Oracle Cloud Infrastructure Documentation

Setting Up an IPSec VPN

This topic gives instructions for setting up an IPSec VPN for your VCN. For general information about IPSec VPNs, see IPSec VPN 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:

  • Answer these questions:

  • Draw a diagram of your network layout similar to the one in the preceding section. Think about which parts of your on-premises network need to communicate with your VCN, and the reverse. Map out the routing and security lists that you need for your VCN.

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 router's public IP address.
    8. From your DRG, create an IPSec connection to the CPE object and provide your static routes.
  3. Have your network engineer configure your CPE router: Your network engineer must configure your on-premises router 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

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 where. 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 router's public IP address
Task 2h: From your DRG, create an IPSec connection to the CPE object and provide your static routes
Task 3: Have your network engineer configure your CPE router
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 on-premises router in each area
  • Two IPSec VPNs (one for each on-premises router)

Notice that each IPSec VPN has two static routes associated with it: one for the CIDR of the particular geographical area, and a broad 0.0.0.0/0 static route. To understand why, see About the Static Routes.

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 static route can provide flexibility:

  • Assume that the CPE 1 router 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 static 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 static 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 on-premises routers (two in each geographical area)
  • Four IPSec VPNs (one for each on-premises router)
  • Port address translation (PAT) for each on-premises router

When you create each of the four IPSec connections, the static route that you specify is the PAT IP address for the specific on-premises router. 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: