This blog post was written by my colleague Marcus Dandrea.
This blog aims to help with troubleshooting and identifying common Virtual Private Networking (VPN) issues with Oracle Cloud Infrastructure (OCI). This blog will guide you in the fundamental understanding of OCI VPN Connect and common issues seen with VPN connections for Phase 1 and Phase 2 negotiations and customer premise equipment.
VPN Connect offers a secure and straightforward way to connect your corporate network to OCI over your existing internet connection. It encrypts your data and tunnels it through the public internet for enhanced security and privacy with an Internet Protocol Security (IPSec) VPN connection.
Oracle Cloud Infrastructure uses standard-based IPSec encryption
Verified Equipment Vendors
The verified equipment list is subject to change. Verify your equipment vendor, device, and minimum software version and find configuration information online at https://docs.cloud.oracle.com/iaas/Content/Network/Reference/CPElist.htm
The topology below outlines a configuration that uses a simulated on-premises VPN sitting inside an OCI Virtual Cloud Network (VCN) going to a native VPN Connect setup in another OCI VCN. This provides a troubleshooting environment similar to how a customer would build up a VPN connection to OCI from on-premise. For this blog, we will look at several Phase 1 and Phase 2 issues and some native tools in OCI that can use to identify the problems in the various phases.
VPN Negotiations have two distinct phases: Phase 1 and Phase 2
The primary purpose of Phase 1 is to set up a secure encrypted channel through which the two peers can negotiate Phase 2.
The purpose of Phase 2 negotiations is for the two peers to agree on a set of parameters that define what traffic can go through the VPN and how to encrypt and authenticate the traffic.
The link below identifies the Oracle Supported VPN settings. For this blog, the VPN settings are matched as required by the link below but have been modified to show what happens when the settings do not align.
Oracle Cloud provides native logging for troubleshooting, so it is best to enable these features to identify various VPN issues. This assumes you have the basics of routing in OCI understood and security lists and network security groups.
VCN Flow Logs for the various subnet-containing hosts that will pass traffic across the VPN. (Gives you visibility into the packet flow)
VPN Connect Logs for the VPN in OCI that will use for traffic to premise. (Gives visibility to Phase 1 and Phase 2 issues)
In Phase 1 negotiations, the two VPN gateway devices exchange credentials. The devices identify each other and negotiate to find a standard set of Phase 1 settings to use. When Phase 1 negotiations are completed, the two devices have a Phase 1 Security Association (SA). This SA is valid for a specified amount of time. If the two VPN gateways do not complete Phase 2 negotiations before the Phase 1 SA expires, they must complete Phase 1 negotiations again.
The Phase 1 negotiation process depends on which version of Internet Key Exchange (IKE) the gateway endpoints use. IKE authenticates IPSec peers and negotiates IKE SAs during this phase, setting up a secure communications channel for negotiating IPSec SAs in Phase 2. Phase 1 negotiations include these steps:
The settings in the Phase 1 on each IPSec device must exactly match, or IKE negotiations fail. (Note: The SA Life does not need to match. It will still work)
The items you can set in the Phase 1 are: (Note: You cannot adjust any of these settings on the Oracle side, only on the customer premise device)
Authentication — The type of authentication
Pre-Shared Key — Must match on Oracle side or take the default
Encryption — The type of encryption and key length
SA Life — The amount of time until the Phase 1 Security Association expires
Key Group — The Diffie-Hellman key group
After the two IPSec VPN gateways complete Phase 1 negotiations, Phase 2 negotiations begin. The purpose of Phase 2 negotiations is to establish the Phase 2 SA (sometimes called the IPSec SA). The IPSec SA is a set of traffic specifications that tell the device what traffic to send over the VPN and how to encrypt and authenticate that traffic.
Phase 2 negotiations include these steps:
The VPN gateways use the Phase 1 SA to secure Phase 2 negotiations. The VPN gateways agree on whether to use Perfect Forward Secrecy (PFS). VPN encryption keys are changed at the interval specified by the IPSEC session key lifetime setting. To prevent SAs from using Phase 1 keys for Phase 2, PFS forces the DH calculation to happen a second time. This means that Phase 1 and Phase 2 always have different keys, which are harder to break.
We recommend that you use PFS to keep your data secure. If you want to use PFS, it must be enabled on both VPN gateways, and both gateways must use the same Diffie-Hellman groups. PFS is enabled by default for Oracle with DH group 5
The VPN gateways agree on a Phase 2 proposal.
The Phase 2 proposal includes the algorithm to use to authenticate data, the algorithm to use to encrypt data, and how often to make new Phase 2 encryption keys.
The items you can set in a Phase 2 proposal include:
The settings in Phase 2 on each IPSec device must exactly match, or IPSec negotiations will fail.
Note: Oracle only supports a single encryption domain, so you must summarize routes from the premise if you have multiple subnets. You must build two separate VPN tunnels if you require numerous subnets like a 172.x and a 10.x network.
Troubleshooting command for the remote side of the host: (Example below variations could be different)
tcpdump -i ens3 host 10.1.1.216 –l
16:04:08.753493 IP 10.1.1.216 > private.sub04291536181.vcnvpn.oraclevcn.com: ICMP echo request, id 8317, seq 40, length 64
16:04:08.753508 IP private.sub04291536181.vcnvpn.oraclevcn.com > 10.1.1.216: ICMP echo reply, id 8317, seq 40, length 64
16:04:09.754373 IP 10.1.1.216 > private.sub04291536181.vcnvpn.oraclevcn.com: ICMP echo request, id 8317, seq 41, length 64
16:04:09.754421 IP private.sub04291536181.vcnvpn.oraclevcn.com > 10.1.1.216: ICMP echo reply, id 8317, seq 41, length 64
16:04:10.756579 IP 10.1.1.216 > private.sub04291536181.vcnvpn.oraclevcn.com: ICMP echo request,
VPN Connect Quickstart
Step-by-Step Setup of VPN Connect
CPE Configurations (You can use the wizard in OCI as well to generate the CPE Configuration)
Note: Configurations do not take into consideration existing CPE configurations.
Oracle VPN Best Practices