Cisco Anyconnect Lose Internet Connection

Introduction

This document describes how to allow the Cisco VPN Client or the Cisco AnyConnect Secure Mobility Client to only access their local LAN while tunneled into a Cisco Adaptive Security Appliance (ASA) 5500 Series or the ASA 5500-X Series. This configuration allows Cisco VPN Clients or the Cisco AnyConnect Secure Mobility Client secure access to corporate resources via IPsec, Secure Sockets Layer (SSL), or Internet Key Exchange Version 2 (IKEv2) and still gives the client the ability to carry out activities such as printing where the client is located. If it is permitted, traffic destined for the Internet is still tunneled to the ASA.

Anyone run into this issue with their VPN before using anyconnect? I have a feeling it has to do maybe with a group policy or split tunneling but I've tried going through those options and nothing really stood out to me. Created New Connection profile: RACPA. ASA ver 9.6(1) ASDM ver: 7.6(1) Operating System: WIN 10. Anyconnect WIN-4.2.x. Reboot the computer. Whenever Cisco Anyconnect connects successfully to a network, it will automatically open a command prompt window in the background, silently pinging google.com to receive replies back, thus allowing Network & Sharing Center to detect internet access, and resolve the yellow exclamation. The fix is quite simple actually, go to Network Connections from Control Panel, right-click Cisco AnyConnect Security Mobility Client Connection, and choose Properties. Then disable IPv6, change IPv4 IP settings from Fixed IP to Dynamic. Close all Network Properties dialog boxes, and try VPN connecting again. It should go through fine now. Having big issues with Cisco AnyConnect VPN and Windows 10 1607 using HP laptops (ZBook 15 G3 and 840 G3). I know the root cause is the LAN/WLAN Switching feature. Having this enabled in BIOS results in the wifi being disconnected as soon as the VPN connection is established, since the interface type of the VPN network adapter is 'Ethernet'. Cisco-vpn-client I have a VPN connection set up using the Cisco VPN Client, and whenever I connect to it I lose my internet connection. This is the first time I have used this software, all previous VPNs I have used have been setup through Windows and I can uncheck the 'use remote gateway' box in the TCP-IP properties box to get around this.

Note: This is not a configuration for split tunneling, where the client has unencrypted access to the Internet while connected to the ASA or PIX. Refer to PIX/ASA 7.x: Allow Split Tunneling for VPN Clients on the ASA Configuration Example for information on how to configure split tunneling on the ASA.

Prerequisites

Requirements

This document assumes that a functional remote access VPN configuration already exists on the ASA.

Refer to PIX/ASA 7.x as a Remote VPN Server using ASDM Configuration Example for the Cisco VPN Client if one is not already configured.

Refer to ASA 8.x VPN Access with the AnyConnect SSL VPN Client Configuration Example for the Cisco AnyConnect Secure Mobility Client if one is not already configured.

Components Used

The information in this document is based on these software and hardware versions:

Cisco ASA 5500 Series Version 9(2)1
Cisco Adaptive Security Device Manager (ASDM) Version 7.1(6)
Cisco VPN Client Version 5.0.07.0440
Cisco AnyConnect Secure Mobility Client Version 3.1.05152

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Network Diagram

How to prevent cisco anyconnect from disconnecting

The client is located on a typical Small Office / Home Office (SOHO) network and connects across the Internet to the main office.

Background Information

Unlike a classic split tunneling scenario in which all Internet traffic is sent unencrypted, when you enable local LAN access for VPN clients, it permits those clients to communicate unencrypted with only devices on the network on which they are located. For example, a client that is allowed local LAN access while connected to the ASA from home is able to print to its own printer but not to access the Internet without first sending the traffic over the tunnel.

An access list is used in order to allow local LAN access in much the same way that split tunneling is configured on the ASA. However, instead of defining which networks should be encrypted, the access list in this case defines which networks should not be encrypted. Also, unlike the split tunneling scenario, the actual networks in the list do not need to be known. Instead, the ASA supplies a default network of 0.0.0.0/255.255.255.255, which is understood to mean the local LAN of the client.

Note: When the client is connected and configured for local LAN access, you cannot print or browse by name on the local LAN. However, you can browse or print by IP address. See the Troubleshoot section of this document for more information as well as workarounds for this situation.

Configure Local LAN Access for VPN Clients or the AnyConnect Secure Mobility Client

Complete these tasks in order to allow Cisco VPN Clients or Cisco AnyConnect Secure Mobility Clients access to their local LAN while connected to the ASA:

Configure the ASA via the ASDM or Configure the ASA via the CLI

How To Prevent Cisco Anyconnect From Disconnecting

Configure the ASA via the ASDM

Complete these steps in the ASDM in order to allow VPN Clients to have local LAN access while connected to the ASA:

