Configuring VPN Access The following sections describe the Cisco AnyConnect Secure Mobility client VPN profile and features, and how to configure them: • • • • • • • • • • • • • • • • • • • • • • • • • • • • Configuring IP Addresses for AnyConnect Clients IP addresses make internetwork connections possible. They are like telephone numbers: both the sender and receiver must have an assigned number to connect. But with VPNs, there are actually two sets of addresses: the first set connects client and server on the public network. Once that connection is made, the second set connects client and server through the VPN tunnel. In ASA address management, you configure the IP addresses that the client uses to connect to the private network. IP addresses assigned to other resources on your private network are part of your network administration responsibilities, not part of VPN management. In this section, the IP addresses we refer to are available in your private network addressing scheme for client VPN.

This section includes the following topics: • • • IP Address Assignment Policies • Use authentication server — Retrieve addresses from an external authentication, authorization, and accounting server on a per-user basis. If you are using an authentication server that has IP addresses configured, we recommend using this method. You can configure AAA servers in the Configuration >AAA Setup pane. This method is available for IPv4 and IPv6 assignment policies. • Use DHCP — Obtain IP addresses from a DHCP server.

Jan 29, 2014. Vpn-connect.bat @echo off rem rem Try connecting to vpn using command line silently, ie without any prompt whatsoever. Rem set user_id=yourUserId set pwd=yourPassword set install_dir='C: Program Files (x86) Cisco Systems VPN Client' set profile_name=yourProfileNameWithoutFileExtension rem. Apr 18, 2005. This chapter explains how to use the VPN Client command-line interface (CLI) to connect to a Cisco VPN device, generate statistical reports, and disconnect. Note When you use the notrayicon option either directly on the command line or in a batch file, make sure that you issue a vpnclient disconnect.

To use DHCP, configure the server in the Configuration >Remote Access VPN >DHCP Server pane. This method is available for IPv4 assignment policies. • Use an internal address pool — Internally configured address pools are the easiest method of address pool assignment. If you use this method, configure the IP address pools in Configuration >Remote Access VPN >Network (Client) Access >Address Assignment >Address Pools pane. This method is available for IPv4 and IPv6 assignment policies. – Allow the reuse of an IP address so many minutes after it is released—Delays the reuse of an IP address after its return to the address pool. Adding a delay helps to prevent problems firewalls can experience when an IP address is reassigned quickly.

By default, this is unchecked, meaning the ASA does not impose a delay. If you want one, check the box and enter the number of minutes in the range 1 - 480 to delay IP address reassignment.This configurable element is available for IPv4 assignment policies. Configuring IPv4 and IPv6 Address Assignments using ASDM Step 1 Select Configuration >Remote Access VPN >Network (Client) Access >Address Assignment >Assignment Policy Step 2 In the IPv4 Policy area, check the address assignment method to enabled it or uncheck the address assignment method to disable it. These methods are enabled by default: • Use Authentication server.

Enables the use of an Authentication Authorization and Accounting (AAA) server you have configured to provide IP addresses. Enables the use of a Dynamic Host Configuration Protocol (DHCP) server you have configured to provide IP addresses. • Use internal address pools: Enables the use of a local address pool configured on the ASA. If you enable Use internal address pools, you can also enable the reuse of an IPv4 address after it has been released.

You can specify a range of minutes from 0 to 480 after which the IP v4 address can be reused. Step 3 In the IPv6 Policy area, check the address assignment method to enable it or uncheck the address assignment method to disable it. These methods are enabled by default: • Use Authentication server.

Enables the use of an Authentication Authorization and Accounting (AAA) server you have configured to provide IP addresses. • Use internal address pools: Enables the use of a local address pool configured on the ASA. Step 4 Click Apply. Step 5 Click OK. Internal IP Address Pools To configure IPv4 or IPv6 address pools to use for VPN remote access tunnels, open ASDM and select Configuration >Remote Access VPN >Network (Client) Access >Address Management >Address Pools >Add/Edit IP Pool. To delete an address pool, open ASDM and select Configuration >Remote Access VPN >Network (Client) Access >Address Management >Address Pools.

Select the address pool you want to delete and click Delete. The ASA uses address pools based on the connection profile or group policy for the connection. The order in which you specify the pools is important. If you configure more than one address pool for a connection profile or group policy, the ASA uses them in the order in which you added them to the ASA. If you assign addresses from a non-local subnet, we suggest that you add pools that fall on subnet boundaries to make adding routes for these networks easier. Note The ASA's outside interface addresses, for both IPv4 and IPv6, cannot overlap with the private side address space as defined by address pools.

Configuring Local IPv4 Address Pools Using ASDM The IP Pool area shows each configured address pool by name with their IP address range, for example: 10.10.147.100 to 10.10.147.177. If no pools exist, the area is empty.

The ASA uses these pools in the order listed: if all addresses in the first pool have been assigned, it uses the next pool, and so on. If you assign addresses from a non-local subnet, we suggest that you add pools that fall on subnet boundaries to make adding routes for these networks easier. Step 1 Select Configuration >Remote Access VPN >Network (Client) Access >Address Assignment >Address Pools.

Step 2 To add an IPv4 address, click Add >IPv4 Address pool. To edit an existing address pool, select the address pool in the address pool table and click Edit. Step 3 In the Add/Edit IP Pool dialog box, enter this information: • Pool Name—Enter the name of the address pool. It can be up to 64 characters • Starting Address—Enter the first IP address available in each configured pool. Use dotted decimal notation, for example: 10.10.147.100. • Ending Address—Enter the last IP address available in each configured pool.

User dotted decimal notation, for example: 10.10.147.177. • Subnet Mask—Identifies the subnet on which this IP address pool resides. Step 4 Click OK. Step 5 Click Apply.

Configuring Local IPv6 Address Pools Using ASDM The IP Pool area shows each configured address pool by name with a starting IP address range, the address prefix, and the number of addresses configurable in the pool. If no pools exist, the area is empty.

The ASA uses these pools in the order listed: if all addresses in the first pool have been assigned, it uses the next pool, and so on. If you assign addresses from a non-local subnet, we suggest that you add pools that fall on subnet boundaries to make adding routes for these networks easier.

Step 1 Select Configuration >Remote Access VPN >Network (Client) Access >Address Assignment >Address Pools. Step 2 To add an IPv6 address, click Add >IPv6 Address pool. To edit an existing address pool, select the address pool in the address pool table and click Edit. Step 3 In the Add/Edit IP Pool dialog box enter this information: • Name—Displays the name of each configured address pool. • Starting IP Address—Enter the first IP address available in the configured pool.

For example: 2001:DB8::1. • Prefix Length— Enter the IP address prefix length in bits. For example 32 represents /32 in CIDR notation. The prefix length defines the subnet on which the pool of IP addresses resides. • Number of Addresses—Identifies the number of IPv6 addresses, starting at the Starting IP Address, there are in the pool.

Step 4 Click OK. Step 5 Click Apply. Assigning an IP Address to an AnyConnect Connection Use one of these methods to assign an IP address to a VPN connection: • —An internal pool is associated with a group policy and configured on the ASA. These addresses can be IPv4 or IPv6. • —Associating a DHCP server with a group policy that is configured on the ASA.

These addresses can only be IPv4. • —Assigning an IP address to a user configured on the ASA. These addresses can be IPv4 or IPv6.

