Step 2 Defining Any Connect VPN Client Attributes

After loading the AnyConnect package in the router's configuration, SDM allows you to define the client parameters. Before an AnyConnect VPN Client is functional, you have to configure the following attributes:

• Enabling SVC functionality

• Defining a pool of addresses

• Creating a Layer 3 interface

Optionally, you can define other attributes to enhance the functionality of the SSL VPN configuration. They include

• Traffic filtering

• Split tunneling

• DNS and WINS assignment

• Keep SSL VPN client installed

The sections that follow define these options.

Enabling SVC Functionality

The Cisco IOS router allows you to enable AnyConnect VPN Client functionality by using the functions command followed by one of two options:

• svc-enabled: This option enables SVC functionality on an IOS router. After a user is authenticated, the AnyConnect Client is automatically launched on the user's computer. If the SVC client fails for any reason, the user can still use clientless and thin client SSL VPN modes. The svc-enabled mode is useful if you want to provide backup connectivity to certain critical applications (such as Web, Mail, and Terminal Server) through clientless and thin client modes should SVC fail to work.

• svc-required: This option also enables AnyConnect Client functionality in an IOS router. After a user is authenticated, the SVC client is automatically launched on the user's computer. However, if the SVC client fails to load for any reason, the user cannot use clientless or thin client SSL VPN modes. The svc-required mode is useful if you require VPN users to use strictly the full tunnel functionality with no fail-open method.

Using SDM, AnyConnect VPN Client can be enabled by choosing Configure > VPN > SSL VPN > Edit SSL VPN > SecureMeContext > Group Policies > SecureMeDefaultPolicy > SSL VPN Client (Full Tunnel) tab. SDM provides a dropdown menu from which you can select whether you want to simply enable the AnyConnect VPN Client or whether you want to require it. Figure 6-25 illustrates that the Cisco IOS router administrator has enabled the AnyConnect Client for SecureMeDefaultPolicy. The client cannot be enabled until you define a pool of addresses, discussed in the next section.

Figure 6-25 Enabling AnyConnect on a Group Policy

Figure 6-25 Enabling AnyConnect on a Group Policy

Example 6-30 shows the command-line equivalent of the configuration shown in Figure 6-25.

Example 6-30 Enabling SVC on a Group Policy

Example 6-30 shows the command-line equivalent of the configuration shown in Figure 6-25.

Example 6-30 Enabling SVC on a Group Policy

Chicago(config)# webvpn context SecureMeContext

Chicago(config-webvpn-context)# policy group SecureMeDefaultPolicy Chicago(config-webvpn-policy)# functions svc-enabled

The AnyConnect VPN Client requires administrative privileges on the client computer when it is installed. For Windows-based workstations, the SSL VPN client is pushed through ActiveX as the preferred method. If ActiveX installation fails, the SSL VPN client is pushed to the workstations through Java. If installation through Java fails, the client is pushed as an executable as the last option. For non-Windows clients, Java is used as the installation method.

Defining a Pool of Addresses

During the SSL VPN tunnel negotiations, an IP address is assigned to the VPN adapter of the SVC client. The client uses this IP address to access resources on the protected side of the tunnel. The IP address is assigned by configuring an address pool and then linking the pool to a policy group. You can either create a new pool of addresses or select a preconfigured address pool.

The pool of addresses can be defined or selected by choosing Configure > VPN > SSL VPN > Edit SSL VPN > SecureMeContext > Group Policies > SecureMeDefaultPolicy > SSL VPN Client (Full Tunnel) tab. Under IP Address Pool from Which Clients Will Be Assigned an Address, click the ... button and choose the appropriate option. To use a preconfigured pool, click Select an existing IP Pool. SDM presents you with a list of pools that are already defined in the configuration that you can select for the SSL VPN connections. If you would rather define a new pool of addresses for these SSL VPN connections, select the Create a new IP Pool option. You can specify a name for this pool under Pool Name. Click Add and define a range of IP addresses by specifying a start and an end IP address. Click OK when finished. As illustrated in Figure 6-26, a new pool is defined as sslvpnpool with a start IP address of 192.68.2.2 and an end IP address of 192.168.2.100.

Figure 6-26 Defining an Address Pool Using SDM

Figure 6-26 Defining an Address Pool Using SDM

Example 6-31 shows the command-line equivalent of the configuration shown in Figure 6-26.

Example 6-31 Address Assignment from the Local Pool

