This topic is for network engineers. It explains how to configure the on-premises router (the customer-premises equipment, or CPE) at your end of the IPSec VPN so traffic can flow between your on-premises network and virtual cloud network (VCN). See these related topics:
- Overview of Networking: For general information about the parts of a VCN
- VPN Connect: For various topics about IPSec VPNs
- Verified CPE Devices: For a list of CPE devices Oracle has verified
The following figure shows the basic layout of the IPSec VPN connection.
There are several requirements and prerequisites to be aware of before moving forward.
Oracle uses asymmetric routing across the multiple tunnels that make up the IPSec VPN connection. Even if you configure one tunnel as primary and another as backup, traffic from your VCN to your on-premises network can use any tunnel that is "up" on your device. Configure your firewalls accordingly. Otherwise, ping tests or application traffic across the connection will not reliably work.
Exception: Cisco ASA policy-based configuration, which uses a single tunnel.
Creation of Cloud Network Components
You or someone in your organization must have already used Networking to create a VCN and an IPSec connection, which consists of multiple IPSec tunnels for redundancy. You must gather the following information about those components:
- VCN ID: The VCN ID has a UUID at the end. You can use this UUID, or any other string that helps you identify this VCN in the device configuration and doesn't conflict with other object-group or access-list names.
- VCN CIDR
- VCN CIDR subnet mask
For each IPSec tunnel:
- The IP address of the Oracle IPSec tunnel endpoint (the VPN headend)
- The pre-shared key (PSK)
You also need some basic information about the inside and outside interfaces of your on-premises router (your CPE). For more information, see the configuration topic for your type of router.
Oracle recommends that you disable NAT-T at your CPE when establishing IPSec tunnels with Oracle Cloud Infrastructure. Unless you have multiple CPEs sharing the same NAT IP, NAT-T is not required.
If your CPE is behind a NAT device, see If Your CPE Is Behind a NAT Device.
The IPSec protocol uses Security Associations (SAs) to determine how to encrypt packets. Within each SA, you define 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.
There are two general methods of implementing IPSec tunnels:
- 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.
The Oracle VPN headends use route-based tunnels, but can work with policy-based tunnels with some caveats listed in the following section.
If your CPE supports route-based tunnels, use that style of tunnel configuration. It's the simplest configuration with the most interoperability with the Oracle VPN headend.
Route-based IPSec uses an SPI with the following values:
- Source IP address: Any (0.0.0.0/0)
- Destination IP address: Any (0.0.0.0/0)
- Protocol: IPv4
If your CPE supports only policy-based tunnels, there are restrictions on the policy that you can use on the CPE.
The Oracle VPN headend supports only a single SPI encryption domain. 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.
If you use policy-based IPSec, Oracle recommends using a single SPI with the following values:
- Source IP address: Any (0.0.0.0/0)
- Destination IP address: VCN CIDR (example: 10.120.0.0/20)
- Protocol: IPv4
Make sure the single SPI matches any traffic that needs to go from your on-premises network across the IPSec tunnel to the VCN. The VCN CIDR must not overlap with your on-premises network.
IPSec VPN Best Practices
- Configure all tunnels for every IPSec connection: Oracle deploys multiple IPSec headends for all your connections to provide high availability for your mission-critical workloads. Configuring all the available tunnels is a key part of the "Design for Failure" philosophy. (Exception: Cisco ASA policy-based configuration, which uses a single tunnel.)
- Have redundant CPEs in your on-premises locations: Each of your sites that connects via IPSec to Oracle Cloud Infrastructure should have redundant CPE devices. If you add each CPE to the Oracle Cloud Infrastructure Console and create an IPSec connection between your dynamic routing gateway (DRG) and each CPE, Oracle will provision a full mesh of tunnel endpoints on the Oracle IPSec headends to your CPEs. The Oracle network dynamically learns which tunnels are up and uses the optimal one based on tunnel state and location.
Consider backup aggregate routes: If you have multiple sites connected via IPSec VPNs to Oracle Cloud Infrastructure, and those sites are connected to your on-premises backbone routers, consider configuring your IPSec connection routes with both the local site aggregate route as well as a default route.
Note that the DRG routes learned from the IPSec connections are only used by traffic you route from your VCN to your DRG. The default route will only be used by traffic sent to your DRG whose destination IP address does not match the more specific routes of any of your tunnels.
Confirming the Status of the Connection
After you configure the IPSec connection, you can test the connection by launching an instance into the VCN and then pinging it from your on-premises network. For information about launching an instance, see Launching an Instance.
You can get the status of the IPSec tunnels