Assigning IP Addresses using Internal Address Pools The Add or Edit Group Policy dialog box lets you specify address pools, tunneling protocols, filters, connection settings, and servers for the internal Network (Client) Access group policy being added or modified. For each of the fields on this dialog box, checking the Inherit check box lets the corresponding setting take its value from the default group policy. Inherit is the default value for all the attributes in this dialog box. You can configure both IPv4 and IPv6 address pools for the same group policy. If both versions of IP addresses are configured in the same group policy, clients configured for IPv4 will get an IPv4 address, clients configured for IPv6 will get an IPv6 address, and clients configured for both IPv4 and IPv6 addresses will get both an IPv4 and an IPv6 address. Step 1 Connect to the ASA using ASDM and select Configuration >Remote Access VPN >Network (Client) Access >Group Policies. Step 2 Create a new group policy or the group policy you want to configure with an internal address pool and click Edit.

The General attributes pane is selected by default in the group policy dialog. Step 3 Use the Address Pools field to specify an IPv4 address pool for this group policy. Click Select to add or edit an IPv4 address pool. Manual Html Para Paginas Web. See for more information. Step 4 Use the IPv6 Address Pools field to specify an IPv6 address pools to use for this group policy.

Click Select to add or edit a IPv6 address pool. Step 5 Click OK. Step 6 Click Apply. Assigning IP Addresses Using DHCP To assign IPv4 addresses using a DHCP server, configure the IP address Assignment policy to use DHCP follow the instructions below.

You cannot assign IPv6 addresses to AnyConnect clients using a DHCP server. Step 1 Connect to the ASA using ASDM. Step 2 Select Configuration >Remote Access VPN >Network (Client) Access >Address Assignment >Assignment Policy. Step 3 Click Use DHCP. Step 4 Click Apply.

Step 5 Configure your DHCP servers by selecting Configuration >Remote Access VPN >DHCP Server. Assigning IP Addresses to a Local User ASA administrators can create accounts for individual users on the ASA. These accounts can be configured to use a group policy or they can have many of the same VPN attributes found in group policies configured specifically in the local user policy. These individual users can also have some AnyConnect attributes defined for their account. This section describes how to configure all the attributes of a local user.

Prerequisites This procedure describes how to edit an existing user. To add a user select Configuration >Remote Access VPN >AAA/Local Users >Local Users and click Add. For more information see “Adding a User Account to the Local Database” in Chapter 42, Configuring AAA Servers and the Local Database in the Cisco ASA 5500 Configuration Guide Using ASDM. Guidelines By default, the Inherit check box is checked for each setting on the Edit User Account screen, which means that the user account inherits the value of that setting from the default group policy, DfltGrpPolicy.

To override each setting, uncheck the Inherit check box, and enter a new value. The detailed steps that follow describe each of the settings on the Edit User Account screen. Detailed Steps Step 1 Start ASDM and select Configuration >Remote Access VPN >AAA/Local Users >Local Users. Step 2 Select the user you want to configure and click Edit. The Edit User Account screen opens. Step 3 In the left pane, click VPN Policy.

Step 4 Specify a group policy for the user. The user policy will inherit the attributes of this group policy. If there are other fields on this screen that are set to Inherit the configuration from the Default Group Policy, the attributes specified in this group policy will take precedence over those in the Default Group Policy. Step 5 Specify which tunneling protocols are available for the user, or whether the value is inherited from the group policy. Check the desired Tunneling Protocols check boxes to choose the VPN tunneling protocols that are available for use.

Only the selected protocols are available for use. The choices are as follows: • Clientless SSL VPN (VPN via SSL/TLS) uses a web browser to establish a secure remote-access tunnel to a VPN Concentrator; requires neither a software nor hardware client. Clientless SSL VPN can provide easy access to a broad range of enterprise resources, including corporate websites, web-enabled applications, NT/AD file shares (web-enabled), e-mail, and other TCP-based applications from almost any computer that can reach HTTPS Internet sites.

• The SSL VPN Client lets users connect after downloading the Cisco AnyConnect Client application. Users use a clientless SSL VPN connection to download this application the first time. Client updates then occur automatically as needed whenever the user connects. • IPsec IKEv1—IP Security Protocol.

Regarded as the most secure protocol, IPsec provides the most complete architecture for VPN tunnels. Both Site-to-Site (peer-to-peer) connections and Cisco VPN client-to-LAN connections can use IPsec IKEv1. • IPsec IKEv2—IPsec IKEv2-Supported by the AnyConnect Secure Mobility Client. AnyConnect connections using IPsec with IKEv2 can make use of the same feature set available to SSL VPN Connections. • L2TP over IPsec allows remote users with VPN clients provided with several common PC and mobile PC operating systems to establish secure connections over the public IP network to the ASA and private corporate networks.

Note If no protocol is selected, an error message appears. Step 6 Specify which filter (IPv4 or IPv6) to use, or whether to inherit the value from the group policy. Filters consist of rules that determine whether to allow or reject tunneled data packets coming through the ASA, based on criteria such as source address, destination address, and protocol. To configure filters and rules, choose Configuration >Remote Access VPN >Network (Client) Access >Group Policies >Add/Edit >General >More Options >Filter. Click Manage to display the ACL Manager pane, on which you can add, edit, and delete ACLs and ACEs. Step 7 Specify whether to inherit the Connection Profile (tunnel group) lock or to use the selected tunnel group lock, if any.

Selecting a specific lock restricts users to remote access through this group only. Tunnel Group Lock restricts users by checking if the group configured in the VPN client is the same as the users assigned group. If it is not, the ASA prevents the user from connecting. If the Inherit check box is not checked, the default value is None.

Step 8 Specify whether to inherit the Store Password on Client System setting from the group. Uncheck the Inherit check box to activate the Yes and No radio buttons.

Click Yes to store the logon password on the client sy stem (potentially a less-secure option). Click No (the default) to require the user to enter the password with each connection.

For maximum security, we recommend that you not allow password storage. Step 9 Specify an Access Hours policy to apply to this user, create a new access hours policy for the user, or leave the Inherit box checked. The default value is Inherit, or, if the Inherit check box is not checked, the default value is Unrestricted. Click Manage to open the Add Time Range dialog box, in which you can specify a new set of access hours.

Step 10 Specify the number of simultaneous logons by the user. The Simultaneous logons parameter specifies the maximum number of simultaneous logons allowed for this user.

The default value is 3. The minimum value is 0, which disables logon and prevents user access. Note While there is no maximum limit, allowing several simultaneous connections could compromise security and affect performance. Step 11 Specify the maximum connection time for the user connection time in minutes. At the end of this time, the sy stem terminates the connection. The minimum is 1 minute, and the maximum is minutes (over 4000 years).

To allow unlimited connection time, check the Unlimited check box (the default). Step 12 Specify the Idle Timeout for the user in minutes. If there is no communication activity on the connection by this user in this period, the system terminates the connection. The minimum time is 1 minute, and the maximum time is 10080 minutes. This value does not apply to users of clientless SSL VPN connections. Step 13 Configure the Session Alert Interval.

If you uncheck the Inherit check box, the Default checkbox is checked automatically. This sets the session alert interval to 30 minutes. If you want to specify a new value, uncheck the Default check box and specify a session alert interval from 1 to 30 minutes in the minutes box. Step 14 Configure the Idle Alert Interval.

