VPN authentication errors are typically caused by a configuration mismatch between the SDDC and on-premises VPN endpoints. While these typically prevent the VPN from coming up at creation, they can also bring down a working VPN when one of the endpoints is reconfigured.

Problem

A new VPN fails to come up after creation, or a working VPN fails after one of the ends has been updated or reconfigured.

Cause

IKE negotiation has two phases:
  • In Phase 1, the peer endpoints establish an IKE Security Association (SA), which provides a secure channel for communication between the endpoints.
  • In Phase 2, the endpoints use the SA to negotiate a key exchange using the pre-shared key you entered when you created the VPN.
Phase 1 errors can arise when the Remote ID and Local ID values are inconsistent. Phase 2 errors can arise when the peers are configured with different pre-shared keys.

Solution

  1. Verify that the pre-shared key is exactly the same on each side. Be sure to check for the presence of whitespace on either end of the key string.
  2. If you use special characters in the pre-shared key, try using a pre-shared key that does not contain special characters, in case one side does not correctly interpret them.
  3. Ensure that the Remote ID on each side matches the Local ID used by the peer. Normally this will be the public IP address, but when one side is behind a NAT router, it may instead use its private IP, which will need to be manually entered as the Remote ID on the peer’s configuration. This ID forms part of the authentication so a mismatch will result in an authentication error.
  4. Ensure that the same IKE version is configured for both endpoints. VMware Cloud on AWS VPNs also provide an IKE FLEX version that should be compatible with either IKEv1 or IKEv2.
  5. Ensure that the same IKE mode is configured for both endpoints. VMware Cloud on AWS VPNs do not support IKE Aggressive mode.