Home > Security and SD-WAN > Client VPN > Troubleshooting Client VPN

Troubleshooting Client VPN

This article outlines troubleshooting methods for Client VPN connectivity issues, primarily for Windows-based clients, including a list of common errors. This article also outlines some common issues and solutions for accessing resources over Client VPN. For configuring Client VPN on OS devices, please refer to our Client VPN OS Configuration documentation.

Determining the Cause of Connection Issues

Questions you can start asking to determine the cause of the issue include:

  • Has this connection ever worked before?
    • If the connection has never worked before...
      • It is most likely that your client's VPN connection settings don't quite match (if it's one client), or that your MX may not be receiving/approving connections (if many users are experiencing the issue). Check the Common Connection Issues below to gather more information on which piece is out of place
    • If the connection used to work...
      • If the client is on Windows, check the Windows software update section. Otherwise, verify whether the MX is accepting requests from other clients
  • Are all users experiencing the issue, or only specific users?
    • If all users are experiencing the issue...
      • Is the MX online and connected to the Meraki Cloud? If so, is the MX receiving Client VPN requests? Check the event log, and take a packet capture to see whether any traffic is detected
    • If the problem is only affecting one user, or some specific users...
      • Try the connection on two different devices or operating systems, such as MacOS and Windows. There may be an OS configuration issue. Verify the configuration matches the settings in the Client VPN OS Configuration document
      • If it is only Windows that can’t connect to VPN, have you performed a Windows update recently? Windows software may affect Client VPN configurations and connectivity. The client configuration may need to be reset
  • Is the client's connection request reaching the MX?
    • To determine whether the client's connection attempt is reaching the MX...
      • Check the event log, using the filter Event type include: All Non-Meraki/Client VPN. Check whether the client's request is listed
      • Take a packet capture on the MX, using the Client VPN interface. Check whether there is any traffic seen when the client attempts to connect
  • Have you recently made any changes to your MX or upstream firewall that can affect Client VPN?
    • If you've changed any major MX configuration settings, it's possible your Client VPN service has turned off, or setting have changed. Check that your MX settings match your client config
    • If your MX has failed over or changed IP address, make sure your clients are connecting using a dynamic hostname, rather than the MX IP address
    • Upstream firewalls (if used) will often interfere with Client VPN connections. Make sure your firewall is forwarding traffic on TCP 443 and UDP 500 and 4500 to allow full authentication and VPN traffic

Common Connection Issues

Username, password or shared secret is typed in incorrectly

  • This is the most common reason for failed connectivity. Try deleting your connection configuration entirely and starting again. Be sure to verify all credentials carefully.
  • If you are unsure what the user credentials should be (username, password), verify your authentication method and check your clients list for more information.
  • If you are unsure what the shared secret should be, you can check it by selecting Show secret in the dashboard on the Client VPN page.
  • If you are unsure what the client configuration settings should be, check the documentation, Client VPN OS Configuration.

Incorrect MX IP address is specified

  • Consider enabling Dynamic DNS and using the hostname (e.g. '.com') rather than the MX IP address for connecting to the VPN. You can find your MX hostname on the Security & SD-WAN > Appliance status page.
  • If you are using an IP address to connect, verify that you’re attempting to reach the MX at the correct IP address. You can verify the MX IP address by going to the Security & SD-WAN > Appliance status page in the dashboard.
  • If you have two uplink connections, when the uplink fails over from primary to secondary, the MX IP address may change, which would cause the MX VPN connection to no longer work if configured to use the primary MX IP address.

Windows software update

  • Windows updates will often cause Client VPN connectivity issues, and devices that have previously been working may get rejected. Re-configure the settings on the client device, following the Client VPN OS Configuration documentation

The MX is not receiving the Client VPN connection attempt

  • Look at the event log page, using the filter Event type include: All Non-Meraki/Client VPN. Check whether the client's request is listed. If there is no connection attempt going through to the MX, it is possible that the Internet connection that the end user is on may have blocked VPN. If this is the case, you may need to check the access control and firewall settings upstream of the client.
  • If the event log is not clear, take a packet capture on the MX, using the Client VPN interface. Check whether there is any traffic seen when the client attempts to connect

RADIUS/Active Directory connection failed (only for RADIUS/AD Authentication)

  • Check your server. Check your logs to determine whether the server is receiving RADIUS/AD requests, and whether it is responding to them. If requests are being denied, you may need to check your server configuration, or check the credentials on your client device.

User is not authorized to connect to VPN (only for Meraki Cloud Authentication)

  • If you are using Meraki Cloud authentication, or Systems Manager authentication, it is possible the user attempting to connect is not authorized for VPN access. Add the user or change the VPN permissions of the user on the User management section on the Client VPN page. Their account should say Authorized for Client VPN > Yes.

 

Configuration Requirements

Client Device

Please reference our documentation for instructions on Configuring Client VPN on the Client Device.

Encryption Method

Client VPN uses the L2TP/IP protocol, with 3DES and SHA1 respectively as the encryption and hashing algorithms. As a best practice, the shared secret should not contain any special characters at the beginning or end.  

MX-Z Security Appliance

Please see the following link to configure the MX-Z for Client VPN. If the MX-Z sits behind another NAT device or firewall, please make sure that the following UDP ports are forwarded/allowed to the MX-Z:

  • UDP 500 (IKE) 
  • UDP 4500 (IPSec NAT-T)

Note: Since the MX is the device communicating from UDP 500/4500, those ports need to be forwarded on any devices upstream of the MX, not on the MX itself.

Verifying a Successful Connection

There are three primary ways to determine if the Client VPN connection is successfully connected to an MX:

  • Check the device for connection status using common network utilities (this will vary depending on the operating system being used). The Event Log contains entries each time a client connects or disconnects from Client VPN. These logs can be viewed from Monitor > Event log. Deselect all event categories except VPN followed by clicking on the Search button. Client VPN logs will have one of two Event types: VPN client connected or VPN client disconnected. Here is an example set of log messages that shows a client connecting and then disconnecting from Client VPN:
Jun 27 12:24:53 05:00:08:ab:cd:ef VPN client disconnected remote_ip: 174.X.X.X, user_id: administrator, local_ip: 192.168.100.239 
Jun 27 12:24:38 05:00:08:ab:cd:ef VPN client connected remote_ip: 174.X.X.X, user_id: administrator, local_ip: 192.168.100.239
  • The client list can also be used to see if a client is currently connected to Client VPN.  Browse to Monitor > Clients in the Dashboard.  Add an additional column by clicking on the + button and select MAC address.  Clients can then be filtered by 'N/A (Client VPN)' as the MAC address.  

Common Connection Error Codes

This section of the article will outline common configuration errors and the resulting Event log message/client error message.  

Note: If your Windows device is failing to connect to the VPN, it is recommended that you verify the VPN configuration on your device to ensure it matches the Client VPN OS Configuration requirements.

Finding Error Codes in Windows

If a Client VPN connection is failing to establish from a Windows devices but no error message appeared on the screen, the Event Viewer can be used to find an error code associated with the failed connection:

  1. Press the Windows key and type in "Event Viewer," then click on Event Viewer in the search results.
  2. In Event Viewer, navigate to Windows Logs > Application.
  3. A Client VPN connection failure should show up as an Error event type. Clicking on the event will show the associated error code:

This Microsoft knowledge base article lists error codes and their meanings.

Windows Error 789

2b67656b-f4d8-4355-bc70-4a44a3f3850f

Example event log entries:

Jul 2 13:53:20 VPN msg: invalid DH group 19.
Jul 2 13:53:20 VPN msg: invalid DH group 20.

 

This issue may also result in no event log messages, if the client's traffic doesn't successfully reach the MX's WAN interface.

Possible causes and solutions:

  • Incorrect secret key (pre-shared key in Windows)
    Solution: Ensure that the shared secret is configured correctly on the client machine. It must match between the MX and the client. More information about setting the shared secret can be found in the links at the top of the page.
  • Firewall blocking VPN traffic to MX
    Solution: Ensure UDP ports 500 (IKE) and 4500 (IPsec NAT-T) are being forwarded to the MX and not blocked. If traffic cannot reach the MX on these ports, the connection will timeout and fail.
  • IKE and AuthIP IPsec Keying Modules disabled (Windows only)
    Solution: This occurs most often when 3rd party VPN software has been installed and disables the IKEEXT service. This can be re-enabled by navigating in Windows to Control Panel > Administrative Tools > Services. Find the service named "IKE and AuthIP IPsec Keying Modules" and open it. Change the Startup type to "Automatic". If this automatically reverts to "Disabled" or fails to start, it may be necessary to remove the 3rd party VPN software:
    0c0475d2-82a7-4b3e-8e5d-5a58f5625304

 

Windows Error 691

9ce2dd1d-4fdc-4884-94cc-3d1966eb9498

Example event log entries:

Jul 2 14:00:40 VPN msg: not matched 
Jul 2 14:00:40 VPN msg: ISAKMP-SA established 82.35.46.78[4500]-174.45.35.220[4500] spi:b74e92b3b5360c16:ce602504804696a9

 

Possible causes and solutions:

  • Invalid user credentials
    Solution: Confirm user credentials are correct. When using Meraki authentication, usernames should be in e-mail format (ex. user@example.com). When using AD or RADIUS authentication, be sure to enter the username in a format that will be recognized by the server, including the domain if needed (ex. DOMAIN\user).
  • User not authorized
    Solution: If using Meraki Authentication, ensure that the user has been authorized to connect to the VPN.
  • No certificate on AD server
    Solution: If using Active Directory authentication with Client VPN, make sure the AD server has a valid certificate for TLS.
  • Incorrect DNS name resolution from the MXs upstream DNS server

        Solution: If the MX is configured with an ISP DNS server, change this to a Non-ISP public DNS server such as Google 8.8.8.8

  • Alternatively, this message can be caused when a mismatch of pre-shared secrets between a RADIUS server and MX results in bad encryption of the password. Test this by changing the pre-shared secret in Dashboard and for the RADIUS client on the server to something simple, such as "Meraki". If the error disappears, verify the secret used is correct on both devices, and simplify the password if needed. 

Windows Error 809

If this error appears, the Event Log won't have any relevant logs, as the traffic doesn't reach the MX's WAN interface.

 

Possible causes and solutions:

  • Client behind NAT devices
    Solution: Modern Windows devices do not support L2TP/IPsec connections when the Windows computer or VPN server are located behind a NAT. If the Windows VPN client fails with Error 809 when trying to establish a VPN connection to an MX located behind a NAT, add the "AssumeUDPEncapsulationContextOnSendRule" DWORD value to the Windows registry. This DWORD value allows Windows to establish security associations when both the VPN server and the Windows based VPN client computer are behind NAT devices.
     

    For Windows XP:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec

    RegValue: AssumeUDPEncapsulationContextOnSendRule

    Type: DWORD

    Value data: 2
    Base: Decimal

 

  • For Windows Vista, 7, 8, 10, and 2008 Server:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent 

    RegValue: AssumeUDPEncapsulationContextOnSendRule

    Type: DWORD

    Value data: 2
    Base: Decimal
     

    Note that after creating this key you will need to reboot the machine. For more information, reference the Microsoft Support Knowledge Base.

Note: Some third party network programs can also Windows Error 809 to occur. SmartByte is one such program known to cause this issue. Disabling the program should resolve the issue and allow the VPN to connect.

IPv6 and Mobile Devices

Sometimes the event log will log the message, "msg: unsupported ID type 5." If the identification field value is 5 in the identification payload, this means the payload is carrying the ID type 'ID_IPV6_ADDR.' Meraki does not currently support ID type 5, so an error will appear for these ISAKMP messages. This message will appear for devices that do not have an IPv4 address assigned to them directly, and, as such, are reliant upon an IPv6 transition mechanism like NAT64 to reach the Internet. Such devices will not be able to connect to our Client VPN solution at this time.

Connections to Clients with Dual NICs

Sometimes a user's endpoint utilizing the Client VPN connection may have connection issues to LAN endpoints that have dual NICs. Oftentimes LAN endpoints have both a WAN and a LAN NIC. If these devices are unpingable from an endpoint connected vial Client VPN, check the routes on the LAN endpoints. In Windows, open the command prompt and type the command "route print". In macOS, open up the terminal and type the command "netstat -nr". Check that there are gateways set for the LAN routes and not just the WAN.

Other Problems

Client VPN on Cisco Meraki devices uses the L2TP over IPsec standard, which is supported out-of-the-box by the majority of client devices. If a client is unable to establish a VPN connection, resulting in an error code not discussed in this article, it is recommended to first check for OS-specific documentation about that error. From there, ensure that the client has been configured correctly, and has a network connection to the MX that is not filtering UDP ports 500 or 4500. It may also be helpful to confirm with a packet capture that the client's traffic is reaching the MX.

 

If the MX is in a Warm Spare configuration, the virtual IP for the uplink will have to be used on the client device for the destination server address.

Problems Accessing Network Resources

Occasionally, end users will report that their Client VPN connection is not working, but this does not necessarily mean there is a problem with the Client VPN tunnel; the client may simply be unable to access the network resource(s) they want.

The following sections outline steps to diagnose and fix problems with Client VPN users accessing network resources. 

Verify VPN Connectivity

The first troubleshooting step should be verifying that the Client VPN connection is established, and passing traffic to the MX. Active Client VPN users can be seen on the Monitor > Clients page, and can be found by IP address or MAC address (will appear as "N/A (Client VPN)). The event log also records each time a user connects and disconnects to the MX using Client VPN.  

Open a command prompt or terminal on the Client VPN device, and ping the LAN IP address of the MX. The LAN IP address can be found on theConfigure > Addressing & VLANs page in Dashboard.  Choose an MX IP address from a VLAN that is configured to participate in VPN. In this example the MX has a LAN IP address of 192.168.10.1:

Test Connectivity to Resources

At this point it has been verified that the Client VPN session is established and working.  From a command prompt or terminal, ping the IP address of the resource the client are trying to use.  Keep in mind that the device the client is trying to reach may not respond to ICMP, so it is useful to test pinging other devices over the VPN that do respond to ICMP.  Here, connectivity is tested to a file server that has a LAN IP address of 192.168.10.3:

If the network resource does not respond to ping but the Client VPN tunnel is established, make sure the resource's firewall allows it to respond to requests from the Client VPN subnet configured under Security appliance > Configure > Client VPN. Note that Microsoft's Windows firewall typically blocks communication from unknown private subnets by default.

Testing DNS Resolution

Since client VPN users will not be provided with DHCP option 15, make sure any DNS lookups over client VPN specify the FQDN instead of the Short Name.

Most end users will access resources using hostnames, so also test DNS resolution from a command prompt or terminal.  In this example, fileserver01 should resolve to 192.168.10.3:

Verify the configured DNS servers on the Security Appliance > Configure > Client VPN page.  The default configuration sets the clients DNS server to Google public DNS.

Custom DNS nameservers can also be defined for Client VPN users.  From the DNS nameservers drop down menu, select 'Specify nameservers...' and enter the IP addresses of the desired internal DNS servers.  In this example the IP address of the internal DNS server is 192.168.10.2:

After configuring a custom nameserver, DNS resolution should be functioning properly, so users should be able to reach resources over the Client VPN connection by name:

Resolving NetBIOS names over Client VPN

Windows hosts utilize NetBIOS-based name resolution to locate Windows file and print shares located on other Windows hosts. A NetBIOS name syntax appears as "MYCOMPUTER" and is normally seen in UNC paths such as \\MYCOMPUTER\myfileshare\.

 

NetBIOS name resolution is a layer 2 broadcast based name discovery protocol. Layer 2 broadcasts do not traverse layer 3 boundaries such as the Client VPN interface on an MX.

WINS is a service that provides centralized name resolution of NetBIOS hostnames. NetBIOS clients register their hostnames on the WINS server and other NetBIOS clients query the WINS server to resolve NetBIOS names.

To allow hosts that utilize NetBIOS names to find network resources over Client VPN, specify the IP address of a WINS server in the Client VPN configuration. This is done using the WINS setting on the Security & SD-WAN > Configure > Client VPN page.

In the screenshot below the specified WINS server is 192.168.1.100:

Client VPN Dashboard Configuration.png

Additional Checks

End users may report that they are unable to map network shares over the Client VPN tunnel.  This could be potentially caused by a layer 7 firewall rule configured to block file sharing.  Check the layer 7 firewall rules under Security appliance > Configure > Firewall > Layer 7.  

Also, check any group policies that are applied to the target resource to ensure file sharing is not blocked in the group policy.

Max Sessions per User Account

For security purposes, we limit each user's account to five (5) simultaneous VPN connections to an MX. If you need to change this number, please contact Cisco Meraki Support.

Troubleshooting Client VPN with Packet Captures

Client VPN connection issues can be effectively troubleshot by using packet captures. In this section, best practices and expected behavior in terms of what can be seen in a packet capture will be discussed, and common troubleshooting steps are explained.

Negotiation Process

Client VPN Negotiation Process.png

For any client VPN connection, expect to follow the above process. If the process breaks down at any point, there are some specific things to look for at each step. To start, take a WAN packet capture (on the primary WAN) and follow the guide below.

Understanding the WAN Packet Capture

Client VPN WAN Pcap.png

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 Tips

If no ISAMKP traffic from the client is seen:

  • Verify client is connecting to the primary MX WAN IP (VIP for warm spare)

  • Verify inbound UDP 500 traffic is not being blocked/dropped upstream

  • If the MX is behind a NAT, port forwarding may need to be configured on the upstream device for UDP ports 500 and 4500

  • Some OS-specific behaviors may prevent the client machine from generating any traffic. Try to rule out by testing another device type (e.g. a different OS or smart phone)

ISAKMP Phase 1

1. Security Association

ISAKMP Phase 1 Security Association.png

The initiator sends a Security Association, and the responder sends a Security Association response.

 

2. Key Exchange

ISAKMP Phase 1 Key Exchange.png

The initiator sends a Key Exchange, and the responder sends a Key Exchange response.

Troubleshooting Tips

  • Phase 1 uses UDP 500, Phase 2 uses UDP 500 or UDP 4500 (NAT-T)

  • If the MX doesn’t respond to the client, verify:

    • The destination IP and MAC addresses (or VIP for warm spare) are correct

    • Port forwarding isn’t configured on the MX for Port 500

    • Client isn’t trying to connect from behind the same MX

    • Client public IP doesn’t match any non-Meraki VPN peer IPs or another currently connected VPN client

    • Any extra configuration options manually applied to the MX that would override default client VPN settings

  • If both sides are continually sending Security Association, this may indicate Port 500 traffic isn’t being received at the client

  • If one side is continually sending Key Exchange, this may indicate one of the following problems:

    • Incorrect pre-shared key

    • Port 4500 traffic to initiate phase 2 is being dropped/filtered (not reaching the client)

3. Identification

ISAKMP Phase 2 Identification.png

The initiator sends an Identification, and the responder sends an Identification response

4. Hash


ISAKMP Phase 2 Hash.png

The initiator sends a Hash, and the responder sends a Hash response.

Troubleshooting Tips

  • Phase 2 uses UDP 4500 (NAT-T) or sometimes UDP 500
  • If both sides are continually sending Phase 2 packets, this may indicate one of the following problems:

    • Incorrect encryption/authentication settings

    • Incorrect subnet definition (site-to-site only)

  • The client may need to verify their VPN settings. For additional information on specific OS configuration, please follow this article on Client VPN OS Configuration.

ESP

If bi-directional ESP traffic is seen, the tunnel is up.

  • User authentication happens at this step.

  • The WAN packet capture will no longer be helpful, since everything is encrypted past this point.

  • Verify if the authentication is successful between the MX and the authentication server

Troubleshooting Tips

  • For Meraki Cloud authentication, verify:

    • The MX WAN port can resolve meraki.com via DNS, and all required cloud connections are allowed on upstream equipment. For additional explanation of what Meraki requires for cloud communication, please reference the documentation on upstream rules for cloud connectivity.

    • The account is "Authorized for client VPN" in dashboard, and password is correct

 

  • For RADIUS authentication, verify:
    • RADIUS authentication packets sent between MX and server must result in ACCESS-ACCEPT for successful connection
    • RADIUS server event log, which is explained in the RADIUS issue resolution guide.

 

  • For Active Directory authentication, verify:
    • Active Directory packets sent between MX and server must show a successful TLS connection
    • Active Directory server event log

 

  • For all authentication types:
    • If no authentication logs or packets are seen, the client may not be sending credentials.

      • The client may need to verify their VPN settings.

      • If the problem exists for only one client, troubleshooting may be required at the client machine (e.g. reboot, check for conflicting software)

    • If authentication is successful, but client still fails to connect, ensure the IP pool for the client VPN subnet is not exhausted.
Last modified

Tags

Classifications

This page has no classifications.

Other Languages

Explore the Product

Click to Learn More

Article ID

ID: 1447

Explore Meraki

You can find out more about Cisco Meraki on our main site, including information on products, contacting sales and finding a vendor.

Explore Meraki

Contact Support

Most questions can be answered by reviewing our documentation, but if you need more help, Cisco Meraki Support is ready to work with you.

Open a Case

Ask the Community

In the Meraki Community, you can keep track of the latest announcements, find answers provided by fellow Meraki users and ask questions of your own.

Visit the Community