The anyconnect ask command specifies how the anyconnect client will be installed on the user’s computer. The none default anyconnect part tells the ASA not to ask the user if he/she wants to use WebVPN or anyconnect but just starts the download of the anyconnect client automatically. The anyconnect dpd-interval command is used for Dead Peer. AnyConnect by Cisco is a robust VPN tool built for a large-scale company in mind. Cisco offers several options for businesses that wish to subscribe to its VPN services, including both term (1. Cisco VPN server list: Defend your privateness Cisco VPN server list study was matured to provide. The best way to know if a Cisco VPN server list will run for you is to try engineering verboten in your own home. Conceive if you dismiss access partly the sites and services that you need. Acquire safe if the interface is usable, and if the speeds metallic element your surface area area unit.

• Cisco Anyconnect Server List
• Cisco Anyconnect Profile Settings

The AnyConnect troubleshooting guide has been broken down into scenarios to help administrators identify and resolve issues quickly. Please refer to the troubleshooting steps highlighted in the scenario that best identifies with the issue you may be facing. In as much as we cannot account for all possible scenarios, we will continue to update this guide with common issues and resolutions.
AnyConnect configuration guide

Scenario One: No log-in prompt

1. MX is running wrong the firmware version.
   Ensure your MX is running the right firmware version. The firmware section on the Appliance Status page should say MX 16.X version. If your MX is still running MX14 or 15, please contact Meraki Support to get your MX upgraded.

2. The connection request did not make it to the MX (AnyConnect server).
   If your MX is behind a router or firewall device, ensure traffic is forwarded to your MX, as requests from the AnyConnect client could be reaching the upstream router or firewall device but not your MX (AnyConnect server). Take a packet capture on the WAN to validate if it is an upstream issue.
   If you are using a port other than the default 443, eg. 1443, ensure the new port is appended to the end of the DDNS hostname with a colon like this 'xyz.dynamic-m.com:1443'
   

Scenario Two: Authentication fails

1. Wrong AnyConnect client version: You receive the error message “The AnyConnect package on the secure gateway could not be located' when authenticating.
   
   This error message is seen when a user tries to connect with an AnyConnect client version 4.7 or lower. The MX only supports TLS 1.2, hence you need AnyConnect client version 4.8 or higher to connect to the MX (AnyConnect server).

2. Unable to connect due to captive portal
   This error message is usually seen when there is a captive portal enabled on the network the user is connecting from. A possible workaround is to disable captive portal detection under the AnyConnect client preferences.
   

3. Wrong username/password combination.
   Look at the event log and filter by 'AnyConnect authentication failures' and try testing with different username and password or try updating your credentials.

4.Authentication server is down or not responding.
When authenticating with RADIUS or Active Directory (if offline), after entering your username and password, your AnyConnect client will look like screenshots below. When the RADIUS or AD server responds immediately with authentication failure, the user will get a prompt to reenter their password immediately. If the user does not get a prompt to reenter their credentials, the server is not responding or the response from the server is not making it back to the MX for some reason. You may even see error messages indicating an issue with the server certificate, although the issue really is that the Active Directory or RADIUS server did not respond to the authentication request.

• Ping the RADIUS or AD server to see if it is online
• Ensure your MX is listed as a RADIUS client, if authenticating via RADIUS
• Take a packet capture on LAN/VPN/WAN depending on where the authentication server resides to see if authentication requests and replies are seen been the MX and the authentication server

5. Connecting to the wrong device?
Verify you are connecting to the right device via the right public IP/Port or hostname.

Scenario Three:Untrusted server message

When AnyConnect is configured on your MX, it generates a temporary self-signed certificate to start receiving connections. Then the MX initiates enrollment for a publicly trusted certificate; this will take about 10 minutes after AnyConnect is enabled for the certificate enrollment process to be completed. If you try to make a connection before a publicly trusted certificate is available, you will see the “Untrusted Server Certificate” message. Once the public certificate enrollment is complete, the AnyConnect server will swap out the self-signed certificate with the publicly trusted certificate.
What if the user continues to get an 'Untrusted Server Certificate' message 10 minutes after the AnyConnect was enabled?

• Ensure the device is online on Dashboard
  

• Ensure Dynamic DNS is enabled and resolves to the MX IP
  
• Ensure you are connecting with the DDNS hostname not the IP of the MX. Connecting with the IP will throw off certificate error even if there is a publicly trusted certificate on the MX
  
• Connect to the MX with different devices to see if they all report the MX as an “Untrusted Server.” Devices should have QuoVadis root CA certificates by default. If this is seen on some devices, check the Trusted CA folder on your client device. If you do not see the QuoVadis root CA certificates, you should update your browser to the latest version
  
• In rare cases, you may need to download the Root CA certificate and push it to the end device in order for it to trust the AnyConnect Server certificate. To identify what Root CA to download, try connecting to the DDNS hostname or IP of the MX, when the Untrusted Server message pops up, click details, look at the Issuer field to identify the Root CA required. The Root CA certificate can then be downloaded from https://au.quovadisglobal.com/Repository/DownloadRootsAndCRL.aspxand pushed to the client

Scenario Four: Connected, but no access

1. Check traffic settings on MX or routes on your AnyConnect client.

Check the route details on your client to ensure you have secure routes to the destination you are trying to get to. If you don’t have the necessary routes, you will need to modify the traffic setting on the AnyConnect Settings page and reconnect to the AnyConnect server to update your routes.

Cisco Anyconnect Server List

2. Firewall rules or group policy.
   Check the firewall rules on the MX to ensure traffic is not being blocked from your AnyConnect client IP or subnet to the destination you are trying to get to.

3. Take packet captures on the AnyConnect VPN interface.
   Packet captures can be taken on the AnyConnect VPN interface to verify if traffic is making it to the MX. To take packet captures, navigate to:
   Dashboard > Network > Packet captures > Select AnyConnect VPN interface.
   

Cisco Anyconnect Profile Settings

Scenario Five: Connected with limited access

1. Check traffic settings on MX or routes on your AnyConnect Client
   Check the route details on your client to ensure you have the secure routes to the destination you are trying to get to. If you don’t have the necessary routes, you will need to modify the traffic settings on AnyConnect Settings page and reconnect to the AnyConnect server to update your routes.

2. Take packet captures on the AnyConnect VPN interface.
   Packet captures can be taken on the AnyConnect VPN interface to verify if traffic is making it to the MX. To take packet captures, navigate to:
   Dashboard > Network > Packet captures > Select AnyConnect VPN interface.
   

Scenario Six: Group policy not working

1. Please note that this policy does not show up on the Client Details page, hence don't rely on the client list. Pass traffic on the client device to see if the policy applied works as expected. If you have a combined network that includes Meraki Wireless, this policy will be displayed in the 802.1X column on the client list.

2. Ensure the RADIUS attribute is being passed by the RADIUS server to the MX by taking a packet capture and looking at the RADIUS accept message.

3. Ensure the value being sent by the RADIUS server matches what is configured on dashboard.

4. Look at the AnyConnect session event on the event log to see if/what policies are applied to a user.

Scenario Seven: Tunnel drops intermittently

We have seen reports of tunnel drops specifically within the first few minutes after connecting to the MX.
1. Verify what protocol is being used, TLS or DTLS. Usually customers report tunnel drops when their client is unable to successfully negotiate a DTLS tunnel. Ensure both TCP and UDP (443 or the port AnyConnect is configured to listen on) are open on your upstream firewall to receive connections.
Below we see the AnyConnect port on the AnyConnect Settings page on the dashboard is set to port 443. Hence, if your MX is sitting behind another firewall on your network, ensure TCP and UDP port 443 are both permitted to communicate with the WAN IP of your MX.

Below, the protocol on the VPN > Statistics tab of the AnyConnect client shows DTLSv1.2. This means the client was able to negotiate TLS (TCP) and DTLS (UDP) successfully.

2. Ensure, there is no packet loss on the WAN of the AnyConnect server (look at Appliance status > uplink tab > loss graph). On the client side, try connecting with a different medium, e.g. wired vs. wireless or cellular vs. cable).