Oracle Cloud Infrastructure Documentation

Setting Up VPN Connect

This topic gives instructions for setting up VPN Connect for your VCN. For general information about IPSec VPNs, see VPN Connect Overview.

Warning

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:

  • 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. Have your network engineer configure your CPE device: Your network engineer must configure your CPE device with information that Oracle provides during the previous steps. There is general information about the VCN, and specific information for each IPSec tunnel. This is the only part of the setup that you can't execute by using the Console or API. Without this configuration, traffic will not flow between your VCN and on-premises network. For more information, see Configuring Your CPE.
  4. Validate connectivity.

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
Task 2a: Create the VCN
Task 2b: Create the DRG
Task 2c: Attach the DRG to the VCN
Task 2d: Create a route table and route rule for the DRG
Task 2e: Create a security list
Task 2f: Create a subnet
Task 2g: Create a CPE object and provide your CPE device's public IP address
Task 2h: Create an IPSec connection to the CPE object
Task 3: Have your network engineer configure your CPE
Task 4: Validate connectivity

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 IPSec 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

What's Next?

See these related topics and procedures: