Setting Up VPN Connect

This topic gives instructions for constructing a site-to-site VPN Connect link to your VCN. For general information about IPSec VPNs, see VPN Connect Overview.

Caution

Avoid entering confidential information when assigning descriptions, tags, or friendly names to your cloud resources through the Oracle Cloud Infrastructure Console, API, or CLI.

Before You Get Started

To prepare, do these things first:
  • Read this section: Routing for the Oracle IPSec VPN
  • Answer these questions:

    Question Answer
    What is your VCN's CIDR?  

    What is the public IP address of your CPE device? If you have multiple devices for redundancy, get the IP address for each.

    Note: If your CPE device is behind a NAT device, see Overview of the IPSec VPN Components and also Requirements and Prerequisites.

     
    Will you use port address translation (PAT) between each CPE device and your VCN?  

    What type of routing do you plan to use? If you want BGP dynamic routing, list the BGP session IP addresses to use and the ASN of your network. The IP addresses must be part of the IPSec VPN's encryption domain.

    If you want static routing, what are the static routes for your on-premises network? See Routing for the Oracle IPSec VPN.

     

    Do you want to provide each tunnel's shared secret or let Oracle assign them? See Overview of the IPSec VPN Components.

     
  • Draw a diagram of your network layout (for examples, see the first task in Example: Setting Up a Proof of Concept IPSec VPN). Think about which parts of your on-premises network need to communicate with your VCN, and the reverse. Map out the routing and security rules that you need for your VCN.
Tip

If you have an existing Oracle IPSec VPN that uses static routing, you can change the tunnels to instead use BGP dynamic routing.

Overall Process

Here's the overall process for setting up an IPSec VPN:

  1. Complete the tasks listed in Before You Get Started.
  2. Set up the IPSec VPN components (instructions in Example: Setting Up a Proof of Concept IPSec VPN):
    1. Create your VCN.
    2. Create a DRG.
    3. Attach the DRG to your VCN.
    4. Create a route table and route rule for the DRG.
    5. Create a security list and required rules.
    6. Create a subnet in the VCN.
    7. Create a CPE object and provide your CPE device's public IP address.
    8. Create an IPSec connection to the CPE object and provide required routing information.
  3. Use the CPE Configuration Helper: Your network engineer must configure your CPE device with information that Oracle provides during the previous steps. The CPE Configuration Helper generates the information for your network engineer. For more information, see Using the CPE Configuration Helper and also CPE Configuration.
  4. Have your network engineer configure your CPE device.
  5. Validate connectivity.

If you plan to set up redundant connections, see the Connectivity Redundancy Guide.

Example: Setting Up a Proof of Concept IPSec VPN

Tip

Oracle offers a quickstart workflow to make it easier to set up VPN Connect. For more information, see VPN Connect Quickstart.

This example scenario shows how to set up a single IPSec VPN with a simple layout that you might use for a proof of concept (POC). It follows tasks 1 and 2 in Overall Process and shows each component in the layout being created. For each task, there's a corresponding screenshot from the Console to help you understand what information is needed. For more complex layouts, see Example Layout with Multiple Geographic Areas or Example Layout with PAT.

Task 1: Gather information
Question Answer
What is your VCN's CIDR? 172.16.0.0/16

What is the public IP address of your CPE device? If you have multiple devices for redundancy, get the IP address for each.

Note: If your CPE device is behind a NAT device, see Overview of the IPSec VPN Components and also Requirements and Prerequisites.

142.34.145.37
Will you be doing port address translation (PAT) between each CPE device and your VCN? No

What type of routing do you plan to use? If you plan to use BGP dynamic routing, list the BGP session IP addresses to use and the ASN of your network.

If static routing, list the static routes for your on-premises network. See Routing for the Oracle IPSec VPN.

BGP dynamic routing example:

Tunnel 1:

  • BGP Inside tunnel interface - CPE: 10.0.0.16/31
  • BGP Inside tunnel interface - Oracle: 10.0.0.17/31

Tunnel 2:

  • BGP Inside tunnel interface - CPE: 10.0.0.18/31
  • BGP Inside tunnel interface - Oracle: 10.0.0.19/31

Network ASN: 12345

Static routing example:

Use 10.0.0.0/16 for the static route for a simple POC.

Do you want to provide each tunnel's shared secret or let Oracle assign them? See Overview of the IPSec VPN Components. Let Oracle assign.

Here's an example diagram for task 1 that uses BGP dynamic routing:

