Setting Up Site-to-Site VPN

Overall Process

Here's the overall process for setting up Site-to-Site VPN:

1. Complete the tasks listed in Before You Get Started.

2. Set up Site-to-Site VPN components (instructions in Example: Setting Up a Proof of Concept Site-to-Site 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 Site-to-Site VPN

Tip

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

This example scenario shows how to set up a Site-to-Site 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: Use the CPE Configuration Helper

Task 4: Have your network engineer configure your CPE

Task 5: Validate connectivity

Example Layout with Multiple Geographic Areas

Libreswan

Libreswan is an open source IPSec implementation that is based on FreeS/WAN and Openswan. Most Linux distributions include Libreswan or make it easy to install. You can install it on hosts in either your on-premises network or a cloud provider network. For an example of setting up a Libreswan host in another cloud provider to connect to your Oracle Cloud Infrastructure virtual cloud network (VCN), see Access to Other Clouds with Libreswan.

This topic provides configuration for CPE that is running Libreswan. Virtual tunnel interface (VTI) support for this route-based configuration requires minimum Libreswan version 3.18 and a recent Linux 3.x or 4.x kernel. This configuration was validated using Libreswan version 3.29.

Important

Oracle provides configuration instructions for a set of vendors and devices. Make sure to use the configuration for the correct vendor.

If the device or software version that Oracle used to verify the configuration does not exactly match your device or software, the configuration might still work for you. Consult your vendor's documentation and make any necessary adjustments.

If your device is for a vendor not in the list of verified vendors and devices, or if you're already familiar with configuring your device for IPSec, see the list of supported IPSec parameters and consult your vendor's documentation for assistance.

Oracle Cloud Infrastructure offersSite-to-Site VPN, a secure IPSec connection between your on-premises network and a virtual cloud network (VCN).

The following diagram shows a basic IPSec connection to Oracle Cloud Infrastructure with redundant tunnels. IP addresses used in this diagram are an example only.

Best Practices

This section covers general best practices and considerations for using Site-to-Site VPN.

Configure All Tunnels for Every IPSec Connection

Oracle deploys two IPSec headends for each of your connections to provide high availability for your mission-critical workloads. On the Oracle side, these two headends are on different routers for redundancy purposes. Oracle recommends configuring all available tunnels for maximum redundancy. This is a key part of the "Design for Failure" philosophy.

Have Redundant CPEs in Your On-Premises Network Locations

Each of your sites that connects with IPSec to Oracle Cloud Infrastructure should have redundant edge devices (also known as customer-premises equipment (CPE)). You add each CPE to the Oracle Console and create a separate IPSec connection between your dynamic routing gateway (DRG) and each CPE. For each IPSec connection, Oracle provisions two tunnels on geographically redundant IPSec headends. For more information, see the Connectivity Redundancy Guide (PDF).

Routing Protocol Considerations

When you create a Site-to-Site VPN IPSec connection, it has two redundant IPSec tunnels. Oracle encourages you to configure your CPE to use both tunnels (if your CPE supports it). Note that in the past, Oracle created IPSec connections that had up to four IPSec tunnels.

The following two routing types are available, and you choose the routing type separately for each tunnel in the Site-to-Site VPN:

• BGP dynamic routing: The available routes are learned dynamically through BGP. The DRG dynamically learns the routes from your on-premises network. On the Oracle side, the DRG advertises the VCN's subnets.

• Static routing: When you set up the IPSec connection to the DRG, you specify the particular routes to your on-premises network that you want the VCN to know about. You also must configure your CPE device with static routes to the VCN's subnets. These routes are not learned dynamically.

• Policy-based routing: When you set up the IPSec connection to the DRG, you specify the particular routes to your on-premises network that you want the VCN to know about. You also must configure your CPE device with static routes to the VCN's subnets. These routes are not learned dynamically.