VPN Connect is the easiest and fastest way to connect your on-premises network and your Oracle virtual cloud network (VCN) using IPSec tunnels over the internet. It uses industry standard IPSec protocol suite that encrypts the entire IP traffic before the packets are transferred from the source to the destination.
The purpose of this document is to provide you a simple guide how to implement VPN Connect utilizing the Oracle Console, educate you on how the service work, and what to expect so you are successful connecting to Oracle Cloud.
VPN Connect offers the following advantages:
Public internet lines are used to transmit data, so dedicated, expensive lease lines from on-premises network are not needed.
Internal IP addresses from your on-premises networks are hidden from external users.
The entire communication between the on-premises network and Oracle Cloud is encrypted, significantly lowering the chances of information theft.
In this section you will learn about some of the technology considerations used to deploy VPN Connect. This section communicates technology information and provides key points that you need to understand as they play a key role when deploying VPN Connect. If you have deep knowledge of IPSec VPN and networking you might skip to the next section Before You Get Started. Figure 1 shows a high overview of the solution.
Figure 1. VPN Connect overview
IPSec is a standard protocol which creates an encrypted tunnel between two end points (your on-premises network and Oracle Cloud). This tunnel creates a Virtual Private Network (VPN) securing the communication between your on-remises CPE and the Oracle headends the as it passes over the internet. By default, Oracle provides you with two VPN headends in the region to terminate the tunnels for redundancy. In general, IPSec can be configured in two modes:
Transport mode (NOT supported by Oracle): 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.
Figure 2. VPN Tunnel modes
During the process of establishing the tunnel, the end devices at both ends of the connection go through a series of negotiations for encapsulation and security called Internet Key Exchange (IKE). The IPSec protocol has two IKE phases:
IKE Phase 1 known as ISAKMP (Internet Security Association and Key Management Protocol) - it is used to create a private tunnel between the end points for a secure communication.
IKE Phase 2 known as IPsec - it is used to create the IPsec tunnel used for user traffic
Each phase has its own configuration parameters and both ends of the tunnel need be configured with the same parameters for the tunnel to come up and for traffic to flow through the tunnel. Table 1 shows the parameters supported by Oracle for each phase. For some parameters, Oracle supports multiple values, and the recommended one is highlighted in bold font. If a parameter is not listed, it means that it is NOT supported. Vendors might use a different name for the various parameters so check with your vendor that it can support these parameters.
Table 1. Oracle Phase 1 and Phase 2 Supported Parameters
ISAKMP Policy Options (Phase 1)
IPSec Policy Options (Phase 2)
As part of phase 1, a pre-shared-key (shared secret) is exchanged between the devices at both ends of the connection. By default, Oracle assigns the shared secret to the tunnel unless you provide your own. You can provide a shared secret for each tunnel when you configure it in the Oracle Console 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 for a moment while it is being reprovisioned.
The IPSec protocol uses Security Associations (SAs) to determine how to encrypt packets. Within each SA, you define the Encryption Domain or Security Parameter Indexes (SPIs) to map a packet's source and destination IP address and protocol type to an entry in the SA database to define how to encrypt or decrypt a packet. The encryption domain is what is encrypted or what is allowed within the IPSec tunnel.
Important: Oracle supports only a single encryption domain or SPI.
There are two types of VPN tunnels that you need to be aware of:
Route-based tunnels: Also called next-hop-based tunnels. A route table lookup is performed on a packet's destination IP address. If that route’s egress interface is an IPSec tunnel, the packet is encrypted and sent to the other end of the tunnel.
Policy-based tunnels: The packet's source and destination IP address and protocol are matched against a list of policy statements. If a match is found, the packet is encrypted based on the rules in that policy statement.
Important: The Oracle VPN headends supports route-based tunnels, but can work with policy-based tunnels with some caveats as listed below.
It's the simplest configuration with the most interoperability with the Oracle VPN headend. Route-based IPSec uses an encryption domain or SPI with the following values:
Source IP address: Any (0.0.0.0/0)
Destination IP address: Any (0.0.0.0/0)
If you configure your CPE with policy-based tunnels, there are restrictions on the policy that you can use on the CPE. The Oracle VPN headend supports only a single encryption domain or SPI. If your policy includes multiple entries, the tunnel will bounce or there will be connectivity problems in which only a single policy works at any one time.
For policy-based IPSec, Oracle recommends using a single encryption domain or SPI with the following values:
Source IP address: Any (0.0.0.0/0) or a single summary subnet for your on-premises network
Destination IP address: VCN subnet (example: 10.120.0.0/20)
Make sure the single encryption domain or SPI matches any traffic that needs to go from your on-premises network across the IPSec tunnel to the VCN. The VCN subnet must not overlap with your on-premises network.
The CPE IKE identifier is used by IPSec to identified each end of the connection. 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 you CPE's public IP address, which you provide when you create the CPE object in the Oracle Console. 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.
Figure 3. Your CPE behind a NAT device
In this type of situation, the tunnels will not come up as Oracle will receive the wrong CPE IKE identifier. 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 in the Oracle Console. 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.
Routing plays a key part when setting up VPN Connect as you can have your tunnels up and working but if the routing is not set properly, traffic will not be redirected to the tunnel. VPN Connect supports two routing types, and you have the option to choose the routing type separately for each tunnel:
BGP dynamic routing: Routes are learned dynamically through the BGP routing protocol between your CPE and the DRG. The DRG dynamically learns the routes advertised by your CPE for your on-premises network and your CPE learns the VCN's subnets advertised by the DRG.
Static routing: Manually you specify in the Oracle Console the on-premises networks that you want the VCN to know about. You also must configure your CPE device with static routes to the VCN's subnets.
If you choose BGP, for each tunnel you must provide a different /31 subnet (two IP addresses). This subnet will address each of the two BGP peers in the tunnel's BGP session. The addresses must be within the encryption domain for the IPSec tunnel. You must also provide the BGP autonomous system number (BGP ASN) for your network. See Figure 4 for details.
Figure 4. BGP IP address requirements example
If you choose static routing, you must provide at least one subnet (maximum 10 but if needed this limit can be increased) of your on-premises network. The subnet(s) specified become static routes the DRG uses to route traffic to your on-premises network. Note that the same set of static routes are used for all tunnels in IPSec connection that are configured to use static routing. You can update/change the on-premises subnets at any time after creating the IPSec connection.
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 you have two tunnels using the same routing protocol and you advertise the same routes across both tunnels, Oracle always prefers the oldest established route when responding to requests or initiating connections to your on-premises network. This could create asymmetric routing, meaning you could send a request over Tunnel 1, but then Oracle response could come back over Tunnel 2. See Figure 3 above as an example. Oracle receives the same route 10.0.0.0/8 from both tunnels. It will respond based on the oldest established route so if for example Tunnel 2 is the oldest, Oracle will respond over Tunnel 2.
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 initiating connections. If you use static routing, you can only influence traffic from your on-premises network towards your VCN. For more details see the “Influencing Routing” section below.
Oracle uses 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 Table 2. Assuming that you're not influencing routing in some way, when the same route is advertised over multiple paths to the DRG at the Oracle end of the connections, Oracle prefers the paths in the following order:
Table 2. Oracle preferred 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||VPN Connect 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||VPN Connect with static routing||Oracle prepends 3 private ASNs on the static routes that you've provided (Oracle advertises those routes to the DRG at the Oracle end VPN Connect)||Private ASN, Private ASN, Private ASN, Your ASN|
Within a VPN Connect connection, you can influence which tunnel is preferred. Here are some points for your consideration:
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. For example, over Tunnel 1 you could advertise your VCN’s address space as 172.16.0.0/17 and 172.16.128.0/17 while over Tunnel 2 you could advertise 172.16.0.0/16. Your CPE will prefer Tunnel 1 In this case.
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.
Security also plays a key role when setting up VPN Connect as you can have your tunnels up and working, your routing properly set to send traffic to the tunnels, but if security lists do not allow the traffic between your on-premises network and your VCN, traffic will not flow through the tunnel. On the Oracle side you need to update/create security lists at the subnet level as well as the DRG. On your on-premises network you might have Access Control Lists (ACLs) or firewalls restricting traffic. On either side you need to allow traffic to flow based on your application’s requirements. At this level you have also a more granular control of the traffic flow. For example, you might open traffic for SSH, or HTTPS, or Ping (and path MTU discovery).
If there is a firewall on your on-premises network in front of your CPE device terminating the tunnels, make sure the firewall allows traffic from both Oracle headends to create the IPSec tunnels. The firewall will need to allow traffic for TCP/UDP 500, and IP protocol 50 (ESP). Without these ports open the IPsec tunnels will not be established.
In this section you will learn about the different components involved establishing VPN Connect, what role they play and where it can be configured. If you have deep knowledge of IPSec VPN and networking you might skip to the next section Before You Get Started.
Figure 4 shows the different components for VPN Connect to give you and overview of the solution. It will help you visualized where these components are located. We strongly recommend to have your network team configure VPN Connect. They have some information required to complete the tasks in this guide, and they need to configure the CPE on your on-premises network. On the Oracle side you can configure the components either from the Console or via APIs. This document focuses on using the Console. If you need API support please refer to the public documentation for VPN Connect.
Figure 5. VPN Connect components
At Oracle's end of VPN Connect is a virtual router called a dynamic routing gateway (DRG), which is the gateway into your VCN from your on-premises network. After creating a DRG, you must attach it to your VCN, using either the Console or API. The DRG is where the IPSec tunnels terminate on the Oracle side. You must also add one or more route rules on your VCN’s subnets pointing to the DRG and add rules to your security lists. Without that DRG attachment and the security and route rules, traffic will not be directed and will not flow to your on-premises network. There are two other components that are not represented in the diagram as they are part of the actual configuration which are very important:
When setting up VPN Connect, you must create a virtual representation of your CPE (5) terminating the IPSec tunnel. This component is created in the Oracle Console and it contains basic information about your device that Oracle needs to configure its VPN headends.
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 VPN Connect service. This will create the two tunnels (7 & 8). When you create this component, you configure the type of routing to use for each tunnel, you provide any related routing information, and the shared secret.
The VPN headend is where the IPSec tunnel terminates in the Oracle Cloud. It is part of the DRG but for simplicity it is represented in Figure 4 as separate components to help you understand the concept. When you configure VPN Connect Oracle by default provides two headends for redundancy.
The virtual private network is the core of your cloud deployment, with firewall rules and specific types of communication gateways that you can choose to use. A VCN resides in a single Oracle Cloud Infrastructure region and covers a single, contiguous IPv4 subnet block of your choice. For additional information see Allowed VCN Size and Address Ranges and VCNs and Subnets.
VCN subnets is how you segregate/segment traffic within your VCN. You have the option to create private and public subnets.
Private subnets within your VCN are addressed typically with private IP addresses (RFC 1918). Instances in a private subnet can reach the internet via a NAT gateway but they cannot be reached from the internet.
Public subnets within your VCN are also addressed typically with private IP addresses (RFC 19118) but you have the option to request from Oracle to assign each instance a public IP address. Bsically Oracle will translate the private IP address with a public IP address. This is known as 1:1 NAT (Network Address Translation). Instances in a public subnet can reach the internet via an Internet Gateway and they can also be reached from the Internet using the public IP address assigned to them.
Each subnet has its own routing table and its own security lists. For your subnets to communicate with your on-premises network you need to add a route rule for your on-premises networks pointing to the DRG. You also need to create/modify the security lists associated with each subnet to allow traffic to your on-premises network.
This is the network device at your on-premises network which terminates the IPSec tunnel. It could be a router, a firewall, or a virtual appliance that supports IPSec protocol. Figure 4 shows a CPE terminating the IPSec tunnel and connecting to the Internet but the CPE could be a device sitting behind another device deep within your network. It could be sitting behind a router or a firewall. As mentioned above during configuration the CPE object is the representation of this device. If your device is behind a firewall or other network equipment performing a NAT function called NAT Device please see Your CPE Is Behind a NAT Device at the end of this section.
They are the subnets within your on-premises network that need to talk to the VCN in the Oracle Cloud. You will advertise them to Oracle via BGP or you will configure them statically when creating the IPSec connection object.
An IPSec tunnel is used to encrypt traffic between secured IPSec endpoints. Oracle creates two tunnels for each VPN Connect connection for redundancy. 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 (5). This information includes an IP address for Oracle’s headend, a shared secret, and the ISAKMP and IPSec parameters from Table 1.
The route table is used you tell the subnets within your VCN what path they need to take in order to reach your on-premises network. Each subnet can have its own route table giving you flexibility to control what subnets within your VCN can talk to your on-premises network. You must also add one or more route rules on your VCN’s subnets pointing to the DRG to reach your on-premises network. Please note that this route table is different than BGP or static routing used when exchanging routing between your CPE and the DRG.
Security lists allows you to control the traffic in and out of your VCN’s subnets in more granular fashion as you can permit/deny traffic based on source and destination IP address plus port for the protocol or application used. The security list for your VCN’s subnets need to be updated to allow application traffic between the VCN and your on-premises network.