Troubleshooting Client VPN with Packet Captures
Click 日本語 for Japanese
Purpose and overview
This article provides best practices for using packet captures to troubleshoot client VPN connection issues on Cisco Meraki MX WAN appliances. It covers expected behavior and troubleshooting steps for each phase of the VPN negotiation process.
This article assumes Internet Key Exchange version 1 (IKEv1) is using Main Mode and not Aggressive Mode. Aggressive Mode is not recommended on MX 14 and earlier firmware versions due to known security flaws in the protocol. Aggressive Mode is not supported for client VPN on MX 15 and later firmware versions.
Negotiation process
Client VPN connections are negotiated with the following process:
The guide below provides guidance on using a WAN packet capture to troubleshoot failures in this process.
Understanding the WAN packet capture
Filter the WAN pcap for the client’s public IP and ISAKMP/ESP, if necessary. Look for the ISAKMP “Next payload” field, which identifies the negotiation step. Start at the first “Security Association” from the client.
Troubleshooting ISAKMP phase 1 issue
ISAKMP Phase 1 establishes a secure channel through a two-step exchange: a Security Association and a Key Exchange between the initiator (client) and the responder (MX).
Phase 1 uses UDP 500. Phase 2 uses UDP 500 or UDP 4500 for Network Address Translation Traversal (NAT-T).
Possible causes
-
Incorrect destination IP or MAC address
-
Port forwarding configured on the MX for port 500
-
Client attempting to connect from behind the same MX
-
Client public IP matches a non-Meraki VPN peer IP or another currently connected VPN client
-
Extra configuration options manually applied to the MX that override default client VPN settings
-
Incorrect pre-shared key
-
Port 4500 traffic being dropped or filtered before reaching the client
Troubleshooting steps
Step 1: Security association
The initiator sends a Security Association, and the responder sends a Security Association response. If the MX does not respond to the client, verify the following:
-
The destination IP and MAC addresses (or virtual IP address (VIP) for warm spare) are correct.
-
Port forwarding is not configured on the MX for port 500.
-
The client is not trying to connect from behind the same MX.
-
The client public IP does not match any non-Meraki VPN peer IPs or another currently connected VPN client.
-
No extra configuration options have been manually applied to the MX that would override default client VPN settings.
If both sides are continually sending Security Association packets, port 500 traffic may not be reaching the client.
Step 2: Key exchange
The initiator sends a Key Exchange, and the responder sends a Key Exchange response.
If one side is continually sending Key Exchange packets, one of the following problems may be the cause:
-
Incorrect pre-shared key.
-
Port 4500 traffic required to initiate Phase 2 is being dropped or filtered and is not reaching the client.
Troubleshooting ISAKMP phase 2 issue
ISAKMP Phase 2 completes the VPN negotiation through an Identification exchange and a Hash exchange between the initiator and responder.
Phase 2 uses UDP 4500 (NAT-T) or, in some cases, UDP 500.
Possible causes
-
Incorrect encryption or authentication settings
-
Incorrect subnet definition (site-to-site VPN only)
-
Misconfigured VPN settings on the client device
Troubleshooting steps
Step 1: Identification
The initiator sends an Identification packet, and the responder sends an Identification response.
Step 2: Hash
The initiator sends a Hash packet, and the responder sends a Hash response.
If both sides are continually sending Phase 2 packets, this might indicate one of the following problems:
-
Incorrect encryption or authentication settings
-
Incorrect subnet definition (site-to-site only)
-
VPN settings on the client device; for more information, refer to the Client VPN OS Configuration
In some cases, /var/log/racoon.log or /var/log/strongswan.log may provide additional information
Troubleshooting ESP and authentication issue
If bidirectional ESP traffic is visible in the packet capture, the tunnel is up and user authentication occurs at this step. The WAN packet capture is no longer useful past this point, because all traffic is encrypted.
Possible causes
-
Authentication credentials not configured correctly in the dashboard
-
Authentication server unreachable or misconfigured
-
Client not sending credentials
-
Misconfigured VPN settings on the client device
-
IP pool for the client VPN subnet exhausted
Troubleshooting steps
Verify whether authentication is successful between the MX and the authentication server.
-
Meraki cloud authentication
Verify the following:
-
The MX WAN port can resolve meraki.com via DNS, and all required cloud connections are allowed on upstream equipment. For more information, refer to the Upstream Firewall Rules for Cloud Connectivity.
-
The account is authorized for client VPN in the dashboard and the password is correct.
RADIUS authentication
Verify the following:
-
RADIUS authentication packets sent between the MX and the server result in an ACCESS-ACCEPT response for a successful connection.
-
The RADIUS server event log shows the expected results. For more information, refer to the RADIUS Issue Resolution Guide.
-
Active directory authentication
Verify the following:
-
Active Directory packets sent between the MX and the server show a successful TLS connection.
-
The Active Directory server event log shows the expected results.
-
All authentication types:
For all authentication types, verify the following:
-
If no authentication logs or packets are visible, the client may not be sending credentials. The client may need to verify VPN settings. For more information, refer to the Client VPN OS Configuration.
-
If the problem affects only one client, troubleshooting at the client machine may be required, such as rebooting or checking for conflicting software.
-
If authentication is successful but the client still fails to connect, verify that the IP pool for the client VPN subnet is not exhausted.