If you uncheck the Inherit check box, the Default checkbox is checked automatically. This sets the idle alert interval to 30 minutes.

If you want to specify a new value, uncheck the Default check box and specify a session alert interval from 1 to 30 minutes in the minutes box. Step 15 To set a dedicated IPv4 address for this user, enter an IPv4 address and subnet mask in the Dedicated IPv4 Address (Optional) area. Step 16 To set a dedicated IPv6 address for this user, enter an IPv6 address with an IPv6 prefix in the Dedicated IPv6 Address (Optional) field. The IPv6 prefix indicates the subnet on which the IPv6 address resides. Step 17 To configure clientless SSL settings, in the left pane, click Clientless SSL VPN. To override each setting, uncheck the Inherit check box, and enter a new value.

Step 18 Click Apply. The changes are saved to the running configuration.

Configuring IPv4 or IPv6 Traffic to Bypass the VPN The Client Bypass Protocol feature allows you to configure how the AnyConnect client manages IPv4 traffic when the ASA is expecting only IPv6 traffic or how AnyConnect manages IPv6 traffic when the ASA is only expecting IPv4 traffic. When the AnyConnect client makes a VPN connection to the ASA, the ASA could assign the client an IPv4, IPv6, or both an IPv4 and IPv6 address. If Client Bypass Protocol is enabled for one IP protocol and an address pool is not configured for that protocol (in other words, no IP address for that protocol was pushed to client from the ASA) any IP traffic using that protocol will not be sent through the VPN tunnel, it will be sent from the AnyConnect client in the clear. On the other hand, if Client Bypass Protocol is disabled, and an address pool is not configured for that protocol, the client will drop all traffic for that IP protocol once the VPN tunnel is established. For example, assume that the ASA assigns only an IPv4 address to an AnyConnect connection and the endpoint is dual stacked. When the endpoint attempts to reach an IPv6 address, if Client Bypass Protocol is disabled, the IPv6 traffic is dropped and if Client Bypass Protocol is enabled, the IPv6 traffic is sent from the client in the clear. You configure the Client Bypass Protocol on the ASA for group policies.

Step 1 Connect to the ASA using ASDM. Step 2 Select Configuration >Remote Access VPN >Network (Client) Access >Group Policies. Step 3 Select a group policy and click Edit. Step 4 Select Advanced >AnyConnect. Step 5 Next to Client Bypass Protocol, uncheck Inherit if this is a group policy other than the default group policy. Step 6 Choose one of these options: • Click Disable to drop IP traffic for which the ASA did not assign an address. • Click Enable to send that IP traffic in the clear.

Step 7 Click OK. Step 8 Click Apply. Creating and Editing an AnyConnect Profile This section describes how to launch the profile editor from ASDM and create a new profile. The Cisco AnyConnect Secure Mobility client software package, version 2.5 and later (all operating systems) contains the profile editor. ASDM activates the profile editor when you load the AnyConnect software package on the ASA as an SSL VPN client image. If you load multiple AnyConnect packages, ASDM loads the profile editor from the newest AnyConnect package. This approach ensures that the editor displays the features for the newest AnyConnect loaded, as well as the older clients.

Note If you manually deploy the VPN profile, you must also upload the profile to the ASA. When the client system connects, AnyConnect verifies that the profile on the client matches the profile on the ASA. If you have disabled profile updates, and the profile on the ASA is different from the client, then the manually deployed profile won’t work. To activate the profile editor in ASDM, follow these steps: Step 1 Load the AnyConnect software package as an AnyConnect Client image.

If you have not done this already, see Chapter 2, “Configuring the ASA to Download AnyConnect”. Step 2 Select Configuration >Remote Access VPN >Network (Client) Access >AnyConnect Client Profile. The AnyConnect Client Profile pane opens. Step 3 Click Add.

The Add AnyConnect Client Profile window opens ( Figure 3-1). Figure 3-1 Adding an AnyConnect Profile Step 4 Specify a name for the profile. Unless you specify a different value for Profile Location, ASDM creates an XML file on the ASA flash memory with the same name. Note When specifying a name, avoid the inclusion of the.xml extension. If you name the profile example.xml, ASDM adds an.xml extension automatically and changes the name to example.xml.xml. Even if you change the name back to example.xml in the Profile Location field on the ASA, the name returns to example.xml.xml when you connect with AnyConnect by remote access.

If the profile name is not recognized by AnyConnect (because of the duplicate.xml extension), IKEv2 connections may fail. Step 5 Choose a group policy (optional). The ASA applies this profile to all AnyConnect users in the group policy. Step 6 Click OK. ASDM creates the profile, and the profile appears in the table of profiles.

Step 7 Select the profile you just created from the table of profiles. The profile editor displays as shown in. Enable AnyConnect features in the panes of the profile editor. When you finish, click OK. Figure 3-2 Editing a Profile Deploying the AnyConnect Profile Note You must include the ASA in the host list in the profile so the client GUI displays all the user controllable settings on the initial VPN connection.

If you do not add the ASA address or FQDN as a host entry in the profile, then filters do not apply for the session. For example, if you create a certificate match and the certificate properly matches the criteria, but you do not add the ASA as a host entry in that profile, the certificate match is ignored. For more information about adding host entries to the profile, see.

Step 1 Associate a client profile with a group policy. Select Configuration >Remote Access VPN >Network (Client) Access >Group Policies. Step 2 Add a new group policy or select a group policy from the group policies table and click Edit.

Step 3 Select Advanced >AnyConnect Client. Step 4 Uncheck Inherit and select an AnyConnect profile to download using the Select AnyConnect Client Profile dialog box.

Step 5 When you have finished with the configuration, click OK and then Apply. Configuring VPN Load Balancing Configuring load balancing for AnyConnect clients is documented fully in “Configuring Load Balancing,” in Chapter 67, Configuring IKE, Load Balancing, and NAC in Cisco ASA 5500 Series Configuration Guide using ASDM, 6.4 and 6.6.

In addition to the guidelines defined there, be aware of these guidelines: • Clients with IPv6 addresses can make AnyConnect connections through the ASA cluster’s public-facing IPv6 address or through a Global Site Selector (GSS) server. Similarly, clients with IPv6 addresses can make AnyConnect VPN connections through the ASA cluster’s public-facing IPv4 address or through a GSS server.

Either type of connection can be load-balanced within the ASA cluster. Note Connections may fail if the DNS Time-To-Live (TTL) for entries in the GSS DNS Server are less than the time it takes AnyConnect to fully connect.

We recommend setting a DNS TTL of at least 300 seconds (five minutes). For clients with IPv6 addresses to successfully connect to the ASA’s public-facing IPv4 address, a device that can perform network address translation from IPv6 to IPv4 needs to be in the network. • When performing certificate verification for load balancing with AnyConnect, and the connection is redirected by an IP address, the client does all name checking through this IP address.

The customer needs to make sure that this IP address is listed in the certificates common name or the subject alt name. If the IP address is not present in these fields, then the certificate will be deemed untrusted. • Following the guidelines defined in RFC 2818, if a subject alt name is included in the certificate, we only use the subject alt name for name checks and we ignore the common name.

Make sure that the IP address of the server presenting the certificate is defined in the subject alt name of the certificate. For a standalone ASA, the IP address is the IP of that ASA. In a clustering situation, it depends on the certificate configuration.

If the cluster uses one certificate, then it would be the IP of the cluster, and the certificate would contain Subject Alternative Name extensions that have each ASA's IP and FQDN. If the cluster uses multiple certificates, then it should once again be the IP address of the ASA. Configuring Start Before Logon Start Before Logon (SBL) allows a user to establish their VPN connection to the enterprise infrastructure before logging on to Windows. Windows logon forces the user to connect to the enterprise infrastructure over a VPN connection before logging on to Windows by starting AnyConnect before the Windows logon dialog box appears. After authenticating to the ASA, the Windows logon dialog appears, and the user logs in as usual. SBL is only available for Windows and lets you control the use of logon scripts, password caching, mapping network drives to local drives, and more.

Note AnyConnect does not support SBL for Windows XP x64 (64-bit) Edition. Reasons you might consider enabling SBL for your users include: • The user’s computer is joined to an Active Directory infrastructure. • The user cannot have cached credentials on the computer (the group policy disallows cached credentials).

• The user must run logon scripts that execute from a network resource or need access to a network resource. • A user has network-mapped drives that require authentication with the Microsoft Active Directory infrastructure. • Networking components (such as MS NAP/CS NAC) exist that might require connection to the infrastructure. To enable the SBL feature, you must make changes to the AnyConnect profile and enable the ASA to download an AnyConnect module for SBL. The only configuration necessary for SBL is enabling the feature. Network administrators handle the processing that goes on before logon based upon the requirements of their situation. Logon scripts can be assigned to a domain or to individual users.

Generally, the administrators of the domain have batch files or the like defined with users or groups in Microsoft Active Directory. As soon as the user logs on, the logon script executes.

SBL creates a network that is equivalent to being on the local corporate LAN. For example, with SBL enabled, since the user has access to the local infrastructure, the logon scripts that would normally run when a user is in the office would also be available to the remote user.

This includes domain logon scripts, group policy objects and other Active Directory functionality that normally occurs when a user logs on to their system. In another example, a system might be configured to not allow cached credentials to be used to log on to the computer. In this scenario, users must be able to communicate with a domain controller on the corporate network for their credentials to be validated before gaining access to the computer. SBL requires a network connection to be present at the time it is invoked. In some cases, this might not be possible, because a wireless connection might depend on credentials of the user to connect to the wireless infrastructure. Since SBL mode precedes the credential phase of a logon, a connection would not be available in this scenario.

In this case, the wireless connection needs to be configured to cache the credentials across logon, or another wireless authentication needs to be configured, for SBL to work. If the Network Access Manager is installed, you must deploy machine connection to ensure that an appropriate connection is available. For more information, see.

AnyConnect is not compatible with fast user switching. This section covers the following topics: • • Installing Start Before Logon Components (Windows Only) The Start Before Logon components must be installed after the core client has been installed. Additionally, the Start Before Logon components require that the core client software is installed. If you are pre-deploying AnyConnect and the Start Before Logon components using the MSI files (for example, you are at a big company that has its own software deployment—Altiris, Active Directory, or SMS), then you must get the order right. The order of the installation is handled automatically when the administrator loads AnyConnect if it is web deployed or web updated. Note AnyConnect cannot be started by third-party Start Before Logon applications.

Start Before Logon Differences Between Windows Versions The procedures for enabling SBL differ slightly on Windows 7 and Vista systems. Pre-Vista systems use a component called VPNGINA (which stands for virtual private network graphical identification and authentication) to implement SBL. Windows 7 and Vista systems use a component called PLAP to implement SBL. In AnyConnect, the Windows 7 or Vista SBL feature is known as the Pre-Login Access Provider (PLAP), which is a connectable credential provider. This feature lets network administrators perform specific tasks, such as collecting credentials or connecting to network resources, before logon. PLAP provides SBL functions on Windows 7 and Vista. PLAP supports 32-bit and 64-bit versions of the operating system with vpnplap.dll and vpnplap64.dll, respectively.