Choose Configuration > Remote Access VPN > Network (Client) Access > Group Policy and select the Group Policy in which you wish to enable local LAN access. Then click Edit.
Go to Advanced > Split Tunneling.
Uncheck the Inherit box for Policy and choose Exclude Network List Below.
Uncheck the Inherit box for Network List and then click Manage in order to launch the Access Control List (ACL) Manager.
Within the ACL Manager, choose Add > Add ACL... in order to create a new access list.
Provide a name for the ACL and click OK.
Once the ACL is created, choose Add > Add ACE... in order to add an Access Control Entry (ACE).
Define the ACE that corresponds to the local LAN of the client.
1. Choose Permit.
2. Choose an IP Address of 0.0.0.0
3. Choose a Netmask of /32.
4. (Optional) Provide a description.
5. Click OK.
Click OK in order to exit the ACL Manager.
Be sure that the ACL you just created is selected for the Split Tunnel Network List.
Click OK in order to return to the Group Policy configuration.
Click Apply and then Send (if required) in order to send the commands to the ASA.

Configure the ASA via the CLI

Rather than use the ASDM, you can complete these steps in the ASA CLI in order to allow VPN Clients to have local LAN access while connected to the ASA:

Enter configuration mode.
Create the access list in order to allow local LAN access.
Caution: Due to changes in the ACL syntax between ASA software versions 8.x to 9.x, this ACL is no longer permited and admins will see this error message when they try to configure it:
rtpvpnoutbound6(config)# access-list test standard permit host 0.0.0.0
ERROR: invalid IP address
The only thing that is allowed is:
rtpvpnoutbound6(config)# access-list test standard permit any4
This is a known issue and has been addressed by Cisco bug ID CSCut3131. Upgrade to a version with the fix for this bug in order to be able to configure local LAN access.
Enter the Group Policy configuration mode for the policy that you wish to modify.
Specify the split tunnel policy. In this case, the policy is excludespecified.
Specify the split tunnel access list. In this case, the list is Local_LAN_Access.
Issue this command:
Associate the group policy with the tunnel group
Exit the two configuration modes.
Save the configuration to non-volatile RAM (NVRAM) and press Enter when prompted to specify the source filename.

Configure the Cisco AnyConnect Secure Mobility Client

In order to configure the Cisco AnyConnect Secure Mobility Client, refer to the Establish the SSL VPN Connection with SVC section of ASA 8.x : Allow Split Tunneling for AnyConnect VPN Client on the ASA Configuration Example.

Split-exclude tunneling requires that you enable AllowLocalLanAccess in the AnyConnect Client. All split-exclude tunneling is regarded as local LAN access. In order to use the exclude feature of split-tunneling, you must enable the AllowLocalLanAccess preference in the AnyConnect VPN Client preferences. By default, local LAN access is disabled.

In order to allow local LAN access, and therefore split-exclude tunneling, a network administrator can enable it in the profile or users can enable it in their preferences settings (see the image in the next section). In order to allow local LAN access, a user selects the Allow Local LAN access check box if split-tunneling is enabled on the secure gateway and is configured with the split-tunnel-policy exclude specified policy. In addition, you can configure the VPN Client Profile if local LAN access is allowed with <LocalLanAccess UserControllable='true'>true</LocalLanAccess>.

User Preferences

Here are the selections you should make in the Preferences tab on the Cisco AnyConnect Secure Mobility Client in order to allow local LAN access.

XML Profile Example

Here is an example of how to configure the VPN Client Profile with XML.

Verify

Complete the steps in these sections in order to verify your configuration.

Connect your Cisco AnyConnect Secure Mobility Client to the ASA in order to verify your configuration.

Choose your connection entry from the server list and click Connect.
Choose Advanced Window for All Components > Statistics... in order to display the Tunnel Mode.
Click the Route Details tab in order to see the routes to which the Cisco AnyConnect Secure Mobility Client still has local access.
In this example, the client is allowed local LAN access to 10.150.52.0/22 and 169.254.0.0/16 while all other traffic is encrypted and sent across the tunnel.

Cisco AnyConnect Secure Mobility Client

When you examine the AnyConnect logs from the Diagnostics and Reporting Tool (DART) bundle, you can determine whether or not the parameter that allows local LAN access is set.

Test Local LAN Access with Ping

An additional way to test that the VPN Client still has local LAN access while tunneled to the VPN headend is to use the ping command at the Microsoft Windows command line. Here is an example where the local LAN of the client is 192.168.0.0/24 and another host is present on the network with an IP address of 192.168.0.3.

Troubleshoot

This section provides information you can use in order to troubleshoot your configuration.

Unable to Print or Browse by Name

When the VPN Client is connected and configured for local LAN access, you cannot print or browse by name on the local LAN. There are two options available in order to work around this situation:

Browse or print by IP address.
- In order to browse, instead of the syntax sharename, use the syntax x.x.x.x where x.x.x.x is the IP address of the host computer.
- In order to print, change the properties for the network printer in order to use an IP address instead of a name. For example, instead of the syntax sharenameprintername, use x.x.x.xprintername, where x.x.x.x is an IP address.
Create or modify the VPN Client LMHOSTS file. An LMHOSTS file on a Microsoft Windows PC allows you to create static mappings between hostnames and IP addresses. For example, an LMHOSTS file might look like this:
In Microsoft Windows XP Professional Edition, the LMHOSTS file is located in %SystemRoot%System32DriversEtc. Refer to your Microsoft documentation or Microsoft knowledge base Article 314108 for more information.

