When a VPN goes down with a "Peer not responding" message, the root cause can be anything from a network outage to a missing or misconfigured firewall rule.

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 or a route table has been changed.

Cause

Unlike other endpoints, whose reachability can be verified with commands like ping, you can’t really verify VPN connectivity outside of the VPN itself. IPsec uses UDP, so you either get a response from the peer or you don’t. Ping reachability depends on whether the peer has enabled it, and many don’t.

Solution

  1. Ensure the remote IP address configured in the VPN matches the IP the peer is listening on.
  2. Ensure any firewalls on the remote (on-premises) site are configured to allow traffic to UDP port 500. If the remote endpoint is NATted, firewalls on the remote site must allow traffic to UDP port 4500.
  3. IPsec VPN traffic uses multiple protocols, all of which must be allowed through the firewall.
    These include:
    • ESP (Encapsulating Security Payload) IP protocol 50
    • AH (Authenticating Header) - IP protocol 51
    • ISAKMP (Internet Security Association and Key Management Protocol which in turn uses IKE and IKE v2 (Internet Key Exchange)
  4. Ensure that the same IKE version is configured for both endpoints.
  5. Ensure that routing is in place for each side to reach each other.
    This can be validating using traceroute, but end to end path validation is not always possible as many endpoints will not respond to standard ICMP Echo (ping) or traceroute requests. When you configure the SDDC VPN Local IP Address as Public, VPN traffic will always flow over the SDDC Internet Gateway. Otherwise (when the VPN Local IP Address is Private), VPN traffic flows over the SDDC Intranet uplink. Be sure that the remote side of the VPN sends reply traffic over the same path.