The PLAP function supports Windows 7 and Vista x86 and x64 versions. Note In this section, VPNGINA refers to the Start Before Logon feature for pre-Vista platforms, and PLAP refers to the Start Before Logon feature for Windows 7 and Vista systems. A GINA is activated when a user presses the Ctrl+Alt+Del key combination. With PLAP, the Ctrl+Alt+Del key combination opens a window where the user can choose either to log in to the system or to activate any Network Connections (PLAP components) using the Network Connect button in the lower-right corner of the window. The sections that immediately follow describe the settings and procedures for both VPNGINA and PLAP SBL. For a complete description of enabling and using the SBL feature (PLAP) on a Windows 7 or Vista platform, see the. Enabling SBL in the AnyConnect Profile To enable SBL in the AnyConnect profile, follow these steps: Step 1 Launch the Profile Editor from ASDM (see the.

Step 2 Go to the Preferences pane and check Use Start Before Logon. Step 3 (Optional) To give the remote user control over using SBL, check User Controllable. Note The user must reboot the remote computer before SBL takes effect. Enabling SBL on the Security Appliance To minimize download time, AnyConnect requests downloads (from the ASA) only of core modules that it needs for each feature that it supports.

To enable SBL, you must specify the SBL module name in group policy on the ASA. Follow this procedure: Step 1 Go to Configuration >Remote Access VPN >Network (Client) Access >Group Policies. Step 2 Select a group policy and click Edit. Step 3 Select Advanced >AnyConnect Client in the left navigation pane. AnyConnect Client settings display. Step 4 Uncheck Inherit for the Optional Client Module for Download setting. Step 5 Select the AnyConnect SBL module in the drop-down list.

Troubleshooting SBL Use the following procedure if you encounter a problem with SBL: Step 1 Ensure that the AnyConnect profile is loaded on the ASA, ready to be deployed. Step 2 Delete prior profiles (search for them on the hard drive to find the location, *.xml).

Step 3 Using Windows Add/Remove Programs, uninstall the SBL Components. Reboot the computer and retest. Step 4 Clear the user’s AnyConnect log in the Event Viewer and retest. Step 5 Browse back to the security appliance to install AnyConnect again.

Step 6 Reboot once. On the next reboot, you should be prompted with the Start Before Logon prompt. Step 7 Collect a DART bundle and send it to your AnyConnect Administrator. Step 8 If you see the following error, delete the user’s AnyConnect profile: Description: Unable to parse the profile C: Documents and Settings All Users Application Data Cisco Cisco AnyConnect Secure Mobility Client Profile VABaseProfile.xml.

Host data not available. Step 9 Go back to the.tmpl file, save a copy as an.xml file, and use that XML file as the default profile. Configuring Start Before Logon (PLAP) on Windows Systems As on the other Windows platforms, the Start Before Logon (SBL) feature starts a VPN connection before the user logs in to Windows. This ensures users connect to their corporate infrastructure before logging on to their computers. Microsoft Windows 7 and Vista use different mechanisms than Windows XP, so the SBL feature on Windows 7 and Vista uses a different mechanism as well. The SBL AnyConnect feature is known as the Pre-Login Access Provider (PLAP), which is a connectable credential provider. This feature lets programmatic network administrators perform specific tasks, such as collecting credentials or connecting to network resources, before logon.

PLAP provides SBL functions on Windows 7 and Vista. PLAP supports 32-bit and 64-bit versions of the operating system with vpnplap.dll and vpnplap64.dll, respectively. The PLAP function supports x86 and x64. Note In this section, VPNGINA refers to the Start Before Logon feature for Windows XP, and PLAP refers to the Start Before Logon feature for Windows 7 and Vista. Installing PLAP The vpnplap.dll and vpnplap64.dll components are part of the existing GINA installation package, so you can load a single, add-on SBL package on the security appliance, which then installs the appropriate component for the target platform. PLAP is an optional feature.

The installer software detects the underlying operating system and places the appropriate DLL in the system directory. For systems before Windows 7 and Vista, the installer installs the vpngina.dll component on 32-bit versions of the operating system. On Windows 7 or Vista, or the Windows 2008 server, the installer determines whether the 32-bit or 64-bit version of the operating system is in use and installs the appropriate PLAP component. Note If you uninstall AnyConnect while leaving the VPNGINA or PLAP component installed, the VPNGINA or PLAP component is disabled and not visible to the remote user. Once installed, PLAP is not active until you modify the user profile file to activate SBL.

After activation, the user invokes the Network Connect component by clicking Switch User, then the Network Connect icon in the lower, right part of the screen. Note If the user mistakenly minimizes the user interface, the user can restore it by pressing the Alt+Tab key combination. Logging on to a Windows 7 or Windows Vista PC using PLAP Users can log on to Windows 7 or Windows Vista with PLAP enabled by following these steps, which are Microsoft requirements. The examples screens are for Windows Vista: Step 1 At the Windows start window, users press the Ctrl+Alt+Delete key combination (). Figure 3-3 Example Logon Window Showing the Network Connect Button The Vista logon window appears with a Switch User button.

Figure 3-4 Example Logon Window with Switch User Button Step 2 The user clicks Switch User (circled in red in this figure). The Vista Network Connect window displays. The network logon icon is circled in red.

Note If the user is already connected through an AnyConnect connection and clicks Switch User, that VPN connection remains. If the user clicks Network Connect, the original VPN connection terminates. If the user clicks Cancel, the VPN connection terminates. Figure 3-5 Example Network Connect Window Step 3 The user clicks the Network Connect button in the lower-right corner of the window to launch AnyConnect. The AnyConnect logon window opens. Step 4 The user uses this GUI to log in as usual. Note This example assumes AnyConnect is the only installed connection provider.

If there are multiple providers installed, the user must select the one to use from the items displayed on this window. Step 5 When the user connects, the user sees a screen similar to the Vista Network Connect window, except that it has the Microsoft Disconnect button in the lower-right corner ( Figure 3-5).

This button is the only indication that the connection was successful. Figure 3-6 Example Disconnect Window The user clicks the icon associated with their logon. In this example, the user clicks VistaAdmin to complete logging onto the computer. Caution Once the connection is established, you have a few minutes to log on. The user logon session times out after approximately a two minute idle timeout and a disconnect is issued to the AnyConnect PLAP component, causing the VPN tunnel to disconnect. Disconnecting from AnyConnect Using PLAP After successfully establishing a VPN session, the PLAP component returns to the original window, this time with a Disconnect button displayed in the lower-right corner of the window (circled in ). When the user clicks Disconnect, the VPN tunnel disconnects.

In addition to explicitly disconnecting in response to the Disconnect button, the tunnel also disconnects in the following situations: • When a user logs on to a PC using PLAP but then presses Cancel. • When the PC is shut down before the user logs on to the system. • When Windows times out the user logon session and returns to the “Press CTRL + ALT + DEL to log on” screen. This behavior is a function of the Windows PLAP architecture, not AnyConnect. Trusted Network Detection Trusted Network Detection (TND) gives you the ability to have AnyConnect automatically disconnect a VPN connection when the user is inside the corporate network (the trusted network) and start the VPN connection when the user is outside the corporate network (the untrusted network).

This feature encourages greater security awareness by initiating a VPN connection when the user is outside the trusted network. Note For the equivalent feature for the Web Security module, see.

If AnyConnect is also running Start Before Logon (SBL), and the user moves into the trusted network, the SBL window displayed on the computer automatically closes. TND does not interfere with the ability of the user to manually establish a VPN connection. It does not disconnect a VPN connection that the user starts manually in the trusted network. TND only disconnects the VPN session if the user first connects in an untrusted network and moves into a trusted network.

For example, TND disconnects the VPN session if the user makes a VPN connection at home and then moves into the corporate office. Because the TND feature controls the AnyConnect GUI and automatically starts connections, the GUI should run at all times. If the user exits the GUI, TND does not automatically start the VPN connection. You configure TND in the AnyConnect VPN Client profile. No changes are required to the ASA configuration.

Trusted Network Detection Requirements Trusted Network Detection (TND) is supported on computers running the Microsoft Windows and Mac OS X operating systems supported by this release of AnyConnect. Trusted Network Detection with or without Always-On configured is supported on IPv6 and IPv4 VPN connections to the ASA over IPv4 and IPv6 networks. Configuring Trusted Network Detection To configure TND in the client profile, follow these steps: Step 1 Launch the Profile Editor from ASDM (see the “ ).

Step 2 Go to the Preferences (Part 2) pane. Step 3 Check Automatic VPN Policy. Note Automatic VPN Policy does not prevent users from manually controlling a VPN connection. Step 4 Select a Tru sted Network Policy —the action the client takes when the user is inside the corporate network (the tru sted network). The options are: • Disconnect—The client terminates the VPN connection in the trusted network. • Connect—The client starts a VPN connection in the trusted network. • Do Nothing—The client takes no action in the trusted network.

Setting both the Trusted Network Policy and Untrusted Network Policy to Do Nothing disables Trusted Network Detection (TND). • Pause—AnyConnect suspends the VPN session (instead of disconnecting) it if a user enters a network configured as trusted after establishing a VPN session outside the trusted network.

Prins Afc Software V24. When the user goes outside the trusted network again, AnyConnect resumes the session. This feature is for the user’s convenience because it eliminates the need to establish a new VPN session after leaving a trusted network.

Step 5 Select an Untru sted Network Policy —the action the client takes when the user is outside the corporate network. The options are: • Connect—The client starts a VPN connection upon the detection of an untrusted network. • Do Nothing—The client starts a VPN connection upon the detection of an untrusted network. This option disables always-on VPN. Setting both the Trusted Network Policy and Untrusted Network Policy to Do Nothing disables Trusted Network Detection. Step 6 Specify Tru sted DNS Domains —Specify the DNS suffixes (a string separated by commas) that a network interface may have when the client is in the tru sted network.

You can assign multiple DNS suffixes if you add them to the split-dns list and specify a default domain on the ASA. See Table 3-1 for more examples of DNS suffix matching. You must have a DNS entry for the headend server that is resolvable by DNS. If your connections are by IP address, you need a DNS server that can resolve mus.cisco.com. If mus.cisco.com is not resolvable via DNS, captive portal detection will not work as expected.

The AnyConnect client builds the DNS suffix list in the following order: • the domain passed by the head end • the split-DNS suffix list passed by the head end • the public interface’s DNS suffixes, if configured. If not, the primary and connection-specific suffixes, along with the parent suffixes of the primary DNS suffix (if the corresponding box is checked in the Advanced TCP/IP Settings) Step 7 Specify Tru sted DNS Servers —All DNS server addresses (a string separated by commas) that a network interface may have when the client is in the tru sted network.

For example: 203.0.113.1,2001:DB8::1. Wildcards (*) are not supported for DNS server addresses. Note You can configure either TrustedDNSDomains, TrustedDNSServers, or both.

If you configure TrustedDNSServers, be sure to enter all your DNS servers, so your site(s) will all be part of the Trusted Network. An active interface will be considered as an In-Trusted-Network if it matches ALL the rules in the VPN profile. Table 3-1 DNS Suffix Matching Examples To Match this DNS Suffix: Use this Value for TrustedDNSDomains: example.com (only) *example.com example.com AND anyconnect.cisco.com *.example.com OR example.com, anyconnect.example.com asa.example.com AND example.cisco.com *.example.com OR asa.example.com, anyconnect.example.com Wildcards (*) are supported for DNS suffixes.

TND and Users with Multiple Profiles Connecting to Multiple Security Appliances Multiple profiles on a user computer may present problems if the user alternates connecting to a security appliance that has TND enabled and to one that does not. If the user has connected to a TND-enabled security appliance in the past, that user has received a TND-enabled profile. If the user reboots the computer when out of the trusted network, the GUI of the TND-enabled client displays and attempts to connect to the security appliance it was last connected to, which could be the one that does not have TND enabled. If the client connects to the TND-enabled security appliance, and the user wishes to connect to the non-TND ASA, the user must manually disconnect and then connect to the non-TND security appliance. Consider these problems before enabling TND when the user may be connecting to security appliances with and without TND. The following workarounds will help you prevent this problem: • Enable TND in the client profiles loaded on all the ASAs on your corporate network.

• Create one profile listing all the ASAs in the host entry section, and load that profile on all your ASAs. • If users do not need to have multiple, different profiles, use the same profiles name for the profiles on all the ASAs. Each ASA overrides the existing profile. Always-on VPN You can configure AnyConnect to establish a VPN session automatically after the user logs in to a computer. The VPN session remains open until the user logs out of the computer, or the session timer or idle session timer expires. The group policy assigned to the session specifies these timer values. If AnyConnect loses the connection with the ASA, the ASA and the client retain the resources assigned to the session until one of these timers expire.

AnyConnect continually attempts to reestablish the connection to reactivate the session if it is still open; otherwise, it continually attempts to establish a new VPN session. Note If always-on is enabled, but the user does not log on, AnyConnect does not establish the VPN connection.

AnyConnect starts the VPN connection only post-login. (Post logon) always-on VPN enforces corporate policies to protect the computer from security threats by preventing access to Internet resources when the computer is not in a trusted network. Caution Always-on VPN does not support connecting though a proxy. When AnyConnect detects always-on VPN in the profile, it protects the endpoint by deleting all other AnyConnect profiles and ignores any public proxies configured to connect to the ASA. To enhance the protection against threats, we recommend the following additional protective measures if you configure always-on VPN: • Pre-deploy a profile configured with always-on VPN to the endpoints to limit connectivity to the pre-defined ASAs. Predeployment prevents contact with a rogue server.

• Restrict administrator rights so that users cannot terminate processes. A PC user with admin rights can bypass an always-on VPN policy by stopping the agent.

If you want to ensure fully-secure always-on VPN, you must deny local admin rights to users. • Restrict access to the following folders or the Cisco sub-folders on Windows computers: – For Windows XP users: C: Document and Settings All Users – For Windows Vista and Windows 7 users: C: ProgramData Users with limited or standard privileges may sometimes have write access to their program data folders. They could use this access to delete the AnyConnect profile file and thereby circumvent the always-on feature. • Predeploy a group policy object (GPO) for Windows users to prevent users with limited rights from terminating the GUI.

Predeploy equivalent measures for Mac OS users. Always-on VPN Requirements Support for always-on VPN requires one of the following licensing configurations: • An AnyConnect Premium license on the ASA. • An AnyConnect Essentials license on the ASA and a Cisco Secure Mobility for AnyConnect license on the WSA. Always-on VPN requires a valid server certificate configured on the ASA; otherwise, it fails and logs an event indicating the certificate is invalid.

Ensure your server certificates can pass strict mode if you configure always-on VPN. Always-on VPN supports computers running the Microsoft Windows and Mac OS X operating systems supported by this release. To prevent the download of an always-on VPN profile that locks a VPN connection to a rogue server, the AnyConnect client requires a valid, trusted server certificate to connect to a secure gateway. Tip We strongly recommend purchasing a digital certificate from a certificate authority (CA) and enrolling it on the secure gateways.

If you generate a self-signed certificate, users connecting receive a certificate warning. They can respond by configuring the browser to trust that certificate to avoid subsequent warnings. Note We do not recommend using a self-signed certificate because of the possibility a user could inadvertently configure a browser to trust a certificate on a rogue server and because of the inconvenience to users of having to respond to a security warning when connecting to your secure gateways. ASDM provides an Enroll ASA SSL VPN with Entrust button on the Configuration >Remote Access VPN >Certificate Management >Identity Certificates panel to facilitate enrollment of a public certificate to resolve this issue on an ASA. The Add button on this panel lets you import a public certificate from a file or generate a self-signed certificate: Figure 3-7 Add Identity Certificate dialog Note These instructions are intended only as a guideline for configuring certificates. For details, click the ASDM Help button, or see the ASDM or CLI guide for the secure gateway you are configuring.

Use the Advanced button to specify the domain name and IP address of the outside interface if you are generating a self-signed interface. Following the enrollment of a certificate, assign it to the outside interface. To do so, choose Configuration >Remote Access VPN >Advanced >SSL Settings, edit the “outside” entry in the Certificates area, and select the certificate from the Primary Enrolled Certificate drop-down list. Figure 3-8 Assigning a Certificate to the Outside Interface (ASDM 6.3 Example) Add the certificate to all the secure gateways and associate it with the IP address of the outside interfaces.

Adding Load-Balancing Backup Cluster Members to the Server List Always-on VPN affects the load balancing of AnyConnect VPN sessions. With always-on VPN disabled, when the client connects to a master device within a load balancing cluster, the client complies with a redirection from the master device to any of the backup cluster members. With always-on enabled, the client does not comply with a redirection from the master device unless the address of the backup cluster member is specified in the server list of the client profile. Therefore, be sure to add any backup cluster members to the server list. To specify the addresses of backup cluster members in the client profile, use ASDM to add a load-balancing backup server list by following these steps: Step 1 Launch the Profile Editor from ASDM (see the ). Step 2 Go to the Server List pane.

Step 3 Choose a server that is a master device of a load-balancing cluster and click Edit. Step 4 Enter an FQDN or IP address of any load-balancing cluster member. Configuring Always-on VPN To configure AnyConnect to establish a VPN session automatically only when it detects that the computer is in an untrusted network, Step 1 Configure TND (see ). Step 2 Check Always On. Configuring a Policy to Exempt Users from Always-on VPN By default, always-on VPN is disabled. You can configure exemptions to override an always-on policy.

For example, you might want to let certain individuals establish VPN sessions with other companies or exempt the always-on VPN policy for noncorporate assets. You can set the always-on VPN parameter in group policies and dynamic access policies to override the always-on policy. Doing so lets you specify exceptions according to the matching criteria used to assign the policy.

If an AnyConnect policy enables always-on VPN and a dynamic access policy or group policy disables it, the client retains the disable setting for the current and future VPN sessions as long as its criteria match the dynamic access policy or group policy on the establishment of each new session. The following procedure configures a dynamic access policy that uses AAA or endpoint criteria to match sessions to noncorporate assets, as follows: Step 1 Choose Configuration >Remote Access VPN >Network (Client) Access >Dynamic Access Policies >Add or Edit. Figure 3-9 Exempting Users from Always-on VPN Step 2 Configure criteria to exempt users from always-on VPN. For example, use the Selection Criteria area to specify AAA attributes to match user logon IDs.

Step 3 Click the AnyConnect tab on the bottom half of the Add or Edit Dynamic Access Policy window. Step 4 Click Disable next to “Always-On for AnyConnect VPN” client. If a Cisco AnyConnect Secure Mobility client policy enables always-on VPN and a dynamic access policy or group policy disables it, the client retains the disable setting for the current and future VPN sessions as long as its criteria match the dynamic access policy or group policy on the establishment of each new session. Disconnect Button for Always-on VPN AnyConnect supports a Disconnect button for always-on VPN sessions. If you enable it, AnyConnect displays a Disconnect button upon the establishment of a VPN session.

Users of always-on VPN sessions may want to click Disconnect so they can choose an alternative secure gateway for reasons such as the following: • Performance issues with the current VPN session. • Reconnection issues following the interruption of a VPN session. The Disconnect button locks all interfaces to prevent data from leaking out and to protect the computer from internet access except for establishing a VPN session. Caution Disabling the Disconnect button can at times hinder or prevent VPN access.

If the user clicks Disconnect during an always-on VPN session, AnyConnect locks all interfaces to prevent data from leaking out and protects the computer from internet access except for that required to establish a new VPN session. AnyConnect locks all interfaces, regardless of the connect failure policy.

Caution The Disconnect locks all interfaces to prevent data from leaking out and to protect the computer from internet access except for establishing a VPN session. For the reasons noted above, disabling the Disconnect button can at times hinder or prevent VPN access. Disconnect Button Requirements The requirements for the disconnect option for always-on VPN match those in the.

Enabling and Disabling the Disconnect Button By default, the profile editor enables the Disconnect button when you enable always-on VPN. You can view and change the Disconnect button setting, as follows: Step 1 Launch the Profile Editor from ASDM (see the ). Step 2 Go to the Preferences (Part 2) pane.

Step 3 Check or uncheck Allow VPN Disconnect. Connect Failure Policy for Always-on VPN The connect failure policy determines whether the computer can access the internet if always-on VPN is enabled and AnyConnect cannot establish a VPN session (for example, when a secure gateway is unreachable). The fail-close policy disables network connectivity–except for VPN access. The fail-open policy permits network connectivity. Regardless of the connect failure policy, AnyConnect continues to try to establish the VPN connection. The following table explains the fail open and fail close policies: Always-on VPN Connect Policy Scenario Advantage Trade-off Fail open AnyConnect fails to establish or reestablish a VPN session.

This failure could occur if the secure gateway is unavailable, or if AnyConnect does not detect the presence of a captive portal (often found in airports, coffee shops and hotels). Grants full network access, letting users continue to perform tasks where access to the Internet or other local network resources is needed. Security and protection are not available until the VPN session is established. Therefore, the endpoint device may get infected with web-based malware or sensitive data may leak. Fail close Same as above except that this option is primarily for exceptionally secure organizations where security persistence is a greater concern than always-available network access.

The endpoint is protected from web-based malware and sensitive data leakage at all times because all network access is prevented except for local resources such as printers and tethered devices permitted by split tunneling. Until the VPN session is established, this option prevents all network access except for local resources such as printers and tethered devices. It can halt productivity if users require Internet access outside the VPN and a secure gateway is inaccessible. Caution A connect failure closed policy prevents network access if AnyConnect fails to establish a VPN session. AnyConnect detects most captive portals, described in the; however, if it cannot detect a, the connect failure closed policy prevents all network connectivity. Use extreme caution when implementing a connect failure closed policy.

If you deploy a closed connection policy, we highly recommend that you follow a phased approach. For example, first deploy always-on VPN with a connect failure open policy and survey users for the frequency with which AnyConnect does not connect seamlessly. Then deploy a small pilot deployment of a connect failure closed policy among early-adopter users and solicit their feedback. Expand the pilot program gradually while continuing to solicit feedback before considering a full deployment. As you deploy a connect failure closed policy, be sure to educate the VPN users about the network access limitation as well as the advantages of a connect failure closed policy. Connect Failure Policy Requirements Support for the connect failure policy feature requires one of the following licenses: • AnyConnect Premium (SSL VPN Edition) • Cisco AnyConnect Secure Mobility You can use a Cisco AnyConnect Secure Mobility license to provide support for the connect failure policy in combination with either an AnyConnect Essentials or an AnyConnect Premium license.

The connect failure policy supports only computers running Microsoft Windows 7, Vista, or XP and Mac OS X 10.6 and 10.7. Configuring a Connect Failure Policy By default, the connect failure policy prevents Internet access if always-on VPN is configured and the VPN is unreachable. To configure a connect failure policy, Step 1 Configure TND (see ). Step 2 Check Always On. Step 3 Set the Connect Failure Policy parameter to one of the following settings: • Closed—(Default) Restricts network access when the secure gateway is unreachable.

AnyConnect does this by enabling packet filters that block all traffic from the endpoint that is not bound for a secure gateway to which the computer is allowed to connect. The fail-closed policy prevents captive portal remediation (described in the next sections) unless you specifically enable it as part of the policy. The restricted state permits the application of the local resource rules imposed by the most recent VPN session if Apply Last VPN Local Resources is enabled in the client profile. For example, these rules could determine access to active sync and local printing.

The network is unblocked and open during an AnyConnect software upgrade when Always-On is enabled. The purpose of the Closed setting is to help protect corporate assets from network threats when resources in the private network that protect the endpoint are not available. • Open—This setting permits network access by browsers and other applications when the client cannot connect to the ASA.

An open connect failure policy does not apply if you enable the Disconnect button and the user clicks Disconnect. Captive Portal Hotspot Detection and Remediation Many facilities that offer Wi-Fi and wired access, such as airports, coffee shops, and hotels, require the user to pay before obtaining access, agree to abide by an acceptable use policy, or both. These facilities use a technique called captive portal to prevent applications from connecting until the user opens a browser and accepts the conditions for access. The following sections describe the captive portal detection and remediation features. Captive Portal Remediation Requirements Support for both captive portal detection and remediation requires one of the following licenses: • AnyConnect Premium (SSL VPN Edition) • Cisco AnyConnect Secure Mobility You can use a Cisco AnyConnect Secure Mobility license to provide support for captive portal detection and remediation in combination with either an AnyConnect Essentials or an AnyConnect Premium license. Captive portal detection and remediation is supported on the Microsoft Windows and Mac OS X operating systems supported by this release of AnyConnect.

Captive Portal Hotspot Detection AnyConnect displays the “Unable to contact VPN server” message on the GUI if it cannot connect, regardless of the cause. 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 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, the AnyConnect GUI displays the following message once per connection and once per reconnect: The service provider in your current location is restricting access to the Internet. The AnyConnect protection settings must be lowered for you to log on with the service provider. Your current enterprise security policy does not allow this.

If AnyConnect detects the presence of a captive portal and the AnyConnect configuration differs from that described above, the AnyConnect GUI displays the following message once per connection and once per reconnect: The service provider in your current location is restricting access to the Internet. You need to log on with the service provider before you can establish a VPN session. You can try this by visiting any website with your browser.

Captive portal detection is enabled by default, and is non-configurable. AnyConnect does not modify any browser configuration settings during Captive Portal detection. Captive Portal Hotspot Remediation Captive portal remediation is the process of satisfying the requirements of a captive portal hotspot to obtain network access. AnyConnect does not remediate the captive portal, it relies on the end user to perform the remediation. The end user performs the captive portal remediation by meeting the requirements of the provider of the hotspot. These requirements could be paying a fee to access the network, signing an acceptable use policy, both, or some other requirement defined by the provider.

Captive portal remediation needs to 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 don’t need to explicitly allow captive portal remediation in an AnyConnect VPN Client profile because the user is not restricted from getting access to the network. Configuring Support for Captive Portal Hotspot Remediation You need to enable captive portal remediation in an AnyConnect VPN client policy if the Always-on feature is enabled and the connect failure policy is set to closed. If the connect failure policy is set to open, your users are not restricted from network access, and so, are capable of remediating a captive portal without any other configuration of the AnyConnect VPN client policy. By default, support for captive portal remediation is disabled. Use this procedure to enable captive portal remediation: Step 1 Configure a connect failure policy (see ). Step 2 If you set the connect failure policy to closed, configure the following parameters: • Allow Captive Portal Remediation—Check to let the Cisco AnyConnect Secure Mobility client lift the network access restrictions imposed by the closed connect failure policy.

By default, this parameter is unchecked to provide the greatest security; however, you must enable it if you want the client to connect to the VPN if a captive portal is preventing it from doing so. • Remediation Timeout—Enter the number of minutes that AnyConnect lifts the network access restrictions. The user needs enough time to satisfy the captive portal requirements. If always-on VPN is enabled, and the user clicks Connect, or a reconnect is in progress, a message window indicates the presence of a captive portal. The user can then open a web browser window to remediate the captive portal. If Users Cannot Access a Captive Portal Page If users cannot access a captive portal remediation page, ask them to try the following steps until they can remediate: Step 1 Disable and re-enable the network interface. This action triggers a captive portal detection retry.

Step 2 Terminate any applications that use HTTP, such as instant messaging programs, e-mail clients, IP phone clients, and all but one browser to perform the remediation. The captive portal may be actively inhibiting DoS attacks by ignoring repetitive attempts to connect, causing them to time out on the client end. The attempt by many applications to make HTTP connections exacerbates this problem.

Step 3 Retry Step 1. Step 4 Restart the computer. False Captive Portal Detection AnyConnect can falsely assume it is in a captive portal in the following situations. • If AnyConnect attempts to contact an ASA with a certificate containing an incorrect server name (CN), then the AnyConnect client will think it is in a “captive portal” environment. To prevent this, make sure 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, and that device 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 to connect to the ASA. If you need to 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) to ensure that HTTP/HTTPS requests sent to the ASA will not return an unexpected response. Client Firewall with Local Printer and Tethered Device Support When users connect to the ASA, all traffic is tunneled through the connection and users cannot access resources on their local network. This includes printers, cameras, and tethered devices that synchronize with the local computer. Enabling Local LAN Access in the client profile resolves this problem, however it can introduce a security or policy concern for some enterprises because it allows unrestricted access to the local network.