This image shows a basic VPN layout when using BGP dynamic routing.

Here's an example diagram for task 1 that uses static routing:

This image shows a basic VPN layout when using static routing.

Task 2a: Create the VCN

If you already have a VCN, skip to the next task.

Tip

When you use the Console to create a VCN, you can create only the VCN, or you can create the VCN with several related resources. This task creates only the VCN, and the subsequent tasks create the other required resources.

This image shows creation of the VCN

  1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual Cloud Networks.
  2. Choose a compartment you have permission to work in (on the left side of the page). The page updates to display only the resources in that compartment. If you're not sure which compartment to use, contact an administrator. For more information, see Access Control.
  3. Click Create Virtual Cloud Network.
  4. Enter the following values:

    • Create in Compartment: Leave as is.
    • Name: A descriptive name for the cloud network. It doesn't have to be unique, and it can't be changed later in the Console (but you can change it with the API). Avoid entering confidential information.
    • CIDR Block: A single, contiguous CIDR block for the cloud network (for example, 172.16.0.0/16). You can't change this value later. See Allowed VCN Size and Address Ranges. For reference, use a CIDR calculator.
    • Enable IPv6 Address Assignment: This option is available only if the VCN is in the US Government Cloud. For more information, see IPv6 Addresses.
  5. You can provide values for the rest of the options, or you can ignore them:

    • DNS Resolution: Required for assignment of DNS hostnames to hosts in the VCN, and required if you plan to use the VCN's default DNS feature (called the Internet and VCN Resolver). If the check box is selected, you can specify a DNS label for the VCN, or the Console will generate one for you. The dialog box automatically displays the corresponding DNS Domain Name for the VCN (<VCN DNS label>.oraclevcn.com). For more information, see DNS in Your Virtual Cloud Network.
    • Tags: If you have permissions to create a resource, then you also have permissions to apply free-form tags to that resource. To apply a defined tag, you must have permissions to use the tag namespace. For more information about tagging, see Resource Tags. If you are not sure if you should apply tags, then skip this option (you can apply tags later) or ask your administrator.
  6. Click Create Virtual Cloud Network.

The VCN is created and displayed on the page. Ensure that it's done being provisioned before continuing.

Task 2b: Create the DRG

