Troubleshooting IPSec VPN Connections using IKEv2 in OCI

March 13, 2024 | 4 minute read

Raffi Shahabazian

Principal Cloud Network Architect

Text Size 100%:

－＋

Introduction

IPSec VPN has been around for decades and its no surprise that it is still being used today to establish a secure and inexpensive method of connecting two sites together in a relatively quick manner.

When troubleshooting with IPSec VPN connections, it is important to understand the various parts of the IPSec VPN connection in order to efficiently troubleshoot to establish or restore connectivity.

IPSec VPN connections get established when the following items are properly configured:

In this blog, we will discuss the common troubleshooting methods to diagnose and resolve an IPSec VPN connection issue dealing with IKE (phase 1). Below is an example of common IKE (phase 1) issues we generally see, the methods we can use in OCI to identify the issue, and the methods used to resolve these issues:

CPE IKE Identifier mismatch
IKE version mismatch
IKE pre-shared key mismatch
IKE cipher suite mismatch

CPE IKE Identifier Mismatch

If the CPE is behind a NAT, we will need to provide the CPE private IP address for the IKE Identifier when configuring a CPE in the OCI console. Otherwise, the public IP address of the CPE will be its IKE identifier. If there is a mismatch, the OCI console logs will provide a message indicating that we require IKEv2 peer to have ID '10.0.0.11', but peer declares '10.0.0.12' followed by a set ikev2 invalid ike id error and encountered fatal error in state STATE_PARENT.

ike identifier mismatch 1

We will also notice that the Tunnel Security Associations will also display a message indicating PARENT SA not established: mismatch of IKE ID setting (IKEv2).

ike identifier mismatch 2

We will also see the Tunnel id down with an error indicating IKE SA not established.

ike identifier mismatch 3

In order to resolve this issue, ensure you are using the correct CPE IKE Identifier when configuring the CPE.

IKE Version Mismatch

IPSec VPN connections in OCI support IKEv1 and IKEv2 for their phase 1 protocols. It is imperative for both sites of the IPSec VPN connection to match the version of IKE being used to properly establish the first phase of the connection. If we have the versions mismatched, we will notice the following error messages and log files within the OCI console that should help us isolate the issue.

ike version mismatch 1

Within the OCI console logs, we will also see the following log messages cycling through initiating IKEv2 IKE SA to deleting state.

ike version mismatch 2

In order to resolve this, ensure that the IKE versions are matching on both IPSec Connection VPN sites.

IKE Pre-Shared Key Mismatch

If the pre-shared key is mismatched between the sites, we will notice that the state of the tunnel and the Tunnel security associations are down. The OCI console logs will display a message indicating PARENT SA not established - verify shared secrets, IKE ID, ESP options, or subnet setting (IKEv2).

ike key mismatch 1

ike key mismatch 2

In order to resolve this, ensure that the pre-shared key match on both IPSec VPN connection sites.

IKE Cipher Suite Mismatch

If the cipher suite is mismatched between the sites, we will notice that the state of the parent SA will within the logs will display an attempt to initiate the IKE SA and we will receive a message indicating received unauthenticated v2N_NO_PROPOSAL_CHOSEN - ignored followed by a set ikev2 error <14> message:

ike cipher mismatch 1

In order to resolve this, ensure that the IKE cipher suites match on both IPSec VPN connection sites.

In summary, these are the common misconfigurations that typically are the reasons why phase 1 fails for IKEv2 in OCI along with their associated error messages in the OCI console.