You can use the ASA to deploy endpoint OS firewall capabilities to restrict access to particular types of local resources, such as printers and tethered devices. To do so, enable client firewall rules for specific ports for printing. The client distinguishes between inbound and outbound rules. For printing capabilities, the client opens ports required for outbound connections, but blocks all incoming traffic. The Client Firewall feature is supported on the Windows, Mac OS X, and Linux operating systems supported by this release. Note Be aware that users logged in as administrators have the ability to modify the firewall rules deployed to the client by the ASA.

Users with limited privileges cannot modify the rules. For either user, the client reapplies the firewall rules when the connection terminates. If you configure the client firewall, and the user authenticates to an Active Directory (AD) server, the client still applies the firewall policies from the ASA. However, the rules defined in the AD group policy take precedence over the rules of the client firewall. The following sections describe procedures on how to do this: • • Usage Notes about Firewall Behavior The following notes clarify how the AnyConnect client uses the firewall: • The source IP is not used for firewall rules. The client ignores the source IP information in the firewall rules sent from the ASA.

The client determines the source IP depending on whether the rules are public or private. Public rules are applied to all interfaces on the client. Private rules are applied to the Virtual Adapter. • The ASA supports many protocols for ACL rules.

However, the AnyConnect firewall feature supports only TCP, UDP, ICMP, and IP. If the client receives a rule with a different protocol, it treats it as an invalid firewall rule, and then disables split tunneling and uses full tunneling for security reasons. • Starting in ASA 9.0, the Public Network Rule and Private Network Rule support unified access control lists. These access control lists can be used to define IPv4 and IPv6 traffic in the same rule. Be aware of the following differences in behavior for each operating system: • For Windows computers, deny rules take precedence over allow rules in Windows Firewall. If the ASA pushes down an allow rule to the AnyConnect client, but the user has created a custom deny rule, the AnyConnect rule is not enforced. • On Windows Vista, when a firewall rule is created, Vista takes the port number range as a comma-separated string.

