Cisco Anyconnect Blocks Internet Access

Cisco Anyconnect Windows 10 Download
Cisco Anyconnect Blocks Internet Access
Cisco Anyconnect Log In

To sum up, when the Cisco AnyConnect VPN client connects, it blocks us from all-but-one address associated with the computer. We need the Cisco Client to stop doing that. Does anyone know how to make Cisco AnyConnect SSL VPN client stop doing that? Note: Firepass SSL VPN from F5 Networks does not suffer the same issue. Oct 02, 2009 This document provides step-by-step instructions on how to allow Cisco AnyConnect VPN client access to the Internet while they are tunneled into a Cisco Adaptive Security Appliance (ASA) 8.0.2. This configuration allows the client secure access to corporate resources via SSL while giving unsecured access to the Internet using split tunneling. 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. However, the VPN connection (Cisco AnyConnect) blocks any Internet access from the host machines (Windows 10): When we are connected to the VPN: Outlook is not working, Lync is not working, host Internet is not working, and so forth. Of course:. Customer does not.

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.

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

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

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

Introduction

This document describes the Cisco AnyConnect Mobility Client captive portal detection feature and the requirements for it to function correctly. Many wireless hotspots at hotels, restaurants, airports, and other public places use captive portals in order to block user access to the Internet. They redirect HTTP requests to their own websites that require users to enter their credentials or acknowledge terms and conditions of the hotspot host.

Prerequisites

Requirements

Cisco recommends that you have knowledge of the Cisco AnyConnect Secure Mobility Client.

Components Used

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

AnyConnect Version 3.1.04072
Cisco Adaptive Security Appliance (ASA) Version 9.1.2

Background Information

Many facilities that offer Wi-Fi and wired access, such as airports, coffee shops, and hotels, require users to pay before they obtain access, agree to abide by an acceptable use policy, or both. These facilities use a technique called captive portal in order to prevent applications from connecting until users open a browser and accept the conditions for access.

Captive Portal Remediation Requirements

Support for both captive portal detection and remediation requires one of these licenses:

AnyConnect Premium (Secure Sockets Layer (SSL) VPN Edition)
Cisco AnyConnect Secure Mobility

You can use a Cisco AnyConnect Secure Mobility license in order to provide support for captive portal detection and remediation in combination with either an AnyConnect Essentials or an AnyConnect Premium license.

Note: Captive portal detection and remediation is supported on the Microsoft Windows and Macintosh OS X operating systems supported by the release of AnyConnect that is in use.

Captive Portal Hotspot Detection

AnyConnect displays the Unable to contact VPN server message on the GUI if it cannot connect, regardless of the cause. The VPN server specifies the secure gateway. If Always-on is enabled and a captive portal is not present, the client continues to attempt to connect to the VPN and updates the status message accordingly.

If the Always-on VPN is enabled, the connect failure policy is closed, captive portal remediation is disabled, and AnyConnect detects the presence of a captive portal, then the AnyConnect GUI displays this message once per connection and once per reconnect:

If AnyConnect detects the presence of a captive portal and the AnyConnect configuration differs from that previously described, the AnyConnect GUI displays this message once per connection and once per reconnect:

Caution: Captive portal detection is enabled by default and is nonconfigurable. AnyConnect does not modify any browser configuration settings during captive portal detection.

Captive Portal Hotspot Remediation

Captive portal remediation is the process where you satisfy the requirements of a captive portal hotspot in order to obtain network access.

AnyConnect does not remediate the captive portal; it relies on the end user to perform the remediation.

In order to perform the captive portal remediation, the end user meets the requirements of the hotspot provider. These requirements might include payment of a fee to access the network, a signature on an acceptable use policy, both, or some other requirement that is defined by the provider.

Captive portal remediation must be explicitly allowed in an AnyConnect VPN Client profile if AnyConnect Always-on is enabled and the Connect failure policy is set to Closed. If Always-on is enabled and the Connect Failure policy is set to Open, you do not need to explicitly allow captive portal remediation in an AnyConnect VPN Client profile because the user is not restricted from network access.

False Captive Portal Detection

AnyConnect can falsely assume it is in a captive portal in these situations.

If AnyConnect attempts to contact an ASA with a certificate that contains an incorrect server name (CN), then the AnyConnect client will think it is in a captive portal environment.
In order to prevent this issue, make sure that the ASA certificate is properly configured. The CN value in the certificate must match the name of the ASA server in the VPN client profile.
If there is another device on the network before the ASA that responds to the client's attempt to contact an ASA by blocking HTTPS access to the ASA, then the AnyConnect client will think it is in a captive portal environment. This situation can occur when a user is on an internal network and connects through a firewall in order to connect to the ASA.
If you must restrict access to the ASA from inside the corporation, configure your firewall such that HTTP and HTTPS traffic to the ASA's address does not return an HTTP status. HTTP/HTTPS access to the ASA should either be allowed or completely blocked (also known as black-holed) in order to ensure that HTTP/HTTPS requests sent to the ASA will not return an unexpected response.

AnyConnect Behavior

This section describes how the AnyConnect behaves.

AnyConnect tries an HTTPS probe to the Fully Qualified Domain Name (FQDN) defined in the XML profile.
If there is a certificate error (not trusted/wrong FQDN), then AnyConnect tries an HTTP probe to the FQDN defined in the XML profile. If there is any other response than an HTTP 302, then it considers itself to be behind a captive portal.

Captive Portal Incorrectly Detected with IKEV2

When you attempt an Internet Key Exchange Version 2 (IKEv2) connection to an ASA with SSL authentication disabled that runs the Adaptive Security Device Manager (ASDM) portal on port 443, the HTTPS probe performed for captive portal detection results in a redirect to the ASDM portal (/admin/public/index.html). Since this is not expected by the client, it looks like a captive portal redirect, and the connection attempt is prevented since it seems that captive portal remediation is required.

Workarounds

Cisco Anyconnect Windows 10 Download

If you encounter this issue, here are some workarounds:

Cisco Anyconnect Blocks Internet Access

Remove HTTP commands on that interface so that the ASA will not listen to HTTP connections on the interface.
Remove the SSL trustpoint on the interface.
Enable IKEV2 client-services.
Enable WebVPN on the interface.

This issue is resolved by Cisco bug ID CSCud17825 in Version 3.1(3103).

Cisco Anyconnect Log In

Caution: The same problem exists for Cisco IOS^® routers. If ip http server is enabled on Cisco IOS, which is required if the same box is used as the PKI Server, AnyConnect falsely detects captive portal. The workaround is to use ip http access-class in order to stop responses to AnyConnect HTTP requests, instead of requesting authentication.

Disable the Captive Portal Feature

It is possible to disable the captive portal feature in AnyConnect client version 4.2.00096 and later (see Cisco bug ID CSCud97386). The administrator can determine if the option should be user configurable or disabled. This option is available under the Preferences (Part 1) section in the profile editor. The administrator can choose Disable Captive Portal Detection or User Controllable as shown in this profile editor snapshot:

If User controllable is checked, the checkbox appears on the Preferences tab of the AnyConnect Secure Mobility Client UI as shown here: