One way to connect your on-premises network and your virtual cloud network (VCN) is to use VPN Connect, which is an IPSec VPN. IPSec stands for Internet Protocol Security or IP Security. IPSec is a protocol suite that encrypts the entire IP traffic before the packets are transferred from the source to the destination.
Required Personnel and Knowledge
Typically the following types of personnel are involved in setting up an IPSec 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 IPSec VPN.
- Network engineer (or similar function) who configures the customer-premises equipment (CPE) device with information provided by the Dev Ops team member.
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 your Oracle Cloud Infrastructure tenancy or a member of the Administrators group, then they have the required permission. For information about restricting access to your networking components, see Access Control.
The personnel should be familiar with the following concepts and definitions:
- The fundamentals of Oracle Cloud Infrastructure
- The basic Networking service components
- General IPSec VPN tunnel functionality
- cloud resources
- Anything you provision on a cloud platform. For example, with Oracle Cloud Infrastructure, a cloud resource can refer to a VCN, compute instance, user, compartment, load balancer, or any other service component on the platform.
- A widely used term in cloud technologies that refers to your traditional data center environments. On-premises can refer to a colocation scenario, a dedicated floor space, a dedicated data center building, or a desktop running under your 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 choose the value for an OCID or change a resource's OCID. For more information, see Resource Identifiers.
About the Oracle IPSec VPN
In general, IPSec 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 VPN consists of multiple redundant IPSec tunnels. For a given 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.
IPSec VPN site-to-site tunnels offer the following advantages:
- Public internet lines are used to transmit 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, significantly lowering the chances of information theft.
IPv6 addressing is currently supported only in the Government Cloud. For more information, see IPv6 Addresses.
When you create an IPSec VPN, it has two redundant IPSec tunnels. Oracle encourages you to configure your CPE device to use both tunnels (if your device supports it). Note that in the past, Oracle created IPSec VPNs 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 IPSec 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. None of these routes are learned dynamically.
Here are important details to understand about routing for your IPSec VPN:
- Originally, the Oracle IPSec 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 given tunnel.
- In general, Oracle encourages you to use the same routing type for all tunnels in your IPSec connection. Exception: 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 choose 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 your network.
- If you choose 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 your CPE device and VCN, the static route for the IPSec connection is the PAT IP address. See Example Layout with PAT.
- If you choose static routing, you may 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 given tunnel's traffic only if that tunnel is configured to use static routing. This is especially relevant if you have an IPSec VPN that uses static routing, but want to switch to using BGP.
Changing the routing:
- If you want 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 currently being provisioned by Oracle). While you change the routing, the tunnel remains up (its IPSec status does not change). However, traffic flowing through the tunnel is disrupted temporarily during reprovisioning and while you reconfigure your CPE device. For information about making changes to an existing IPSec VPN, see Working with VPN Connect.
- Because you configure the routing type separately for each tunnel, if you want to switch your IPSec VPN from static routing to BGP, you can do it one tunnel at a time. This avoids the entire IPSec VPN being down. For instructions, see Changing from Static Routing to BGP Dynamic Routing.
For redundancy, you might use multiple connections between your on-premises network and VCN. For example, you might use both a FastConnect and an IPSec VPN. Or perhaps you use multiple IPSec VPNs (for an example scenario, see Example Layout with Multiple Geographic Areas). The IPSec VPNs could use either BGP or static routing, or a combination. FastConnect always uses BGP.
When responding to a request or initiating new connections, Oracle uses the shortest AS path. This means asymmetric routing is allowed. Therefore Oracle's response to a request can follow a different path than the request. For example, depending on how routing is configured, you could send a request over IPSec VPN, but the Oracle response could come back over FastConnect. If you want to force routing to be symmetric, Oracle recommends using BGP and AS path prepending with your routes to influence which path Oracle uses when responding to and initiating connections.
Oracle implements AS path prepending to determine which path to use if the same route is advertised over multiple connections between your on-premises network and VCN. The details are summarized in the following table. Assuming that you're not influencing routing in some way, when the same route is advertised over multiple paths to the An optional virtual router that you can add to your VCN to provide a path for private network traffic between your VCN and on-premises network. at the Oracle end of the connections, Oracle prefers the paths in the following order:
|Oracle preference||Path||Details of how Oracle prefers the path||Resulting AS path for the route|
|1||FastConnect||Oracle prepends no ASNs to the routes that your CPE device advertises.||Your ASN|
|2||IPSec VPN with BGP routing||Oracle prepends a single private ASN on all the routes that your CPE device advertises over IPSec VPN with BGP.||Private ASN, Your ASN|
|3||IPSec VPN with static routing||Oracle prepends 3 private ASNs on the static routes that you've provided (Oracle advertises those routes to the An optional virtual router that you can add to your VCN to provide a path for private network traffic between your VCN and on-premises network. at the Oracle end of the IPSec VPN) .||Private ASN, Private ASN, Private ASN|
If you have two connections of the same type (for example, two IPSec VPNs that both use BGP), and you advertise the same routes across both connections, Oracle prefers the oldest established route when responding to requests or initiating connections.
Within an IPSec VPN, you can influence which tunnel is preferred. Here are items you can configure:
- Your CPE's BGP local preference: If you use BGP, you can configure the BGP local preference attribute on your CPE device to control which tunnel is preferred for connections initiated from your on-premises network to your VCN. Because Oracle generally 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 your 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 initiating 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 given route. Oracle uses the shortest AS path when responding to or initiating connections.
Routes Advertised to Your On-Premises Network
The An optional virtual router that you can add to your VCN to provide a path for private network traffic between your VCN and on-premises network. at the Oracle end of a FastConnect or IPSec VPN advertises the individual subnets in the DRG's attached VCN. A DRG can be attached to only a single VCN, and a VCN can be attached to only a single DRG.
However, if you set up An advanced routing scenario that enables communication between an on-premises network and multiple virtual cloud networks (VCNs) over a single FastConnect or VPN Connect., the DRG advertises additional routes. Transit routing is an advanced routing scenario that involves a single FastConnect or IPSec VPN and multiple peered VCNs in a hub-and-spoke layout. With transit routing, the DRG advertises additional routes for the VCNs that are peered with the DRG's attached VCN (the hub). For more information, see Advanced Scenario: Transit Routing.
If you're not already familiar with the basic Networking service components, see Overview of Networking before proceeding.
When you set up an IPSec VPN for your 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.
- cpe object
- At your end of the IPSec VPN is the actual device in your on-premises network (whether hardware or software). The term customer-premises equipment (CPE) is commonly used in some industries to refer to 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 your device that Oracle needs.
- dynamic routing gateway (drg)
- At Oracle's end of the IPSec VPN is a virtual router called a dynamic routing gateway, which is the gateway into your VCN from your on-premises network. Whether you're using an IPSec VPN or Oracle Cloud Infrastructure FastConnect private virtual circuits to connect your on-premises network and VCN, the traffic goes through the DRG. For more information, see Dynamic Routing Gateways (DRGs).
- A network engineer might think of the DRG as the VPN headend. After creating a DRG, you must attach it to your 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 does not flow between your VCN and on-premises network. At any time, you can detach the DRG from your 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 overall IPSec VPN. The IPSec connection has its own An Oracle-assigned unique ID called an Oracle Cloud Identifier (OCID). This ID is included as part of the resource's information in both the Console and API.. When you create this component, you configure the type of routing to use for each tunnel, and you provide any related routing information.
- 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 An Oracle-assigned unique ID called an Oracle Cloud Identifier (OCID). This ID is included as part of the resource's information in both the Console and API.. Oracle recommends that you configure your CPE device to support both tunnels in case one fails or Oracle takes one offline for maintenance. Each tunnel has configuration information that your network engineer needs when configuring your CPE device. This information includes an IP address and shared secret, as well as ISAKMP and IPSec parameters. 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 the IPSec 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 your 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 your tenancy. Avoid including confidential information in the names. Oracle automatically assigns each component an OCID. For more information, see Resource Identifiers.
In general, the CPE IKE identifier configured on your 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. However, if your CPE is behind a NAT device, the CPE IKE identifier configured on your end might be the CPE's private IP address, as show in the following diagram.
If you cannot change your CPE's IKE identifier (some CPE platforms do not allow you to), you must provide Oracle the CPE IKE identifier value you're using on your end. 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.
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 is being reprovisioned.
For instructions, see Changing the Shared Secret That an IPSec Tunnel Uses
Monitoring Your Connection
You can monitor the health, capacity, and performance of your Oracle Cloud Infrastructure resources by using metrics, alarms, and notifications. For more information, see Monitoring Overview and Notifications Overview.
For information about monitoring your connection, VPN Connect Metrics.