The port range can be a maximum of 300 ports. For example, from 1-300 or 5000-5300. If you specify a range greater than 300 ports, the firewall rule is applied only to the first 300 ports. • Windows users whose firewall service must be started by the AnyConnect client (not started automatically by the system) may experience a noticeable increase in the time it takes to establish a VPN connection.

• On Mac computers, the AnyConnect client applies rules sequentially in the same order the ASA applies them. Global rules should always be last. • For third-party firewalls, traffic is passed only if both the AnyConnect client firewall and the third-party firewall allow that traffic type. If the third-party firewall blocks a specific traffic type that the AnyConnect client allows, the client blocks the traffic. • For Linux systems, starting with AnyConnect version 3.1.05149, you can configure AnyConnect to evaluate the client's firewall and filter rules.

To configure AnyConnect to allow local firewall and filter rules, add a custom attribute named circumvent-host-filtering to a group profile, and set it to true. Deploying a Client Firewall for Local Printer Support The ASA supports the AnyConnect client firewall feature with ASA version 8.3(1) or later, and ASDM version 6.3(1) or later. This section describes how to configure the client firewall to allow access to local printers, and how to configure the client profile to use the firewall when the VPN connection fails.

Limitations and Restrictions of the Client Firewall The following limitations and restrictions apply to using the client firewall to restrict local LAN access: • Due to limitations of the OS, the client firewall policy on computers running Windows XP is enforced for inbound traffic only. Outbound rules and bidirectional rules are ignored.

This would include firewall rules such as 'permit ip any any'. • Host Scan and some third-party firewalls can interfere with the firewall. The following table clarifies what direction of traffic is affected by the source and destination port settings: Source Port Destination Port Traffic Direction Affected Specific port number Specific port number Inbound and outbound A range or 'All' (value of 0) A range or 'All' (value of 0) Inbound and outbound Specific port number A range or 'All' (value of 0) Inbound only A range or 'All' (value of 0) Specific port number Outbound only Example ACL Rules for Local Printing The ACL AnyConnect_Client_Local_Print is provided with ASDM to make it easy to configure the client firewall.