This image shows creation of the DRG

  1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Dynamic Routing Gateways.

  2. Click Create Dynamic Routing Gateway.
  3. Enter the following values:
    • Create in Compartment: Leave as is (the VCN's compartment).
    • Name: A descriptive name for the DRG. It doesn't have to be unique, and it cannot be changed later in the Console (but you can change it with the API). Avoid entering confidential information.
    • Tags: Leave as is. You can add tags later if you want. For more information, see Resource Tags.
  4. Click Create Dynamic Routing Gateway.

The DRG is created and displayed on the page. Ensure that it's done being provisioned before continuing.

Tip

You could also use this DRG as the gateway for Oracle Cloud Infrastructure FastConnect, which is an alternative way to connect your on-premises network to your VCN.
Task 2c: Attach the DRG to the VCN

This image shows attachment of the DRG to the VCN

  1. Click the name of the DRG you created.
  2. Under Resources, click Virtual Cloud Networks.
  3. Click Attach to Virtual Cloud Network.
  4. Select the VCN. Ignore the section for advanced options, which is only for an advanced routing scenario called transit routing, which is not relevant here.
  5. Click Attach.

The attachment is in the Attaching state for a short period before it's ready.

Task 2d: Create a route table and route rule for the DRG

Although the VCN comes with a default route table (without any rules), in this task you create a custom route table with a route rule for the DRG. In this example, your on-premises network is 10.0.0.0/16. You create a route rule that takes any traffic destined for 10.0.0.0/16 and routes it to the DRG. When you create a subnet in task 2f, you associate this custom route table with the subnet.

Tip

If you already have an existing VCN with a subnet, you don't need to create a route table or subnet. Instead you can update the existing subnet's route table to include the route rule for the DRG.

This image shows creation of the route table and route rule for the DRG

  1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual Cloud Networks.
  2. Click your VCN.
  3. Click Route Tables to see your VCN's route tables.
  4. Click Create Route Table.
  5. Enter the following values:

    • Name: A descriptive name for the route table (for example, MyExampleRouteTable). The name doesn't have to be unique, and it can't be changed later in the Console (but you can change it in the API). Avoid entering confidential information.
    • Create in compartment: Leave as is.
    • Click + Additional Route Rule, and enter the following:

      • Target Type: Dynamic Routing Gateway. The VCN's attached DRG is automatically selected as the target, and you don't have to specify the target yourself.
      • Destination CIDR Block: The CIDR for your on-premises network (10.0.0.0/16 in this example).
      • Description: An optional description of the rule.
    • Tags: Leave the tag information as is.
  6. Click Create Route Table.

The route table is created and displayed on the page. However, the route table doesn't do anything unless you associate it with a subnet during subnet creation (see task 2f).

Task 2e: Create a security list

By default, incoming traffic to the instances in your VCN is set to DENY on all ports and all protocols. In this task, you set up two ingress rules and one egress rule to allow basic required network traffic. Your VCN comes with a default security list with a set of default rules. However, in this task you create a separate security list with a more restrictive set of rules focused on traffic with your on-premises network. When you create a subnet in task 2f, you associate this security list with the subnet.

Tip

Security lists are one way to control traffic in and out of the VCN's resources. You can also use network security groups, which let you apply a set of security rules to a set of resources that all have the same security posture.

This image shows creation of the security list

Important

In the following procedure, ensure that the on-premises CIDR that you specify in the security list rules is the same (or smaller) than the CIDR that you specified in the route rule in the preceding task. Otherwise, traffic will be blocked by the security lists.
  1. While still viewing your VCN, click Security Lists on the left side of the page.
  2. Click Create Security List.
  3. Enter the following values:

    • Name: A descriptive name for the security list. The name doesn't have to be unique, and it cannot be changed later in the Console (but you can change it in the API). Avoid entering confidential information.
    • Create in compartment: Leave as is.
  4. In the Allow Rules for Ingress section, click Add Ingress Rule and enter the following values for the ingress rule, which allows incoming SSH on TCP port 22 from your on-premises network:

    • Source Type: CIDR
    • Source CIDR: The CIDR for your on-premises network (10.0.0.0/16 in this example)
    • IP Protocol: TCP.
    • Source Port Range: Leave as is (the default All).
    • Destination Port Range: 22 (for SSH traffic).
    • Description: An optional description of the rule.
  5. In the Allow Rules for Egress section, click Add Egress Rule enter the following values for the egress rule, which allows outgoing TCP traffic on all ports to your on-premises network:

    • Destination Type: CIDR
    • Destination CIDR: The CIDR for your on-premises network (10.0.0.0/16 in this example).
    • IP Protocol: TCP.
    • Source Port Range: Leave as is (the default All).
    • Destination Port Range: Leave as is (the default All).
    • Description: An optional description of the rule.
  6. Leave the tag information as is.
  7. Click Create Security List.

The security list is created and displayed on the page. However, the security list doesn't do anything unless you associate it with a subnet during subnet creation (see task 2f).

Task 2f: Create a subnet

In this task, you create a subnet in the VCN. Typically a subnet has a CIDR block smaller than the VCN's CIDR. Any instances that you create in this subnet have access to your on-premises network. Oracle recommends using regional subnets. Here you create a regional private subnet.

This image shows creation of the subnet

  1. While still viewing your VCN, click Subnets on the left side of the page.
  2. Click Create Subnet.
  3. Enter the following values:

    • Name: A descriptive name for the subnet. It doesn't have to be unique, and it can't be changed later in the Console (but you can change it with the API). Avoid entering confidential information.
    • Regional or AD-specific subnet: Select the radio button for Regional. Oracle recommends using regional subnets.
    • CIDR Block: A single, contiguous CIDR block for the subnet (for example, 172.16.0.0/24). It must be within the cloud network's CIDR block and can't overlap with any other subnets. You can't change this value later. See Allowed VCN Size and Address Ranges. For reference, use a CIDR calculator.
    • Enable IPv6 Address Assignment: This option is available only if the VCN is in the US Government Cloud. For more information, see IPv6 Addresses.
    • Route Table: The route table that you created earlier.
    • Private Subnet: Select this option. For more information, see Access to the Internet.
    • Use DNS Hostnames in this Subnet: Leave as is (selected).
    • DHCP Options: The set of DHCP options to associate with the subnet. Select the default set of DHCP options for the VCN.
    • Security Lists: The security list that you created earlier.
    • Tags: Leave as is. You can add tags later if you want. For more information, see Resource Tags.
  4. Click Create Subnet.

The subnet is created and displayed on the page. The basic VCN in this example is now set up, and you're ready to create the remaining components for the IPSec VPN.

Task 2g: Create a CPE object and provide your CPE device's public IP address

In this task, you create the CPE object, which is a virtual representation of your CPE device.

This image shows creation of the CPE object

  1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Customer-Premises Equipment.

  2. Click Create Customer-Premises Equipment.
  3. Enter the following values:

    • Create in Compartment: Leave as is (the VCN's compartment).
    • Name: A descriptive name for the CPE object. It doesn't have to be unique, and it cannot be changed later in the Console (but you can change it with the API). Avoid entering confidential information.
    • IP Address: The public IP address of the CPE device at your end of the VPN (see the list of information to gather in Before You Get Started).
    • Tags: Leave as is. You can add tags later if you want. For more information, see Resource Tags.
  4. Click Create.

The CPE object is created and displayed on the page.

Task 2h: Create an IPSec connection to the CPE object

In this task, you create the IPSec tunnels and configure the type of routing for them (BGP dynamic routing or static routing).

Tip

If you have an existing Oracle IPSec VPN that uses static routing, you can change the tunnels to instead use BGP dynamic routing.
For BGP dynamic routing

In this example, you configure both tunnels to use BGP dynamic routing.

This image shows creation of the IPSec connection with BGP dynamic routing.

  1. Open the navigation menu. Under Core Infrastructure, go to Networking and click IPSec Connections.

  2. Click Create IPSec Connection.
  3. Enter the following values:

    • Create in Compartment: Leave as is (the VCN's compartment).
    • Name: Enter a descriptive name for the IPSec connection. It doesn't have to be unique, and you can change it later. Avoid entering confidential information.
    • Customer-Premises Equipment Compartment: Leave as is (the VCN's compartment).
    • Customer-Premises Equipment: Select the CPE object that you created earlier.
    • Dynamic Routing Gateway Compartment: Leave as is (the VCN's compartment).
    • Dynamic Routing Gateway: Select the DRG that you created earlier.
    • Static Route CIDR: Leave empty because this IPSec connection uses BGP dynamic routing. You configure the two tunnels to use BGP in subsequent steps.
  4. Click Show Advanced Options.
  5. On the CPE IKE Identifier tab (optional): Oracle defaults to using the public IP address of the CPE. But if your CPE is behind a NAT device, you might need to enter a different value. You can either enter the new value here, or change the value later.
  6. On the Tunnel 1 tab (required):

    • Name: Enter a descriptive name for the tunnel. It doesn't have to be unique, and you can change it later. Avoid entering confidential information.
    • Provide custom shared secret (optional): By default, Oracle provides the shared secret for the tunnel. If you want to provide it instead, select this check box and enter the shared secret. You can change the shared secret later.
    • IKE Version: The Internet Key Exchange (IKE) version to use for this tunnel. Only select IKEv2 if your CPE supports it. You must also then configure the CPE to use only IKEv2 for this tunnel.
    • Routing Type: Select the radio button for BGP Dynamic Routing.
    • BGP ASN: Enter your network's ASN.
    • Inside Tunnel Interface - CPE: Enter the BGP IP address with subnet mask (either /30 or /31) for the CPE end of the tunnel. For example: 10.0.0.16/31. The IP address must be part of the IPSec VPN's encryption domain.
    • Inside Tunnel Interface - Oracle: Enter the BGP IP address with subnet mask (either /30 or /31) for the Oracle end of the tunnel. For example: 10.0.0.17/31. The IP address must be part of the IPSec VPN's encryption domain.
  7. On the Tunnel 2 tab (required):

    • Name: Enter a descriptive name for the tunnel. It doesn't have to be unique, and you can change it later. Avoid entering confidential information.
    • Provide custom shared secret (optional): By default, Oracle provides the shared secret for the tunnel. If you want to provide it instead, select this check box and enter the shared secret. You can change the shared secret later.
    • IKE Version: The Internet Key Exchange (IKE) version to use for this tunnel. Only select IKEv2 if your CPE supports it. You must also then configure the CPE to use only IKEv2 for this tunnel.
    • Routing Type: Select the radio button for BGP Dynamic Routing.
    • BGP ASN: Enter your network's ASN.
    • Inside Tunnel Interface - CPE: Enter the BGP IP address with subnet mask (either /30 or /31) for the CPE end of the tunnel. Use a different IP address than for tunnel 1. For example: 10.0.0.18/31. The IP address must be part of the IPSec VPN's encryption domain.
    • Inside Tunnel Interface - Oracle: Enter the BGP IP address with subnet mask (either /30 or /31) for the Oracle end of the tunnel. Use a different IP address than for tunnel 1. For example: 10.0.0.19/31. The IP address must be part of the IPSec VPN's encryption domain.
  8. On the Tags tab (optional): Leave as is. You can add tags later if you want. For more information, see Resource Tags.
  9. Click Create IPSec Connection.

    The IPSec connection is created and displayed on the page. It will be in the Provisioning state for a short period.

    The displayed tunnel information includes:

    • The Oracle VPN IP address (for the Oracle VPN headend).
    • The tunnel's IPSec status (possible values are Up, Down, and Down for Maintenance). At this point, the status is Down. Your network engineer still must configure your CPE device.
    • The tunnel's BGP status. At this point, the status is Down. Your network engineer still must configure your CPE device.

    To view the tunnel's shared secret, click the tunnel to view its details, and then click Show next to Shared Secret.

  10. Copy the Oracle VPN IP address and shared secret for each of the tunnels to an email or other location so you can deliver it to the network engineer who will configure your CPE device.

    You can view this tunnel information here in the Console at any time.

You have now created all the components required for the IPSec VPN. But your network engineer must configure your CPE device before network traffic can flow between your on-premises network and VCN.

For static routing

This image shows creation of the IPSec connection with static routing.

  1. Open the navigation menu. Under Core Infrastructure, go to Networking and click IPSec Connections.

  2. Click Create IPSec Connection.
  3. Enter the following values:

    • Create in Compartment: Leave as is (the VCN's compartment).
    • Name: Enter a descriptive name for the IPSec connection. It doesn't have to be unique, and you can change it later. Avoid entering confidential information.
    • Customer-Premises Equipment Compartment: Leave as is (the VCN's compartment).
    • Customer-Premises Equipment: Select the CPE object that you created earlier.
    • Dynamic Routing Gateway Compartment: Leave as is (the VCN's compartment).
    • Dynamic Routing Gateway: Select the DRG that you created earlier.
    • Static Route CIDR: Enter at least one static route CIDR (see the list of information to gather in Before You Get Started). For this example, enter 10.0.0.0/16. You can enter up to 10 static routes, and you can change the static routes later.
  4. Click Show Advanced Options.
  5. On the CPE IKE Identifier tab (optional): Oracle defaults to using the public IP address of the CPE. But if your CPE is behind a NAT device, you might need to enter a different value. You can either enter the new value here, or change the value later.
  6. On the Tunnel 1 tab (optional):

    • Tunnel Name: Enter a descriptive name for the tunnel. It doesn't have to be unique, and you can change it later. Avoid entering confidential information.
    • Provide custom shared secret (optional): By default, Oracle provides the shared secret for the tunnel. If you want to provide it instead, select this check box and enter the shared secret. You can change the shared secret later.
    • IKE Version: The Internet Key Exchange (IKE) version to use for this tunnel. Only select IKEv2 if your CPE supports it. You must also then configure the CPE to use only IKEv2 for this tunnel.
    • Routing Type: Leave the radio button for Static Routing selected.
    • Inside Tunnel Interface - CPE (optional): You can provide an IP address with subnet mask (either /30 or /31) for the CPE end of the tunnel for the purposes of tunnel troubleshooting or monitoring. For example: 10.0.0.16/31. The IP address must be part of the IPSec VPN's encryption domain.
    • Inside Tunnel Interface - Oracle (optional): You can provide an IP address with subnet mask (either /30 or /31) for the Oracle end of the tunnel for the purposes of tunnel troubleshooting or monitoring. For example: 10.0.0.17/31. The IP address must be part of the IPSec VPN's encryption domain.
  7. On the Tunnel 2 tab (optional):

    • Tunnel Name: Enter a descriptive name for the tunnel. It doesn't have to be unique, and you can change it later. Avoid entering confidential information.
    • Provide custom shared secret (optional): By default, Oracle provides the shared secret for the tunnel. If you want to provide it instead, select this check box and enter the shared secret. You can change the shared secret later.
    • IKE Version: The Internet Key Exchange (IKE) version to use for this tunnel. Only select IKEv2 if your CPE supports it. You must also then configure the CPE to use only IKEv2 for this tunnel.
    • Routing Type: Leave the radio button for Static Routing selected.
    • Inside Tunnel Interface - CPE (optional): You can provide an IP address with subnet mask (either /30 or /31) for the CPE end of the tunnel for the purposes of tunnel troubleshooting or monitoring. Use a different IP address than for tunnel 1. For example: 10.0.0.18/31. The IP address must be part of the IPSec VPN's encryption domain.
    • Inside Tunnel Interface - Oracle (optional): You can provide an IP address with subnet mask (either /30 or /31) for the Oracle end of the tunnel for the purposes of tunnel troubleshooting or monitoring. Use a different IP address than for tunnel 1. For example: 10.0.0.19/31. The IP address must be part of the IPSec VPN's encryption domain.
  8. Tags: Leave as is. You can add tags later if you want. For more information, see Resource Tags.
  9. Click Create IPSec Connection.

    The IPSec connection is created and displayed on the page. It will be in the Provisioning state for a short period.

    The displayed tunnel information includes:

    • The Oracle VPN IP address (for the Oracle VPN headend).
    • The tunnel's IPSec status (possible values are Up, Down, and Down for Maintenance). At this point, the status is Down. Your network engineer still must configure your CPE device.

    To view the tunnel's shared secret, click the tunnel to view its details, and then click Show next to Shared Secret.

  10. Copy the Oracle VPN IP address and shared secret for each of the tunnels to an email or other location so you can deliver it to the network engineer who will configure the CPE device.

    You can view this tunnel information here in the Console at any time.

You have now created all the components required for the IPSec VPN. But your network engineer must configure the CPE device before network traffic can flow between your on-premises network and VCN.

For more information, see CPE Configuration.

Task 3: Use the CPE Configuration Helper

Use the CPE Configuration Helper to generate configuration content that your network engineer can use to configure the CPE.

The content includes these items:

  • For each IPSec tunnel, the Oracle VPN IP address and shared secret.
  • The supported IPSec parameter values.
  • Information about the VCN.
  • CPE-specific configuration information.

For more information, see Using the CPE Configuration Helper.

Task 4: Have your network engineer configure your CPE
Task 5: Validate connectivity

After the network engineer configures your CPE device, you can confirm that the tunnel's IPSec status is Up and green. Next, you can create a Linux instance in the subnet in your VCN. You should then be able to use SSH to connect to the instance's private IP address from a host in your on-premises network. For more information, see Creating an Instance.

Example Layout with Multiple Geographic Areas

The following diagram shows an example with this configuration:

  • Two networks in separate geographical areas that each connect to your VCN
  • A single CPE device in each area
  • Two IPSec VPNs (one for each CPE device)

Notice that each IPSec VPN has two routes associated with it: one for the particular geographical area's subnet, and a default 0.0.0.0/0 route. Oracle learns about the available routes for each tunnel either through BGP (if the tunnels use BGP), or because you've set them as static routes for the IPSec connection (if the tunnels use static routing).

This image shows a layout with two geographical areas and two routers

Following are some examples of situations in which the 0.0.0.0/0 route can provide flexibility:

  • Assume that the CPE 1 device goes down (see the next diagram). If Subnet 1 and Subnet 2 can communicate with each other, your VCN could still reach the systems in Subnet 1 because of the 0.0.0.0/0 route that goes to CPE 2.

    This image shows a layout where one of the CPE routers goes down

  • Assume that your organization adds a new geographical area with Subnet 3 and initially just connects it to Subnet 2 (see the next diagram). If you added a route rule to your VCN's route table for Subnet 3, the VCN could reach systems in Subnet 3 because of the 0.0.0.0/0 route that goes to CPE 2.

    This image shows a layout with a new subnet

Example Layout with PAT

The following diagram shows an example with this configuration:

  • Two networks in separate geographical areas that each connect to your VCN
  • Redundant CPE devices (two in each geographical area)
  • Four IPSec VPNs (one for each CPE device)
  • Port address translation (PAT) for each CPE device

For each of the four connections, the route that Oracle needs to know about is the PAT IP address for the specific CPE device. Oracle learns about the PAT IP address route for each tunnel either through BGP (if the tunnels use BGP), or because you've set the relevant address as a static route for the IPSec connection (if the tunnels use static routing).

When you set up the route rules for the VCN, you specify a rule for each PAT IP address (or an aggregate CIDR that covers them all) with your DRG as the rule's target.

This image shows a scenario with multiple IPSec VPNs, routers, and PAT