Chicago(config)# ip local pool sslvpnpool 192.168.2.2 192.168.2.100 Chicago(config)# webvpn context SecureMeContext

Chicago(config-webvpn-context)# policy group SecureMeDefaultPolicy Chicago(config-webvpn-policy)# svc address-pool sslvpnpool

Creating a Layer 3 Interface

The SSL VPN implementation on Cisco IOS routers requires you to configure an interface in the same network as the pool of addresses. If the configured address pool spans a different network, and you do not have an interface in that particular network, you can create a loopback interface. The IP address must belong to the address pool network. An interface can be defined by choosing Configure > Interfaces and Connections > Edit Interface/Connection > Add > New Logical Interface > Loopback. From the IP address drop-down menu, select Static IP address and configure an IP address that belongs to the address pool network. Specify the appropriate subnet mask for this IP address. As shown in Figure 6-27, a static IP address of 192.168.2.1 is configured with a subnet mask of 255.255.255.0.

Figure 6-27 Creating a Loopback Interface

Figure 6-27 Creating a Loopback Interface

NOTE If you create a new loopback interface, it must be advertised in your network through a routing protocol.

Example 6-32 shows the command-line equivalent of the configuration shown in Figure 6-27. Example 6-32 Defining an Interface

Chicago(config)# interface Loopbackl

Chicago(config-if)# ip address 192.168.2.1 255.255.255.0

Traffic Filtering

In some cases, you do not want your remote or mobile users to access the entire network resources. For example, if you provide access to contractors but you only allow them to access a web server to complete their tasks, you can create and apply appropriate filters to restrict their access. Traffic filtering is achieved by setting up an access control list (ACL) and then mapping it to the group policy. If you choose Configure > VPN > SSL VPN > Edit SSL VPN > SecureMeContext > Group Policies > SecureMeDefaultPolicy > SSL VPN Client (Full Tunnel) tab, you can either define a new ACL or link an existing ACL under the ACL to Restrict Access for Users In This Group to Corporate Resources option. If you prefer to define a new ACL, click the ... button and select the Create a new rule (ACL) and select option. SDM prompts you to specify an ACL name and describe its usage. To add a rule, click Add and define the filter attributes, such as the source and destination addresses/networks or source and destination service ports. As shown in Figure 6-28, an ACL, defined as SVC-ACL, allows traffic from the 192.168.2.0 network (local pool) to send traffic to the 192.168.1.0 network (inside network). The network administrator has added a description of "ACL to restrict users to a Terminal Server."

Figure 6-28 Defining Traffic Filtering

Figure 6-28 Defining Traffic Filtering

After the ACL is defined, just map the ACL name to the ACL to Restrict Access for Users in This Group to Corporate Resources option. The corresponding CLI format of the Figure 6-28 configuration is shown in Example 6-33.

Example 6-33 Access List to Filter Traffic Through an SSL VPN

Chicago(config)# ip access-list extended SVC-ACL

Chicago(config-ext-nacl)# remark ACL to restrict users to Terminal Server Chicago(config-ext-nacl)# permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 Chicago(config-ext-nacl)# exit Chicago(config)# webvpn context SecureMeContext

Chicago(config-webvpn-context)# policy group SecureMeDefaultPolicy

Chicago(config-webvpn-policy)# filter tunnel SVC-ACL

Split Tunneling

After the tunnel is up, the default behavior of the Cisco VPN client is to encrypt traffic destined to all the IP addresses. This means that if an SSL VPN user wants to browse http://www.cisco.com over the Internet, as illustrated in Figure 6-29, the packets will be encrypted and sent to the Cisco IOS router. After decrypting them, the Cisco IOS router will look at its routing table and forward the packet to the appropriate next-hop IP address in clear text. These steps are reversed when traffic returns from the web server and is destined to the SSL VPN client.

Figure 6-29 Traffic with No Split Tunneling

192.168.1.0/24

209.165.201.1

Figure 6-29 Traffic with No Split Tunneling

209.165.201.1

192.168.1.0/24

www.cisco.com"/>

www.cisco.com

NOTE

Remove the traffic filter that was created in the previous section ("Traffic Filtering"). This filter restricts traffic to pass from 192.168.2.0/24 to 192.168.1.0/24.

This behavior might not always be desirable, for the following two reasons:

• Traffic destined to the nonsecure networks traverses the Internet twice: once encrypted and once in clear text.

• A Cisco IOS router handles extra VPN traffic destined to the nonsecure subnet.

With split tunneling, the Cisco IOS router can notify the AnyConnect VPN Client for the secured subnets. The client, using the secured routes, encrypts only those packets that are destined for the networks behind the Cisco router.

CAUTION With split tunneling, the remote workstation is susceptible to hackers who can potentially take control over the computer and possibly direct traffic over the tunnel. To mitigate this behavior, you should have a personal firewall on the SSL VPN client workstations.

Additionally, the Cisco IOS router also supports tunneling all traffic except for a list of networks that require clear-text access. This feature is useful if users require clear-text access to their local LANs and encrypted tunnels to the corporate network.

As mentioned earlier, the SSL VPN gateway provides three modes for split tunneling:

• Tunnel all traffic (no split tunneling)

• Tunnel specific networks (split tunneling)

• Tunnel all but specific networks (exclude split tunneling)

These modes can be configured by choosing Configure > VPN > SSL VPN > Edit SSL VPN > SecureMeContext > Group Policies > SecureMeDefaultPolicy > SSL VPN Client (Full Tunnel) tab > Advanced Options > Split Tunneling tab. To enable split tunneling, select Include Traffic and click Add to define the network for data encryption. To tunnel all traffic except for certain networks (including local network), select Exclude Traffic and define the networks to be excluded from data encryption. In Figure 6-30, the 192.168.1.0 network is included for split tunneling.

Figure 6-30 Split-Tunneling Configuration

Figure 6-30 Split-Tunneling Configuration

The related split-tunneling configuration is shown in Example 6-34. Example 6-34 Split-Tunneling Configuration

Chicago(config)# webvpn context SecureMeContext

Chicago(config-webvpn-context)# policy group SecureMeDefaultPolicy Chicago(config-webvpn-policy)# svc split include 192.168.1.0 255.255.255.0

DNS and WINS Assignment

For SSL VPN clients, you can assign DNS and WINS server IP addresses so that they can browse and access internal sites when their VPN tunnel is established. You can configure these attributes by choosing Configure > VPN > SSL VPN > Edit SSL VPN > SecureMeContext > Group Policies > SecureMeDefaultPolicy > SSL VPN Client (Full Tunnel) tab > Advanced Options > DNS and WINS Servers tab. In Figure 6-31, the primary DNS server is defined as 192.168.1.10 and the secondary DNS server is 192.168.1.40, whereas the primary WINS server is 192.168.1.40 and the secondary WINS server is 192.168.1.10. The default domain name to be pushed to the SSL VPN client is securemeinc.com.

Figure 6-31 Defining DNS and WINS Servers for SSL VPN Clients

Figure 6-31 Defining DNS and WINS Servers for SSL VPN Clients

The related split-tunneling configuration is shown in Example 6-35.

Example 6-35 Defining DNS and WINS Servers for SSL VPN Clients

Chicago(config)# webvpn context SecureMeContext

Chicago(config-webvpn-context)# policy group SecureMeDefaultPolicy Chicago(config-webvpn-policy)# svc default-domain securemeinc.com Chicago(config-webvpn-policy)# svc dns-server primary 192.168.1.10 Chicago(config-webvpn-policy)# svc dns-server secondary 192.168.1.40 Chicago(config-webvpn-policy)# svc wins-server primary 192.168.1.40 Chicago(config-webvpn-policy)# svc wins-server secondary 192.168.1.10

Keep SSL VPN Client Installed

After the SSL VPN client is installed successfully, the Cisco IOS router allows you to keep the client installed on the computer even if the tunnel is disconnected. By default, the client is automatically removed after the users log off and is reinstalled when the tunnel is successfully established. You can configure to keep the client installed by choosing Configure > VPN > SSL VPN > Edit SSL VPN > SecureMeContext > Group Policies > SecureMeDefaultPolicy > SSL VPN Client (Full Tunnel) tab, as shown in Figure 6-32.

Figure 6-32 Configuration of Keep SSL VPN Client Installed

Figure 6-32 Configuration of Keep SSL VPN Client Installed

The related CLI configuration is shown in Example 6-36. Example 6-36 Configuring Keep the Client Installed

Chicago(config)# webvpn context SecureMeContext

Chicago(config-webvpn-context)# policy group SecureMeDefaultPolicy Chicago(config-webvpn-policy)# svc keep-client-installed

NOTE You should keep the client on the system. Otherwise, administrative rights are needed to reinstall the client on the computer.

Continue reading here: Step 1 Loading the CSD Package

Was this article helpful?

0 0