Related Information

I ran into an issue recently regarding an unstable AnyConnect VPN connection from a laptop, through a DSL router (not mine), terminating at a Cisco ASA running IOS 9.1. The laptop, running Windows 8 (yes, I know), had AnyConnect 3.1 installed on it. The problem was the AnyConnect connection would connect every time, but after about 1 or 2 minutes, it would disconnect.
The logs in the ASA indicated that the user session was being terminated on the remote end:

%ASA-5-722037: Group User IP %ASA-6-716002: Group User IP

Running the 'show vpn-sessiondb anyconnect' command on the ASA would show the following output below. Note the top one was my testing laptop that worked, the bottom connection was the problematic one, with the output caught within the 1-2 minute window before it disconnected.
ASA/pri/act#show vpn-sessiondb anyconnect

Session Type: AnyConnect

Username : USERA Index : 229
Assigned IP : x.x.x.x Public IP : x.x.x.x
Protocol : AnyConnect-Parent SSL-Tunnel DTLS-Tunnel
License : AnyConnect Essentials
Encryption : AnyConnect-Parent: (1)none SSL-Tunnel: (1)DES DTLS-Tunnel: (1)DES
Hashing : AnyConnect-Parent: (1)none SSL-Tunnel: (1)SHA1 DTLS-Tunnel: (1)SHA1
Bytes Tx : 699061 Bytes Rx : 245379
Group Policy : GroupPolicy_VPN Tunnel Group : VPN
Login Time : 10:37:45 EST Tue Feb 26 2013
Duration : 0h:41m:04s
Inactivity : 0h:00m:00s
NAC Result : Unknown
VLAN Mapping : N/A VLAN : none

Username : USERB Index : 236
Assigned IP : x.x.x.x Public IP : x.x.x.x
Protocol : AnyConnect-Parent SSL-Tunnel
License : AnyConnect Essentials
Encryption : AnyConnect-Parent: (1)none SSL-Tunnel: (1)DES
Hashing : AnyConnect-Parent: (1)none SSL-Tunnel: (1)SHA1
Bytes Tx : 59422 Bytes Rx : 36304

Cisco Anyconnect Lose Internet Connection

Group Policy : GroupPolicy_VPN Tunnel Group : VPN

Cisco Anyconnect Log In

Cisco Anyconnect Vpn Software Download

Cisco Anyconnect Lose Internet Connection Download

VLAN Mapping : N/A VLAN : none

Install Cisco Anyconnect Vpn

This command actually led me to figuring out the solution. The part where it says 'DTLS-Tunnel' on the working connection, but not the bottom connection, was where the issue was. See, the DSL router I was going through had an outbound filter setup to allow port 443/tcp only, NOT 443/udp.

Cisco Anyconnect Secure Mobility Client Free

After reading online about this, I learned that the AnyConnect SSL VPN connection first tries to connect over 443/tcp (TLS), then if successful, transitions over to 443/udp (DTLS). The problem was the connection would establish, but since 443/udp was blocked, it would time out and terminate the connection.

In the ASA, I figured out the following command to run in order to disable the DTLS part of the connection, and force it to only use TLS, since that was what was open to me.

webvpn

Once I turned DTLS off in my group policy, the connection established and stayed up correctly after that.
The following text I found somewhere on Cisco's support forum site, linked here, which helped me figure out the issue.

The SSL-Tunnel is the TCP tunnel that is first created to the ASA. When it is fully established, the client will then try to negotiate a UDP DTLS-Tunnel. While the DTLS-Tunnel is being established, data can pass over the SSL-Tunnel. When the DTLS-Tunnel is fully established, all data now moves to the DTLS-tunnel and the SSL-tunnel is only used for occasional control channel traffic. If something should happen to UDP, the DTLS-Tunnel will be torn down and all data will pass through the SSL-Tunnel again.
The decision of how to send the data is very dynamic. As each network bound data packet is processed there is a point in the code where the decision is made to use either the SSL connection or the DTLS connection. If the DTLS connection is healthy at that moment, the packet is sent via the DTLS connection. Otherwise it is sent via the SSL connection.
The SSL connection is established first and data is passed over this connection while attempting to establish a DTLS connection. Once the DTLS connection has been established, the decision point in the code described above just starts sending the packets via the DTLS connection instead of the SSL connection. Control packets, on the other hand, always go over the SSL connection.
The key point is if the connection is considered healthy. If DTLS, an unreliable protocol, is in use and the DTLS connection has gone bad for whatever reason, the client does not know this until Dead Peer Detection (DPD) occurs. Therefore, data will be lost over the DTLS connection during that short period of time because the connection is still considered healthy. Once DPD occurs, data will immediately be set via the SSL connection and a DTLS reconnect will happen.
The ASA will send data over the last connection it received data on. Therefore, if the client has determined that the DTLS connection is not healthy, and starts sending data over the SSL connection, the ASA will reply on the SSL connection. The ASA will resume use of the DTLS connection when data is received on the DTLS connection.'