Best Practices from Oracle Development's A‑Team

Oracle Cloud VPN Connect Troubleshooting

Ben Woltz
Principal Cloud Architect

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.

VPN Connect: Customer Premise Equipment

Oracle Cloud Infrastructure uses standard-based IPSec encryption

Verified Equipment Vendors

  • Check Point
  • Cisco
  • FortiGate
  • Juniper
  • Libreswan (or Openswan)
  • Palo Alto
  • WatchGuard
  • Yamaha

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

Topology Used for VPN Troubleshooting

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.

Understanding IPSEC

VPN Negotiations have two distinct phases: Phase 1 and Phase 2

Phase 1:

The primary purpose of Phase 1 is to set up a secure encrypted channel through which the two peers can negotiate Phase 2.

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.

Oracle Supported VPN Settings

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.


Before Troubleshooting Turn on the Native OCI Tools

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)


Phase 1 Negotiations

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:

  1. The devices agree on the IKE version to use (IKEv1 or IKEv2). Each device can use IKEv1 or IKEv2. The IKE version for both devices must match.
  2. The devices exchange credentials. The credentials can be a pre-shared key only. Both gateway endpoints must use the same credential method, and the credentials must match.
  3. The devices identify each other.  Each device provides a Phase 1 identifier, an IP address, or fully qualified domain name. The VPN configuration on each device specifies the Phase 1 identifier of the local and the remote device. The configurations must match.
  4. For IKEv1, the Oracle VPN gateways use Main Mode for Phase 1 negotiations.

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

Phase 1 Issues Internet Security Association Key Management Protocol (ISAKMP)

  1. Pre-Shared Key Does Not Match:
    VPN Connect Log Message: " \"1506794757\"[1] #112: IKE SA authentication request rejected by peer:AUTHENTICATION_FAILED"
  2. Miss Matching IKE version:
    VPN Connect Log Message: " \"1506794757\" #442: STATE_MAIN_I1: sent MI1, expecting MR1"
  3. Wrong Encryption: (This could be the same for DH Group and authentication as well.)
    VPN Connect Log Message: " \"301846360\"[1] #451: STATE_PARENT_I1: received unauthenticated v2N_NO_PROPOSAL_CHOSEN - ignored"
  4. Wrong Peer ID: When behind Nat, say the firewall sits behind a router with a private IP, the Peer ID would be the outside interface of the firewall, which could be a 172.x, 10.x, or 192.168.x.x. The public IP would be the Local ID and the CPE information for OCI.
    VPN Connect Log Message: " \"301846360\"[1] #481: ISAKMP_v2_IKE_AUTH message response with Message ID 1 has no matching SA"

Phase 2 Negotiations

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:

  • Type —Encapsulating Security Payload (ESP). ESP encrypts the data and protects against spoofing and packet manipulation (replay detection).
  • Authentication — Authentication makes sure that the information received is the same as the information sent.
  • Encryption — Encryption keeps the data confidential.
  • IPSec Session Key Lifetime — To make sure Phase 2 encryption keys change periodically, specify a lifetime.

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.

Phase 2 Issues (IPSEC)

  • Wrong Encryption:
    (This could be the same for DH Group and authentication as well.
    VPN Connect Log Message: " \"301846360\"[1] #466: no local proposal matches remote proposals 1:ESP:ENCR=DES(UNUSED);ESN=DISABLED"

Verification Using TCPdump

Troubleshooting command for the remote side of the host: (Example below variations could be different)

tcpdump -i ens3 host –l

16:04:08.753493 IP > private.sub04291536181.vcnvpn.oraclevcn.com: ICMP echo request, id 8317, seq 40, length 64

16:04:08.753508 IP private.sub04291536181.vcnvpn.oraclevcn.com > ICMP echo reply, id 8317, seq 40, length 64

16:04:09.754373 IP > private.sub04291536181.vcnvpn.oraclevcn.com: ICMP echo request, id 8317, seq 41, length 64

16:04:09.754421 IP private.sub04291536181.vcnvpn.oraclevcn.com > ICMP echo reply, id 8317, seq 41, length 64

16:04:10.756579 IP > private.sub04291536181.vcnvpn.oraclevcn.com: ICMP echo request,

Additional References and Links



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


Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha