Site-to-Site VPN Overview

Site-to-Site VPN provides an IPSec connection between an on-premises network and a Virtual Cloud Network (VCN). The IPSec protocol suite encrypts IP traffic before the packets are transferred from the source to the destination and decrypts the traffic when it arrives. Site-to-Site VPN was formerly referred to as VPN Connect and IPSec VPN.

Other secure VPN solutions include OpenVPN, a Client VPN solution that can be accessed in the Oracle Marketplace. OpenVPN connects individual devices to a VCN, but not whole sites or networks.

This topic gives an overview of Site-to-Site VPN for a VCN. For scenarios that include Site-to-Site VPN, see Scenario B: Private Subnet with a VPN and Scenario C: Public and Private Subnets with a VPN.

See Site-to-Site VPN Limits and Requesting a Service Limit Increase for limits-related information.

Required Personnel and Knowledge

Typically the following types of personnel are involved in setting up Site-to-Site VPN with Oracle Cloud Infrastructure:

Dev Ops team member (or similar function) who uses the Oracle Cloud InfrastructureConsole to set up the cloud components required for the virtual network and Site-to-Site VPN.
Network engineer (or similar function) who configures the customer-premises equipment (CPE) device with information provided by the Dev Ops team member.

Tip

The Dev Ops team member must have the required permission to create and manage the cloud components. If the person is the default administrator for the Oracle Cloud Infrastructure tenancy or a member of the Administrators group, then they have the required permission. For information about restricting access to networking components, see Access Control.

The personnel should be familiar with the following concepts and definitions:

The fundamentals of Oracle Cloud Infrastructure described in Welcome to Oracle Cloud Infrastructure
The basic Networking service components
General IPSec tunnel functionality

CLOUD RESOURCES: Anything you provision on a cloud platform. For example, with Oracle Cloud Infrastructure, a "cloud resource" can be a VCN, Compute instance, user, compartment, Load Balancer, or any other service component on the platform.
ON-PREMISES: A widely used term in cloud technologies that refers to traditional data center environments. On-premises can mean a colocation scenario, a dedicated floor space, a dedicated data center building, or a desktop running under a desk.
ORACLE CLOUD IDENTIFIER (OCID): A unique identifier assigned to each resource that you provision on Oracle Cloud Infrastructure. The OCID is a long string that Oracle automatically generates. You can't select the value for an OCID or change a resource's OCID. For more information, see Resource Identifiers.

About the Oracle IPSec Connection

In general, an IPSec connection can be configured in the following modes:

Transport mode: IPSec encrypts and authenticates only the actual payload of the packet, and the header information stays intact.
Tunnel mode (supported by Oracle): IPSec encrypts and authenticates the entire packet. After encryption, the packet is then encapsulated to form a new IP packet that has different header information.

Oracle Cloud Infrastructure supports only the tunnel mode for IPSec VPNs.

Each Oracle IPSec connection consists of several redundant IPSec tunnels. For a specific tunnel, you can use either Border Gateway Protocol (BGP) dynamic routing or static routing to route that tunnel's traffic. More details about routing follow.

Site-to-Site VPN IPSec tunnels offer the following advantages:

Public internet lines are used to send data, so dedicated, expensive lease lines from one site to another aren't necessary.
The internal IP addresses of the participating networks and nodes are hidden from external users.
The entire communication between the source and destination sites is encrypted, lowering the chances of information theft.

Routing for Site-to-Site VPN

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

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

BGP dynamic routing: The available routes are learned dynamically through BGP. The DRG dynamically learns the routes from the 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 the on-premises network that you want the VCN to know about. You also must configure the CPE device with static routes to the VCN's subnets. These routes aren't learned dynamically.
Policy-based routing: When you set up the IPSec connection to the DRG, you specify the particular routes to the on-premises network that you want the VCN to know about. You also must configure the CPE device with static routes to the VCN's subnets. These routes aren't learned dynamically.

Important Routing Details for Site-to-Site VPN

Here are important details to understand about routing for Site-to-Site VPN:

