Troubleshoot Anypoint VPN
These are some of the possible errors you may encounter when attempting to connect Anypoint VPN.
If you are unable to connect to the Anypoint VPN, ensure any firewalls that are configured are allowing traffic through the IP addresses in the
localExternalIpAddress field in the VPN tunnels.
This is likely due to a problem with your Phase 1 configuration. Anypoint VPN connections support only IKEv1, meaning IKEv2 doesn’t work.
Phase 1 Diffie-Hellman (DH) groups that are supported include 2, 14-18, 22, 23, and 24.
It is possible that your Phase 2 DH group is not supported. Phase 2 DH groups that are supported include 2, 5, 14-18, 22, 23, and 24.
The VPC route table is not updated until the tunnels are active. When using static routing, the remote networks are added to the route table when the tunnel is active, and removed when the tunnel is inactive. This is the expected behavior. When using BGP routing, the routes are propagated from your VPN endpoint when the tunnel is active. If the route table does not show the required entries, ensure that the BGP session is active and validate the BGP configuration on your device.
Ensure that the neighbor IP address for the tunnel is taken from the Local point-to-point IP address in the tunnel’s details.
The VPN connection supports only one security association (SA) pair per tunnel, so any more than one traffic selector per connection will cause unexpected results.
To solve this, ensure that only one unique SA is used per VPN tunnel connection. If more than one policy is needed, you must consolidate and filter traffic in your network.
IPsec is established by sending "interesting traffic" (traffic that should be encrypted over the Anypoint VPN connection). If there is no interesting traffic, the tunnel disconnects. This is the expected behavior, and the timeout value might vary.
Some VPN configurations require additional steps to keep the tunnel active, which means you need to ensure you periodically send interesting traffic. For example, sending ICMP requests every 5 seconds to a CloudHub worker’s internal IP address or FQDN will keep the tunnel active.
Because the time to retrieve the tunnel status includes the inherent delay in the infrastructure-provider API, you can expect delays of up to five minutes when reporting the correct status. Do not use this information to trigger a failover between the tunnels. Instead, monitor tunnels at the customer-side VPN gateway.