Routing choices:
- Originally, Site-to-Site VPN supported only static routing, and you were required to provide at least one static route for the overall IPSec connection.
- Now two different types of routing are available (BGP and static routing), and you configure the routing type per tunnel. Only one type of routing at a time is supported for a particular tunnel.
- In general, we encourage you to use the same routing type for all tunnels in an IPSec connection. One exception is if you're in the process of transitioning between static routing and BGP, then one tunnel might temporarily still use static routing while the other has already been switched to BGP.
- When you create an IPSec connection, static routing is the default type of routing for all tunnels unless you explicitly configure each tunnel to use BGP.
Routing information required:
- If you select BGP, for each tunnel you must provide two IP addresses (one for each of the two BGP speakers in the tunnel's BGP session). The addresses must be in the encryption domain for the IPSec connection. You must also provide the BGP autonomous system number (BGP ASN) for the on-premises network.
- If you select static routing, you must provide at least one static route (maximum 10). The static routes are configured with the overall IPSec connection, so the same set of static routes are used for all tunnels in the IPSec connection that are configured to use static routing. You can change the static routes at any time after creating the IPSec connection. If you're doing PAT between a CPE device and a VCN, the static route for the IPSec connection is the PAT IP address. See Example Layout with PAT.
- If you select static routing, you might optionally provide an IP address for each end of the tunnel for the purposes of tunnel troubleshooting or monitoring.
- If the tunnel is configured to use BGP, the IPSec connection's static routes are ignored. Any static routes associated with the IPSec connection are used for routing a particular tunnel's traffic only if that tunnel is configured to use static routing. This is especially relevant if you have Site-to-Site VPN that uses static routing, but want to switch to using BGP.
Changing the routing:
- To change a tunnel from BGP to static routing, you must first ensure that the IPSec connection itself has at least one static route associated with it.
- You can change an existing tunnel's routing type at any time (unless the tunnel is being provisioned by Oracle). While you change the routing, the tunnel remains up (its IPSec status doesn't change). However, traffic flowing through the tunnel is disrupted temporarily during reprovisioning and while you reconfigure the CPE device. For information about changing Site-to-Site VPN, see Working with Site-to-Site VPN.
- Because you configure the routing type separately for each tunnel, if you switch Site-to-Site VPN from static routing to BGP, it's best to do it one tunnel at a time. This avoids the entire IPSec connection being down. For instructions, see Changing from Static Routing to BGP Dynamic Routing.

Route Advertisements and Path Preferences When You Have Several Connections

When you use BGP, the DRG attached to a VCN advertises routes to the CPE.

If you set up several connections between an on-premises network and VCN, you must understand what routes the DRG advertises and how to set path preferences to use the preferred connection.

For important information, see Routing Details for Connections to the On-premises Network.

Preferring a Specific Tunnel in Site-to-Site VPN

Within Site-to-Site VPN, you can influence which tunnel is preferred. Here are items you can configure:

The CPE's BGP local preference: If you use BGP, you can configure the BGP local preference attribute on the CPE device to control which tunnel is preferred for connections started from an on-premises network to a VCN. Because Oracle uses asymmetric routing, you must configure other attributes if you want Oracle to respond on that same tunnel. See the next two items.
More specific routes on the preferred tunnel: You can configure a CPE to advertise more specific routes for the tunnel that you want to prefer. Oracle uses the route with the longest prefix match when responding to or starting connections.
AS path prepending: BGP prefers the shortest AS path, so if you use BGP, you can use AS path prepending to control which tunnel has the shortest path for a specific route. Oracle uses the shortest AS path when responding to or starting connections.

Overview of Site-to-Site VPN Components

If you're not already familiar with the basic Networking service components, see Networking before proceeding.

When you set up Site-to-Site VPN for a VCN, you must create several Networking components. You can create the components with either the Console or the API. See the following diagram and description of the components.

This image shows the components of Site-to-Site VPN

Callout 1: Default VCN route table
Destination CIDR	Route target
0.0.0.0/0	DRG

cpe object: At the on-premises end of Site-to-Site VPN is the actual device in the on-premises network (whether hardware or software). The term customer-premises equipment (CPE) is commonly used in some industries for this type of on-premises equipment. When setting up the VPN, you must create a virtual representation of the device. Oracle calls the virtual representation a CPE, but this documentation typically uses the term CPE object to help distinguish the virtual representation from the actual CPE device. The CPE object contains basic information about the device that Oracle needs. A single CPE object public IP can have up to 8 IPSec connections.
Dynamic Routing Gateway (DRG): At Oracle's end of Site-to-Site VPN is a virtual router called a dynamic routing gateway, which is the gateway into a VCN from the on-premises network. Whether you're using Site-to-Site VPN or Oracle Cloud Infrastructure FastConnect private virtual circuits to connect the on-premises network and VCN, the traffic goes through the DRG. For more information, see Dynamic Routing Gateways.; A network engineer might think of the DRG as the VPN headend. After creating a DRG, you must attach it to a VCN, using either the Console or API. You must also add one or more route rules that route traffic from the VCN to the DRG. Without that DRG attachment and the route rules, traffic doesn't flow between the VCN and on-premises network. At any time, you can detach the DRG from a VCN but maintain all the remaining VPN components. You can then reattach the DRG, or attach it to another VCN.
ipsec connection: After creating the CPE object and DRG, you connect them by creating an IPSec connection, which you can think of as a parent object that represents the Site-to-Site VPN. The IPSec connection has its own OCID . When you create this component, you configure the type of routing to use for each IPSec tunnel, and you provide any related routing information. A single CPE object public IP can have up to 8 IPSec connections.
TUNNEL: An IPSec tunnel is used to encrypt traffic between secure IPSec endpoints. Oracle creates two tunnels in each IPSec connection for redundancy. Each tunnel has its own OCID . We recommend that you configure the CPE device to support both tunnels in case one fails or Oracle takes one offline for maintenance. Each tunnel has configuration information that a network engineer needs when configuring your CPE device. This information includes an IP address and shared secret, and also ISAKMP and IPSec parameters. You can use the CPE Configuration Helper to gather the information that the network engineer needs. For more information, see Supported IPSec Parameters and Verified CPE Devices.

Access Control for the Components

For the purposes of access control, when you set up Site-to-Site VPN, you must specify the compartment where you want each of the components to reside. If you're not sure which compartment to use, put all the components in the same compartment as the VCN. Note that the IPSec tunnels always reside in the same compartment as the parent IPSec connection. For information about compartments and restricting access to networking components, see Access Control.

Component Names and Identifiers

You can optionally assign a descriptive name to each of the components when you create them. These names don't have to be unique, although it's a best practice to use unique names across a tenancy. Avoid entering confidential information. Oracle automatically assigns each component an OCID. For more information, see Resource Identifiers.

If the CPE Is Behind a NAT Device

In general, the CPE IKE identifier configured on the on-premises end of the connection must match the CPE IKE identifier that Oracle is using. By default, Oracle uses the CPE's public IP address, which you provide when you create the CPE object in the Oracle Console. However, if a CPE is behind a NAT device, the CPE IKE identifier configured on the on-premises end might be the CPE's private IP address, as shown in the following diagram.

This image shows the CPE behind a NAT device, the public and private IP addresses, and the CPE IKE identifier.

Note

Some CPE platforms don't let you change the local IKE identifier. If you can't, you must change the remote IKE ID in the Oracle Console to match the CPE's local IKE ID. You can provide the value either when you set up the IPSec connection, or later, by editing the IPSec connection. Oracle expects the value to be either an IP address or a fully qualified domain name (FQDN) such as cpe.example.com. For instructions, see Changing the CPE IKE Identifier That Oracle Uses.

About the Tunnel Shared Secret

Each tunnel has a shared secret. By default, Oracle assigns the shared secret to the tunnel unless you provide a shared secret yourself. You can provide a shared secret for each tunnel when you create the IPSec connection, or later after the tunnels are created. For the shared secret, only letters, numbers, and spaces are allowed. If you change an existing tunnel's shared secret, the tunnel goes down while it's being reprovisioned.

For instructions, see Changing the Shared Secret That an IPSec Tunnel Uses.

Resources for Configuring the CPE

A network engineer must configure the CPE at the on-premises end of the IPSec connection. To make it easier, Oracle provides these resources:

CPE Configuration Helper: A tool in the Oracle Console that generates a set of content that the network engineer can use when configuring the CPE.
A list of verified CPE devices: For each device, Oracle provides configuration instructions.
A list of supported IPSec parameters: If the CPE isn't on the list of verified devices, you can use this list of parameters to configure the CPE.

For more information, also see CPE Configuration.

Monitoring the Connection

You can monitor the health, capacity, and performance of Oracle Cloud Infrastructure resources by using metrics, alarms, and notifications. For more information, see Monitoring and Notifications.

For information about monitoring the connection, Site-to-Site VPN Metrics.

What's Next?

See these related topics:

Oracle Cloud Infrastructure Documentation