Chapter 22: PIX and ASA Remote Access Connections (Part 3)

Easy VPN Server Support for 7.0

Continued support for Easy VPN Server is provided in FOS 7.0. Many, many new enhancements have been made to the Server function, putting the PIX and ASA more in line with the IPsec capabilities of the VPN 3000 concentrators. However, the configuration of an Easy VPN Server is very different than what I discussed earlier for 6.x.

This part of the chapter will focus on the configuration of a PIX/ASA as an Easy VPN Server. The following are tasks you need to perform on the 7.0 security appliance to set it up as a Server:

• Enabling ISAKMP, including policies (discussed in the last chapter)

• Defining IP address pools (discussed previously in the “Address Pool Configuration for 6.x” section)

• Creating tunnel groups (this is new in 7.0)

• Specifying where user accounts are located, locally on the PIX/ASA or on an AAA server (discussed previously in the “XAUTH User Authentication Configuration for 6.x” section)

• Creating user accounts, if specified locally

• Defining IPsec transform sets for data connections (discussed in the last chapter)

• Creating a dynamic crypto map for remote access users (discussed in the last chapter)

• Referencing the dynamic crypto map as an entry in a static crypto map (discussed in the last chapter)

• Activating the static crypto map on the PIX/ASA’s interface

Because I described many of the above tasks previously in this and the last chapter, the next few sections will focus on configurations unique to FOS 7.0, including:

• Understanding Tunnel Groups

• Defining Group Policies

• Creating Tunnel Groups

• Creating User Accounts for XAUTH

Following these sections, I’ll also discuss issues with remote access sessions and solutions that are provided in FOS 7.0, and an example that will illustrate the configuration of an Easy VPN Server running FOS 7.0.

Understanding Tunnel Groups

The main IPsec change from 6.3 to 7.0 is the introduction of the tunnel group feature. Tunnel groups allow you to define VPN session policies associated with a particular session or group of sessions, like a related group of remote access users or L2L sessions. Tunnel groups are used to simplify the configuration and management of your IPsec sessions. By default, two tunnel groups already are created on your PIX/ASA: “DefaultL2LGroup” for L2L sessions and “DefaultRAGroup” for remote access sessions. A tunnel group might include parameters such as general policy information and information to build IPsec sessions.

A group policy is used to define attributes associated with a user or group of users. It is associated with a tunnel group. A default group policy, called “DfltGrpPolicy,” exists on the security appliance for users who are not associated with a specific remote access group (similar to the Base Group on a VPN 3000 concentrator).

The use of tunnel groups involves three configuration steps:

Step 1	Define group policies.
Step 2	Create tunnel groups.
Step 3	Create user accounts for XAUTH.

The above three tasks replace the function of the vpngroup command in FOS 6.x. Tunnel groups must be configured locally on a PIX/ASA. The following three sections will discuss each of these steps in more depth.

Defining Group Policies

Group policies define attributes you want to assign to remote access clients during IKE Mode Config that belong to a particular remote access group. These policies either can be defined locally or on an AAA RADIUS server. Creating policies locally is done with the group-policy

command. Once policies are created, you then must associate them with a tunnel group, which specifies the group name the remote access users will use. This section discusses how you create group policies, and the next section discusses how you associate the policies to a tunnel group that is used for the remote access clients.

Group Policy Locations

Your group policies for your remote access users can be defined locally or on an AAA RADIUS server. To define the location of a group’s policies, use the following command:

security(config)# group-policy group_policy_name {internal
       [from group_policy_name]| external
       server-group server_tag password
       server_password

The group-policy command can be used to specify the location of the group policy information. internal specifies that the policies are defined on the PIX/ASA itself and external on an AAA RADIUS server. If you specify internal, you can even specify for the group policy, whatever other group policy it should use to get its default policies from (similar to the VPN 3000 concentrators’ Base Group feature). The server_tag parameter specifies which AAA RADIUS server to use by looking for the same tag in the aaa-server commands and the password for the access; TACACS+ is not supported.

Default Group Policies

There is a default group policy, called “DfltGrpPolicy” on the appliance, which supports the following default policies (you can treat this as the Base Group found on a VPN 3000 concentrator). These can be viewed with the show running-config all group-policy DfltGrpPolicy command, shown here:

• Default domain name: none

• DNS server addresses: none

• Split DNS: disabled

• WINS server addresses: none

• Access hour restrictions: none

• Simultaneous login restrictions: 3

• Tunnel session idle timeout: 30 minutes

• Maximum session connection timeout: none

• Filter applied to tunneled traffic: none

• Supported tunneling protocol: IPsec and WebVPN

• Allowing a user to store the XAUTH password locally: disabled

• Re-authenticate users upon expiration of the tunnel: disabled

• Locking a user into a group: disabled

• Restricting client types and version: disabled

• Compression of tunneled traffic: none

• Using PFS: no

• Login banner: none

• Backup server list: use the client-defined list

• Using IPsec over UDP: disabled

• For IPsec over UDP, the default port number: 10,000

• Split tunneling policy: disabled (tunnel all traffic)

• Split tunneling network list: none

• Software client firewall policy: none

• Secure unit authentication for hardware clients: disabled

• User authentication for hardware clients: disabled

• User authentication idle timeout: none

• IP phone bypass feature for user authentication: disabled

• LEAP bypass feature for user authentication: disabled

• Network extension mode for hardware clients: disabled

Default and Specific Group Policy Attribute Configuration

You can change the values for the default group policy or define local policies for specific internal groups with the group policy attributes command. The configuration of the policy attributes is shown here:

security(config)# group-policy {DfltGrpPolicy | group_policy_name}
       attributes
security(config-group-policy)# domain-name domain_name
security(config-group-policy)# dns-server value IP_address
       [IP_address]
security(config-group-policy)# split-dns domain_name1 domain_name2
       ... domain_nameX
security(config-group-policy)# wins-server value IP_address
       [IP_address]
security(config-group-policy)# dhcp-network-scope IP_network_#
security(config-group-policy)# vpn-access-hours value time_range_name
security(config-group-policy)# vpn-simultaneous-logins number
security(config-group-policy)# vpn-idle-timeout minutes
security(config-group-policy)# vpn-session-timeout minutes
security(config-group-policy)# vpn-filter value ACL_name
security(config-group-policy)# vpn-tunnel-protocol [ipsec] [webvpn]
security(config-group-policy)# password-storage {enable | disable}
security(config-group-policy)# re-xauth {enable | disable}
security(config-group-policy)# group-lock value tunnel_group_name
security(config-group-policy)# client-access-rule priority
       {permit | deny}type type version none
security(config-group-policy)# ip-comp {enable | disable}
security(config-group-policy)# pfs {enable | disable}
security(config-group-policy)# banner value string
security(config-group-policy)# backup-servers {server1 server2 ...
        server10 | clear-client-config |
        keep-client-config}
security(config-group-policy)# ipsec-udp {enable | disable}
security(config-group-policy)# ipsec-udp-port port
security(config-group-policy)# split-tunnel-policy {tunnelall |
       tunnelspecified | excludespecified}
security(config-group-policy)# split-tunnel-network-list
       value ACL_name
security(config-group-policy)# client-firewall {none | {{opt | req}
       firewall_type} policy {AYT |
       CPP acl-in ACL_name acl-out ACL_name}}
security(config-group-policy)# secure-unit-authentication
       {enable | disable}
security(config-group-policy)# user-authentication-idle-timeout
       minutes
security(config-group-policy)# ip-phone-bypass {enable | disable}
security(config-group-policy)# leap-bypass {enable | disable}
security(config-group-policy)# nem {enable | disable}

The above configuration applies only if the group policy type is defined as internal from the previous section. Using the attributes parameter with the group-policy command takes you into a subcommand mode where you can change the policies for the default group policy or a specific group policy.

Note

These are policies for the group or groups—not the group itself. I discuss the use of groups in the next section.

The domain-name command allows you to specify a domain name to assign to a remote access device. The domain name can be up to 63 characters in length. The dns-server value command allows you to specify up to two DNS servers for the remote access clients. The use of these servers overrides the client’s locally configured DNS servers unless you set up split DNS with the split-dns command. You can define as many domain names as you like for the split-dns command; however, the entire string cannot exceed 255 characters. Any domain names listed here will cause the client to use the DNS servers in the dns-server value command; other domain names will be resolved using the DNS server configured locally on the client. The wins-server value command allows you to specify up to two WINS server addresses to assign remote access clients. The dhcp-network-scope command is used only when the appliance will obtain a user’s internal IP address from a DHCP server. This command specifies the network number the DHCP server should pull a dynamic IP address from. I discuss the assignment of internal IP addresses to clients in the next section.

The vpn-access-hours value command specifies a time range configuration to use to restrict a remote access device’s VPN access, based on a time of day, day of week, or a specific day when connecting to the Easy VPN Server. The time range configured with the time-range command is the same as how you would configure this on IOS-based routers. The following commands configure a time range:

security(config)# time-range time_range_name
security(config-time-range)# absolute [start hh:mm date]
       [end hh:mm date]
security(config-time-range)# periodic day_of_the_week time to
       [day_of_the_week] hh:mm

The name of the time range cannot exceed 64 characters. Upon executing the time-range command, you are taken into a subcommand mode. The absolute command specifies a specific, one-time-only period when access is allowed. The time is entered in an hours and minutes format based on a 24-hour time period, like 23:00 for 11 PM. The date is entered by entering the day of the month, followed by the name of the month, and then a 4-digit year, like “23 May 2005.” If you don’t enter a starting time, the current time is used; if you don’t enter an ending time, the time period is infinite. For remote access, this typically is used to give a group temporary access to the Easy VPN Server, which, upon the end time, access is then denied. This type of configuration would be common for temporary consultants or extranet partners.

The periodic subcommand is used more commonly in situations that occur periodically because it allows you to specify recurring time intervals when access is allowed. For the day_of_week parameter, you can use “Monday,” “Tuesday,” “Wednesday,” “Thursday,” “Friday,” “Saturday,” “Sunday,” “daily” (Monday through Sunday), “weekdays” (Monday through Friday), and “weekend” (Saturday and Sunday); you also can specify more than one day for the day_of_week parameter. The time is specified in an hour and minute format based on a 24-hour period. If you omit the second day_of_week parameter, it defaults to the first value. For example, periodic weekdays 07:00 to 18:00 would allow access from 7 AM to 6 PM Monday through Friday, but deny access any other time.

Tip

To ensure that the security appliance has the correct time when restricting VPN access usage, I highly recommend that you use an internal NTP master clock. This is especially true if the appliance is using certificates for device authentication.

The vpn-simultaneous-logins group policy command limits the number of simultaneous logins allowed for any single user. The default is 3, but this can range from 0–2, 147, 483, 647. Normally you don’t want Remotes to share usernames and passwords, so this should be a low value. The vpn-idle-timeout command controls how long an idle Remote session is allowed before it is terminated; this defaults to 30 minutes but can range from 1–35, 791, 394 minutes. The vpn-session-timeout command specifies a maximum number of minutes the Remote can connect to the Server before the Server disconnects the Remote, even if traffic is being transmitted between the two devices. There is no limit, by default, but you can specify a value from 1–35, 791, 394 minutes.

Once a tunnel is established from the Remote to the Server, the Server will allow all traffic that is tunneled to it to exit the tunnel. You can restrict traffic across the tunnel by using the vpn-filter value command, where you need to specify a named ACL on the Server. The vpn-tunnel-protocol command can be used to restrict what remote access protocol or protocols (IPsec or WebVPN) can be used by remote access users associated with the policy; the default is IPsec (only the ASA currently supports WebVPN).

The password-storage command specifies the policy concerning the storage of the XAUTH password on the Remote. By default this is disabled. It is recommended to keep it disabled for software clients, but must be enabled for hardware clients where the default authentication method is unit authentication (the username and password are stored on the hardware client). If you need to support both software and hardware clients, in this situation create two policies: for the software clients, leave it disabled and for the hardware clients, enable it. The re-xauth command controls whether or not users must re-authenticate when IKE rekeying occurs (the management connection is rebuilt). By default this is disabled; if the rekeying interval is short, you’d probably want to keep this disabled. Also, for SUA and user authentication, this might cause the tunnel to fail if no user is there to perform the authentication. Plus, if you are using network extension mode and have IP phones at the remote site, you probably don’t want to use this feature.

The group-lock command forces users who belong to a specific group to connect only to the specified group (the tunnel_group_name). This is disabled, by default, which allows a user to connect to any group if they know the pre-shared key for that group (assuming pre-shared key authentication is being used).

The client-access-rule command allows you to restrict the termination of remote access sessions on the appliance, based on the type of client and the client’s software version. The priority value ranks the rules, where 1 is the highest priority and is processed first by the Server. The type value is the type of VPN client, like “VPN 3002.” You can’t choose any type; instead, the value you enter (including the quotes, if the client type is more than one word) must match exactly as it is displayed in the output of the show vpn-sessiondb remote command. This also is true of the client version in the version parameter. You can wildcard the version with an “*,” like “4.*” (matches all 4.x versions); or “*” (by itself matches on any version). For example, client-access-rule 1 deny type WinNT version* prevents all software clients running on Windows NT from connecting to the appliance, whereas client-access-rule 2 permit type “Cisco VPN Client” version 4.* would allow all other software client connections, assuming that they were running some 4.x version of software. You can create only 25 of these rules per group policy. Also, for clients that don’t send the type or version, you can specify “n/a” for each of these values.

The ip-comp command allows for compression of IP packets using LZS compression. This should be used only by remote access groups with only software-based users using dialup connections; for broadband users, enabling this can affect their throughput negatively in most situations if the user has enabled compression inadvertently. Therefore, enable this policy attribute only when it is associated with a group of dialup-only users. The pfs command enables the use of DH for sharing keys when building the data SAs during ISAKMP/IKE Phase 2; by default this is disabled. The banner value command specifies a banner that should be displayed once the Remote connects. By default, no banner is displayed. The banner can be up to 510 characters in length. You can’t type the banner across multiple command lines in the banner value command; however, you can insert carriage returns into the banner by specifying “\n” in the banner message (this counts as two characters).

The backup-servers command specifies a list of up to 10 backup Easy VPN Server addresses to push down to the Remote; the Remote then will erase any list it has and use this list. The default value is the keep-client-config parameter, which specifies that the client should use its locally configured backup server list. Specifying the clear-client-config parameter has the client remove its configured backup server list.

IPsec over UDP is enabled with the ipsec-udp command (it’s disabled by default). As with the VPN 3000 concentrators, this is enabled on a group-by-group basis, whereas IPsec over TCP and NAT-T are enabled globally with the isakmp command (discussed in the last chapter). If you enable IPsec over UDP, you must enable it manually on the Cisco VPN Client software and VPN 3002 hardware appliance—Cisco router and PIX Remotes currently don’t support IPsec over UDP. The default port number for IPsec over UDP is 10,000, but this can range from 4,001–49, 151, except for 4,500, which is used by NAT-T. Remember that IPsec over UDP is proprietary to Cisco and will work only with certain Cisco devices.

The split-tunnel-policy command allows you to specify whether or not split tunneling is enabled; by default, all traffic must be tunneled (the tunnelall parameter). If you configure the tunnelspecified parameter, traffic matching permit statements in the ACL defined in the split-tunnel-network-list command are tunneled and traffic matching the deny statements is sent in clear text. If you configure the excludespecified parameter, traffic that matches permit statements in the ACL defined in the split-tunnel-network-list command is sent in clear text and traffic matching the deny statements is protected.

The client-firewall command is used to define the firewall policy the remote user (Cisco Windows VPN Client software) must use when connecting to the Server. The syntax of the command is slightly different based on the firewall that you want the user to use, so here’s a list of the firewall commands based on the firewall that you want users to use:

hostname(config-group-policy)# client-firewall none
hostname(config-group-policy)# client-firewall opt | req custom
       vendor-id num product-id num policy AYT |
       {CPP acl-in ACL_name acl-out ACL_name}
       [description string]
hostname(config-group-policy)# client-firewall opt | req
       {zonelabs-zonealarm | zonelabs-zonealarmpro |
       zonelabs-zonealarmorpro} policy AYT |
       {CPP acl-in ACL_name acl-out ACL_name}
hostname(config-group-policy)# client-firewall opt | req
       cisco-integrated acl-in ACL_name
       acl-out ACL_name
hostname(config-group-policy)# client-firewall opt | req
       {sygate-personal | sygate-personal-pro |
       sygate-security-agent | networkice-blackice |
       cisco-security-agent}

I discussed the configuration of client firewall policies on the concentrator in Chapter 7, “Concentrator Remote Access Connections with IPsec.” The only difference between configuring it on the concentrator and the security appliance is that the security appliance uses a CLI. There are three firewall types: none (the default), opt (optional), and req (required). If you specify the latter two, you must specify the firewall software that the user must have installed and running. The two policies a firewall might support are Are You There (AYT) and CPP (Custom Policy Push or Protection). For CPP, you must specify the name of an ACL you’ve already created on the appliance that will be used to filter traffic entering the client (acl-in) and another ACL that will be used to filter traffic leaving the client (acl-out). This is different from the VPN 3000 concentrator, where in a filter you can have both inbound and outbound rules: on the PIX/ASA, you must have a separate ACL for each. The CIC client (cisco-integrated) supports only CPP; Sygate, NetworkICE, and CSA only support AYT; and Zone Labs firewalls support both.

The rest of the commands discussed in the group policy attributes subcommand mode apply to only two hardware clients. The secure-unit-authentication command enables SUA (referred to as Interactive Unit Authentication on the VPN 3002 hardware client), where only a single user must authenticate to bring up the tunnel and then all users can use the tunnel; this is disabled by default (unit, or the default/device, authentication is used). When enabled, the hardware client will not store the XAUTH password on the box; also, you must specify an authentication server group tag to use, which could be “LOCAL,” for the tunnel group, which tells the appliance where to find the user accounts (this is discussed in the next section).

The user-authentication command specifies that all users must authenticate to either bring up or to use an existing tunnel to the Server. This, too, is disabled by default. If you enable it, you can override the default idle timeout for authenticated users, which defaults to 30 minutes, with the user-authentication-idle-timeout command. This value can range from 1–35, 791, 394 minutes. Please note that this command affects a user’s access only through the tunnel, not the lifetime of the tunnel itself, which is negotiated during ISAKMP/IKE Phase 1.

The ip-phone-bypass and leap-bypass commands allow IP phones, and wireless devices using LEAP authentication, to bypass user authentication when enabled for a group, which is necessary in this situation. Both of these will not work properly if the Easy VPN Server is configured for SUA and no one else has brought up the tunnel first. LEAP bypass is necessary only if the LEAP authentication needs to be performed across the IPsec tunnel to the network connected behind the Server.

The nem command is used to enable network extension mode; by default, client mode is used for groups containing hardware clients. This mode should be used when you have devices at the Remote that the central office needs to establish connections to, such as a file server or IP phones.

Note

To set a group’s policy value back to its default, use the attribute command followed by the none keyword, like vpn-idle-timeout none.

Creating Tunnel Groups

There are two default tunnel groups on your security appliance: “DefaultRAGroup” for remote access users and “DefaultL2LGroup” for site-to-site sessions. You can modify the properties of these default tunnel groups, but cannot delete them; however, you can create additional tunnel groups if necessary. The configuration of tunnel groups is different between remote access and L2L sessions. The next two sections will discuss each remote access tunnel group’s properties and the third section will discuss L2L tunnel group properties.

Remote Access Tunnel Group General Properties

Creating a tunnel group for remote access sessions requires either configuring the existing default remote access tunnel group (similar to the Base Group on a VPN 3000 concentrator) or creating specific tunnel groups. The configuration of a tunnel group for remote access sessions involves the configuration of two sets of properties: General and IPsec. The following commands discuss how to configure a remote access tunnel group’s general properties:

security(config)# tunnel-group group_name type ipsec-ra
security(config)# tunnel-group {DefaultRAGroup | group_name}
       general-attributes
security(config-general)# address-pool [(interface name)]
       address_pool1 [...address_pool6]
security(config-general)# dhcp-server hostname1 [...hostname10]
security(config-general)# authentication-server-group
       {LOCAL | AAA_server_tag}
security(config-general)# authorization-server-group
       {LOCAL | AAA_server_tag}
security(config-general)# accounting-server-group
       {LOCAL | AAA_server_tag}
security(config-general)# default-group-policy {DfltGrpPolicy |
       group_policy_name}
security(config-general)# strip-realm
security(config-general)# strip-group
security(config-general)# exit

The tunnel-group type command specifies the type of the tunnel: the ipsec-ra parameter indicates that the tunnel type is for remote access client sessions. The group name for the tunnel group clumps together the tunnel-group commands. The tunnel-group general-attributes command specifies general attributes for the remote access tunnel of the specified group name, which can include the default group (DefaultRAGroup). This command takes you into a subcommand mode where you can configure the general properties for the remote access group.

The address-pool command specifies the address pool or pools created by the ip local pool command that should be used by the group. I discussed the ip local pool command earlier in the “Address Pool Configuration for 6.x” section. You can qualify which logical interface name on the appliance the pool should be used with—this is necessary only if clients might terminate their VPN tunnel on more than one interface on the appliance. If you don’t specify an interface name, the address pool(s) can be used for any interface the client terminates its VPN tunnel on. You can define up to six different address pools for a single group.

The configuration of local pools, as shown in the following code, is necessary when the vpn-addr-assign command specifies the local parameter:

security(config)# vpn-addr-assign {aaa | dhcp | local}

There are no defaults to this global command, so you must specify where remote access users will obtain their addressing from. If you specify aaa, you’ll need to define the addresses on the AAA RADIUS server in each user’s account; this is discussed further in this section. If you specify dhcp, you must use the dhcp-server command to define the IP address or name of the DHCP server or servers that have the user’s addressing information; you can define up to 10 DHCP servers.

If you’re using an AAA server to store the user accounts and addressing information, you must use the authentication-server-group command to specify the AAA group tag that defines the protocol and AAA servers that contain this information (this references the aaa-server commands on the appliance). If you specify LOCAL (the default, if unspecified), the appliance will look for the user accounts on the PIX/ASA itself by searching for username commands, discussed later in the “Creating User Accounts for XAUTH” section of this chapter.

If you’ve defined your group policies on the PIX/ASA appliance with the group-policy commands, you don’t need to configure AAA authorization in the tunnel group (it defaults to LOCAL); otherwise, if the group policies are on an AAA RADIUS server, you need to specify the AAA group tag to use to download the group policies (this references the aaa-server commands that tell the appliance what protocol and server or servers to use). This is configured with the authorization-server-group command.

For AAA authentication and authorization functions, you can create accounting records on your AAA server, like when a user brought up a tunnel and authenticated. To perform this function, configure the accounting-server-group command, and the required AAA group tag that references the AAA server or servers that will store the accounting records. There is no option for storing these records locally on the PIX/ASA, or for sending them as syslog messages to a syslog server.

Note

If you’re using AAA, in most cases, the AAA group tag is the same for authentication, authorization, and accounting; however, you can have different sets of servers handling the three separate functions. The configuration of AAA on the security appliance is beyond the scope of this book.

The default-group-policy command references the name of the group policy (configured with the group-policy commands discussed in the last section) that should be used for this group. You can specify the default policy (DfltGrpPolicy) or specify a specific group policy you created. If you forget to define a policy, the default group policy is used. Only one policy can be applied to a group.

The strip-realm, when configured, causes the appliance to strip off any realm qualifier in the user’s XAUTH information. With many systems, the user might send something like username@realm; this command would strip off the “@realm” portion of the username. This would be required when authentication is occurring externally on an AAA server and the AAA server doesn’t support this capability. The strip-group command performs the same function, removing any group name that is appended to the user’s name in this format: username@group. By default, both of these are disabled.

Remote Access Tunnel Group IPsec Properties

Once you’ve defined your general properties for your tunnel group, you’re ready to define its ISAKMP/IKE/IPsec properties. This is done with the following configuration:

security(config)# tunnel-group group_name ipsec-attributes
security(config-ipsec)# pre-shared-key key
security(config-ipsec)# peer-id-validate {req | cert | nocheck}
security(config-ipsec)# chain
security(config-ipsec)# trustpoint trustpoint_name
security(config-ipsec)# authorization-dn-attributes
       {primary_attribute [secondary_attribute] |
       use-entire-name}
security(config-ipsec)# authorization-required
security(config-ipsec)# radius-with-expiry
security(config-ipsec)# client-update type type url url_string
       rev-nums revision_numbers
security(config-ipsec)# isakmp keepalive threshold number retry number

The tunnel-group ipsec-attributes command defines ISAKMP/IKE/IPsec attributes for your remote access group. Executing this command takes you into a subcommand mode where you can define your properties. If the remote access group is using pre-shared keys, use the pre-shared-key command to define the key. The key can be between 1–128 characters in length. If you’re going to use certificates, omit the configuration of this command.

When using certificates in your network, you can configure a certificate policy on your appliance with the peer-id-validate command. If you specify the req parameter, the peer must use a certificate. The cert parameter specifies that if the appliance has a certificate and an ISAKMP policy with certificates enabled, and the peer has and wants to use certificates, the appliance will use certificates for device authentication. The nocheck parameter specifies that the appliance should not check for the use of certificates. If you don’t configure a pre-shared key for the group with the pre-shared-key command, the default value for this command is req. Remember that if you’ll be using certificates, you’ll need an ISAKMP/IKE Phase 1 policy that includes certificates for device authentication.

If you are using a hierarchical implementation with certificates and want to send the appliance’s subordinate root certificate and the certificates for the other higher-level root certificates, use the chain command; by default, the appliance will send only the root certificate of the CA that generated the appliance’s identity certificate. If your appliance has two identity certificates from two different roots, you can specify which identity certificate to use for the remote access group by using the trustpoint command followed by the name of the trustpoint that generated the appliance’s identity certificate.

You also can specify which field to use on the certificate for user authorization. By default, this is only the CN field on the certificate, but can be changed with the authorization-dn-attributes command. Attributes you can specify are CN (common name), OU (organizational unit), O (organization), L (locality), SP (state/province), C (country), UID (user ID), T (title), SN (surname), N (name), I (initials), GN (given name), DNQ (DN qualifier), EA (e-mail address), SER (serial number), and GENQ (generational qualifier). You can specify up to two attributes. The use-entire-name parameter specifies that the appliance should use the entire subject DN information to derive the user name credentials. The default value for the primary attribute is DN and the secondary attribute is OU.

The authorization-required command specifies that a user must be authorized before allowing the user to connect (this is disabled, by default). If your appliance will be using MS-CHAPv2 to negotiate a password update with a user during authentication, you need to configure the radius-with-expiry command. This is necessary only if the remote client is using Cisco VPN Client software and the user account is stored on an AAA RADIUS server; Microsoft’s L2TP/IPsec client is not presently supported.

The client-update command specifies which clients should be running which version of software; if the client is not running the specified software version, it tells the client where to download the correct version. The type parameter refers to the type of client, which can be Win9X (Windows 95, 98, and ME), WinNT (Windows NT 4.0,2000,and XP), Windows (all Windows platforms), and vpn3002 (3002 hardware client). The url parameter specifies the URL location to download the file if the client isn’t running the specified client version. The client version is specified by the rev-nums parameter, like 4.6.1 or 4.1.7.Rel. This process also is discussed in Chapters 12, “Cisco VPN Software Client,” and 14, “3002 Hardware Client.” For a VPN 3002 hardware client, the URL must use TFTP for the download; for the Windows client, use HTTP or HTTPS. Within a tunnel group, you can specify up to four client update entries by executing the client-update command four times with different update entries.

Note

The VPN 3002 supports automatic updates. It will download the correct software version automatically, install it, and reboot itself. Only the 4.6 version of the Cisco VPN Client for Windows supports this feature for software clients; prior versions of the VPN Client require the user to download the software update, uninstall the software client, reboot the PC, install the new client, and re-reboot the PC.

The isakmp keepalive threshold command defines the values for dead peer detection (DPD). The default threshold is to send an ISAKMP/IKE keepalive every 300 seconds for remote access groups and every 10 seconds for L2L groups, but this can range from 10–3,600 seconds. If a response is not received for a keepalive, the appliance will retry in 2 seconds, but this value can range from 2–10 seconds.

L2L Tunnel Groups

FOS 6.x had one problem with IPsec VPNs: if you wanted to terminate both L2L and remote access sessions on a PIX, remote access users using pre-shared keys could be confused with L2L peers with dynamic addresses and wildcarded pre-shared keys, and treated as an L2L peer, causing session failures because the client was expecting XAUTH and IKE Mode Config. Version 7.0 uses tunnel groups to deal with this issue.

I’ve already discussed how to set up tunnel groups and group policies for remote access users. With L2L sessions, you also can use tunnel groups to define properties for the L2L peers, as shown in the following configuration code:

security(config)# tunnel-group peer_name_or_IP_address type ipsec-l2l
security(config)# tunnel-group {DefaultL2LAGroup | group_name}
       general-attributes
security(config-general)# accounting-server-group
       {LOCAL | AAA_server_tag}
security(config-general)# exit
security(config)# tunnel-group peer_name_or_IP_address
       ipsec-attributes
security(config-ipsec)# pre-shared-key key
security(config-ipsec)# peer-id-validate {req | cert |nocheck}
security(config-ipsec)# chain
security(config-ipsec)# trustpoint trustpoint_name
security(config-ipsec)# isakmp keepalive threshold number retry number

The tunnel-group command specifies the L2L peer that is connecting to the appliance. If the ISAKMP identity type is IP address (configured with the isakmp identity command), then you specify the IP address of the peer; if the type is hostname, you specify the name of the remote peer. For peers that obtain their addresses dynamically, you would use the default L2L group (DefaultL2LGroup). The tunnel type must be configured as ipsec-l2l. The only general attribute that is applicable for L2L sessions is AAA accounting. For IPsec attributes, only the pre-shared-key, peer-id-validate, chain, trustpoint, and isakmp keepalive threshold commands are applicable: these commands were discussed in the last section.

Creating User Accounts for XAUTH

On FOS 7.0 Easy VPN Servers, if you have defined a group policy for remote access users that specifies that their accounts are stored on the security appliance, you’ll need to create the accounts and, possibly, specific user policies for your users. These specific user policies can override the group policies. For example, the group policy might specify that users in the group can connect to the appliance only during business hours; however, for a specific user or users you can override the group policy and define a different restriction, or ignore the restriction.

To create users locally, use the following command:

security(config)# username user's_name password password
       [privilege privilege_level]

The username command creates a user’s account; whatever password you configure on the appliance will be encrypted by the appliance automatically and cannot be seen once configured. The appliance supports 16 privilege levels: 0–15, where 0 restricts the user to very few appliance commands and 15 allows access to all commands. If you don’t specify the privilege level, it defaults to 2.

Caution

If AAA is enabled on your appliance, if you’ve defined both management and XAUTH accounts locally, and if you are using these accounts for management access to the PIX, the XAUTH accounts can be used to access the PIX. Based on this issue, you can use an AAA server for the XAUTH accounts and then specify on the AAA server that local login access (to the ASA) is not allowed. If this is not an option, set the privilege level to 0 for the XAUTH accounts, restricting what the user can execute on the appliance.

When you add a user locally, it does not have any attributes associated with it and is associated with a group only when the user brings up a remote access session and either provides the group name with the pre-shared key or the group name is obtained from the user’s certificate. With 7.0, you now have the ability to define attributes specific to a user with the following commands:

security(config)# username user's_name attributes
security(config-username)# vpn-group-policy group_policy_name
security(config-username)# vpn-framed-ip-address IP_address
security(config-username)# vpn-access-hours value time_range_name
security(config-username)# vpn-simultaneous-logins number
security(config-username)# vpn-idle-timeout minutes
security(config-username)# vpn-session-timeout minutes
security(config-username)# vpn-filter value ACL_name
security(config-username)# vpn-tunnel-protocol [ipsec] [webvpn]
security(config-username)# group-lock value tunnel_group_name
security(config-username)# password-storage {enable | disable}

The username attributes command takes you into a subcommand mode where the attributes you specify in this mode apply only to this user; plus, any attributes you define here automatically override any group attributes assigned to the user based on the user’s group membership.

The vpn-group-policy command specifies the name of the group policy configured in the group-policy command that should be applied to the user, allowing the user to inherit the policies from the specified policy. If you don’t configure this command, the user inherits no properties by default, but obtains these once the user connects and specifies the group name, if any, that user should be associated with. This command is commonly used for remote access clients that don’t or can’t specify a group name for their membership.

The vpn-framed-ip-address command allows you to assign a specific IP address to a user instead of assigning an address dynamically from a locally configured pool, a DHCP server, or an AAA server. This is useful if you have per-user policies based on ACLs behind the security appliance, and the user always must use the same IP address.

I discussed the rest of the commands previously in the “Default and Specific Group Policy Attribute Configuration” section. If you don’t configure any attributes for the user, the user will use the attribute defined by the group policy that user is associated with, after being authenticated.

Once you’ve created your users and, possibly, specific user policies, you can view them with the show running-config all username command.

Tip

For the one or two remote access hardware clients that are set up for default unit authentication, where you must store the XAUTH username and password locally on the hardware client, instead of creating a separate group for this small number of hardware clients, you could set up their usernames with the password-storage enable command. By doing this, you still could put the hardware clients in the same group as remote access users, but allow the use of default unit authentication.

Issues with Remote Access Sessions and Solutions in 7.0

In this last section covering the 7.0 software and Easy VPN Servers, I’ll discuss some issues related to remote access users, including problems and solutions related to the following:

• Simultaneously supporting both remote access and L2L sessions

• Using more than one Server to handle remote access sessions

• Restricting the total number of VPN sessions

Simultaneously Supporting Remote Access and L2L Sessions

One problem that has always existed on the PIX in FOS 6.x and earlier versions was supporting both remote access and L2L sessions simultaneously. Even when using certificates, there still might be a problem where:

• Certain remote access users are associated with an L2L session

• An L2L session is associated with a default remote access group

To overcome this problem, one solution is to create certificate map rules and then associate these rules with a particular tunnel group (assuming you’re using certificates for device authentication). Certificate map rules allow you to look at X.500 information on a certificate, and based on matching criteria you specify, such as certain CN and/or OU values, you can associate the device of that certificate with a specific tunnel group; this ensures that remote access users are associated with remote access tunnel groups and L2L peers with L2L tunnel groups.

Using the certificate map rules feature involves two steps: configuring the certificate mapping rules and then associating them with a tunnel group. The following two sections will discuss each of these steps, followed by an example configuration.

Configuring Certificate Mapping Rules

Certificate mapping rules allow you to specify which fields on a certificate you want to examine and which values should be found in those fields. Creating a certificate mapping rule involves the following commands:

security(config)# crypto ca certificate map rule_#
security(config-ca-cert-map)# issuer {eq | ne | co | nc} value
security(config-ca-cert-map)# subject-name [attr tag]
       {eq | ne | co | nc} string

The crypto ca certificate map command is used to create mapping rules. You can create multiple rules, where each rule is given a different number from 1–65,535. Rules are processed in numerical order. Executing this command takes you into a subcommand mode. The issuer command allows you to look at the issuer field on the identity certificate for a match—this can be used if you have two identity certificates from two different CAs and want to specify the correct IPsec tunnel group (and thus CA) to use for device authentication. You can match a value in the issuer field using the following values:

• eq—equal to the specified value

• ne—not equal to the specified value

• co—contains the specified value

• nc—does not contain the specified value

For example, issuer eq caserver in the rule specifies that the issuer on the certificate must match “caserver.” The match type parameter also is used in the subject-name command. This command specifies which contents of the certificate will be associated with the rule. If you don’t specify the attr parameter, the entire identity certificate information is used when looking for match in the string; otherwise, if you use this parameter, you can examine a specific field on the certificate: DNQ (DN qualifier), GENQ (generational qualifier), I (initials), GN (given name), N (name), SN (surname), IP (IP address), SER (serial number), UNAME (unstructured name), EA (e-mail address), T (title), O (organization name), L (locality), SP (state/province), C (country), OU (organizational unit), and CN (common name).

As an example of matching on identity information on a certificate, if you configured subject-name attr cn eq “richard deal,” this command would cause an identity certificate with the common name of “richard deal” to be associated with this rule; in addition, when the rule is associated with a tunnel group, the user of this certificate then could be placed in the correct tunnel group. This might be necessary for this user if the user was originally in the sales group and then moved to marketing, where you currently are using the OU field for the group name; however, when the user moved to the new group, instead of creating a new certificate for the user, you could create the appropriate certificate matching rule and then associate the rule with the user’s new group.

Associating Certificate Mapping Rules with a Tunnel Group

Once you’ve created your certificate mapping rules, you can then use them by associating the rules with a tunnel group. First, you must specify which type of matching will be used to associate a user to a group with this command:

security(config)# tunnel-group-map enable
       {ike-id | ou | peer-ip | rules}

If you don’t configure this command, the default matching is ou, which causes the appliance to use the OU field in a certificate when associating the remote access user or L2L peer to a group. If you want to use your certificate matching rules, you must configure the above command with the rules parameter. The ike-id parameter specifies group matching when certificates are being used—this is not done by the OU value on the certificate, but instead on the ID information shared during ISAKMP/IKE Phase 1. The peer-ip parameter specifies that the IP address of the peer is used to associate a peer to a particular tunnel group.

If you’re using the certificate matching rules, you can then use the following command to associate a match for a particular rule to a specific tunnel group:

security(config)# tunnel-group-map rule_# default-group
       tunnel_group_name

This command associates a specific matching rule for a specific group.

Illustrating the Use of Certificate Mapping Rules

Example 22-5 illustrates the use of certificate mapping rules. In this example, Alina was originally in the sales group, had an OU value of “sales” on her certificate, and correctly was associated with the sales group; however, she was moved over to marketing and needs to use the policies associated with this group. The configuration in Example 22-5 accomplishes this, assuming the CN field on Alina’s certificate is “alina deal.” Otherwise, the OU field is used to associate users to the marketing or sales group. Also, one L2L peer, asapeer, who has a CN of “asapeer.cisco.com,” is being associated to an L2L IPsec tunnel group called “asapeer.”

Example 22-5: Using Certificate Mapping Rules

asa(config)# crypto ca certificate map 1
asa(config-ca-cert-map)# subject-name attr co cn “alina deal"
asa(config-ca-cert-map)# exit
asa(config)# crypto ca certificate map 2
asa(config-ca-cert-map)# subject-name attr eq ou marketing
asa(config-ca-cert-map)# exit
asa(config)# crypto ca certificate map 3
asa(config-ca-cert-map)# subject-name attr eq ou sales
asa(config-ca-cert-map)# exit
asa(config)# crypto ca certificate map 4
asa(config-ca-cert-map)# subject-name attr co cn asapeer.cisco.com
asa(config-ca-cert-map)# exit
asa(config)# tunnel-group-map enable rules
asa(config)# tunnel-group-map 1 default-group marketing
asa(config)# tunnel-group-map 2 default-group marketing
asa(config)# tunnel-group-map 3 default-group sales
asa(config)# tunnel-group-map 4 default-group asapeer

Note

If you are using certificate mapping with an appliance terminating both remote access and L2L sessions, you can use the above feature easily to look at certificate information for L2L peers and put them into the correct L2L group, and remote access users in the correct remote access group; however, certificate mapping could involve a lot of configuration on your part to associate the right device or user to the correct tunnel group on the appliance. Therefore, I typically try to use this as a last resort when associating a peer with the correct tunnel group.

Using More than One Server to Handle Remote Access Sessions

With the introduction of FOS 7.0 and the ASA security appliances (5520s and 5540s), you now can use the load balancing feature (VCA) that only the VPN 3000 series concentrators originally supported. Unfortunately, this feature is not supported on the PIX security appliances; but one nice bonus is that the load balancing feature is fully compatible with the VPN 3000 concentrators and can be included in the same VCA cluster.

As you recall from Chapter 10, “Concentrator Management,” VCA requires that you set up a virtual IP address that the Easy VPN Remotes connect to. The master of the cluster handles this initial connection, examines the load across the members of the cluster, and sends back a physical address of the member with the least load. The Remote then connects to the physical address. If a member of the cluster fails, the Remote should be able to discover this quickly using DPD, reconnect to the virtual address, and thus be redirected to another member of the cluster.

Setting up VCA on an ASA involves the following commands:

asa(config)# vpn load-balancing
asa(config-load-balancing)# cluster ip address virtual_IP_address
asa(config-load-balancing)# cluster port port_#
asa(config-load-balancing)# cluster encryption
asa(config-load-balancing)# cluster key shared_secret_key
asa(config-load-balancing)# interface {lbprivate | lbpublic}
       logical_interface_name
asa(config-load-balancing)# nat IP_address
asa(config-load-balancing)# priority priority_#
asa(config-load-balancing)# participate

The vpn load-balancing command configures VCA, taking you into a subcommand mode to complete the configuration. The cluster ip address command specifies the virtual IP address of the cluster—this is what the Remotes will use for the Easy VPN Server address. The default port number of load balancing is UDP 9,023; this can be changed with the cluster port command. If you change the port number on one member in the cluster, you must match this on all members of the cluster. VCA messages sent between cluster members are not encrypted by default. The cluster encryption command enables the encryption of VCA messages and the cluster key command configures the encryption key to encrypt the messages (this must match what’s configured on the other members). The interface command specifies which logical interface on the ASA should be associated with the public interface (lbpublic) and which with the private (lbprivate). The nat command is necessary only if an address translation device sits between the cluster and the Remotes. This command specifies the global address that represents the address of the ASA on its public interface. When performing redirection, the master will send the global address to the Remote, which the Remote will use to connect to the cluster member. The priority command is used to affect which cluster member is chosen as the master: the higher the number the more likely the member will be chosen. The priority can range from 1–10. If you don’t configure it, the 5520 has a default priority of 5 and the 5540 a priority of 7. Last, you must enable load balancing with the participate command.

To view your load balancing configuration, use the show running-config vpn load-balancing command; to view the runtime statistics of the operation of load balancing, use the show vpn load-balancing command.

Setting up load balancing, as you can see, is simple. I’ll use Figure 22-3 to illustrate its configuration. Examples 22-6 and 22-7 show the configurations of the two ASAs. In this example, Remotes need to connect to 192.1.1.3, which, by default, ASA1 will handle because it has a higher priority.

Figure 22-3: ASA and Load Balancing

Example 22-6: Load Balancing on ASA1

asa1(config)# interface GigabitEthernet 0/1
asa1(config-if)# ip address 192.1.1.1 255.255.255.0
asa1(config-if)# nameif public
asa1(config-if)# security-level 0
asa1(config-if)# exit
asa1(config)# interface GigabitEthernet 0/2
asa1(config-if)# ip address 192.168.1.1 255.255.255.0
asa1(config-if)# nameif private
asa1(config-if)# security-level 100
asa1(config-if)# exit
asa1(config)# vpn load-balancing
asa1(config-load-balancing)# interface lbpublic public
asa1(config-load-balancing)# interface lbprivate private
asa1(config-load-balancing)# cluster ip address 192.1.1.3
asa1(config-load-balancing)# cluster key 123cisco
asa1(config-load-balancing)# cluster encryption
asa1(config-load-balancing)# priority 10
asa1(config-load-balancing)# participate

Example 22-7: Load Balancing on ASA2

asa2(config)# interface GigabitEthernet 0/1
asa2(config-if)# ip address 192.1.1.2 255.255.255.0
asa2(config-if)# nameif public
asa1(config-if)# security-level 0
asa2(config-if)# exit
asa2(config)# interface GigabitEthernet 0/2
asa2(config-if)# ip address 192.168.1.2 255.255.255.0
asa2(config-if)# nameif private
asa1(config-if)# security-level 100
asa2(config-if)# exit
asa2(config)# vpn load-balancing
asa2(config-load-balancing)# interface lbpublic public
asa2(config-load-balancing)# interface lbprivate private
asa2(config-load-balancing)# cluster ip address 192.1.1.3
asa2(config-load-balancing)# cluster key 123cisco
asa2(config-load-balancing)# cluster encryption
asa2(config-load-balancing)# participate

Note

Remember that members of a VCA cluster must be able to see each other off of all enabled interfaces. This means that the ASA must allow the VCA messages (UDP port 9,023) on any interface that contains an ACL. Also, the ASA must have an active 3DES/ AES license; if it doesn’t, any VCA configuration you’ve set up on the ASA is ignored by the ASA.

To use a PIX/ASA or not?

If I had to implement an Easy VPN Server or an L2L session and I had a choice between a PIX running FOS 6.x and another device, such as a concentrator for remote access or a router for L2L, I would very rarely choose the PIX because of its limitations. Some people like the 6.x software because setting up VPNs is simple; but the FOS 6.x software had too many limitations that typically wouldn’t provide the functionality I or my customers needed. However, with the introduction of 7.0, Cisco has greatly enhanced the capabilities of the PIX/ASA. Actually, if I had to choose between a router and a PIX/ASA for an Easy VPN Server, today I would easily choose the PIX/ASA because of their advanced capabilities, especially the ASA with its support of features like WebVPN and load balancing. And if I needed a one-box solution, with firewall, remote access VPN, and intrusion prevention in one box, I definitely would consider the PIX/ASA over a VPN concentrator or an IOS router.

Restricting the Total Number of VPN Sessions

One problem you might face with your appliance is dealing with the large number of IPsec sessions terminating on it. With the ASAs, this is more of a concern on the 5510 and, possibly, the 5520, because of their VPN session license limits. This can be problematic if one group of remote access users is using up all of the VPN sessions allowed by the appliance, leaving none for other groups or for L2L sessions. One solution to this is to disconnect the users with the vpn-sessiondb logoff command:

security# vpn-sessiondb logoff {remote | l2l | webvpn | email-proxy |
       protocol protocol_name | name username |
       ipaddress IP_address | tunnel-group
       tunnel_group_name | index indexnumber | all}

As you can see from the above command, you can terminate all remote access users with the remote parameter, all L2L users with the l2l parameter, a specific user with the name parameter, a user based on their IP address with the ipaddress parameter, all members of a particular tunnel group with the tunnel-group parameter, and others.

Also, if your appliance is overloaded, you can specify a lower limit of VPN sessions the appliance will accept. This is configured with the following command:

security(config)# vpn-sessiondb max-session-limit #_of_sessions

Illustrating an Easy VPN Server Configuration Example for 7.0

To better understand how tunnel groups and group policies are used to terminate Easy VPN Remote sessions on your security appliance acting as an Easy VPN Server, I’ll now show you a simple configuration example. In this example, I’ll use a PIX 515E running Version 7.0 as the Server and the network shown previously in Figure 22-1. This is basically the same example I illustrated earlier in the “6.x Easy VPN Remote Example Configuration”; however, this example will show you how to configure the Server running 7.0.

Example 22-8 shows the configuration of the Server. Reference numbers to the right of the configuration commands are explained below the example.

Example 22-8: Network with a 515E and 7.0 as an Easy VPN Server

Server(config)# interface ethernet0
Server(config-if)# ip address 192.1.1.1 255.255.0.0
Server(config-if)# nameif outside
Server(config-if)# exit
Server(config)# interface ethernet1
Server(config-if)# ip address 192.168.0.1 255.255.0.0
Server(config-if)# nameif inside
Server(config-if)# exit
Server(config)# isakmp policy 1 authentication pre-share       (1)
Server(config)# isakmp policy 1 encryption 3des
Server(config)# isakmp policy 1 hash sha
Server(config)# isakmp policy 1 group 2
Server(config)# isakmp policy 1 lifetime 3600
Server(config)# isakmp enable outside
Server(config)# access-list split-tunnel permit  (2)
       192.168.0.0 255.255.255.0
       192.168.0.0 255.255.255.0
Server(config)# group-policy salespolicy internal  (3)
Server(config)# group-policy salespolicy attributes
Server(config-group-policy)# domain-name cisco.com
Server(config-group-policy)# dns-server value 192.168.0.10
Server(config-group-policy)# split-dns cisco.com
Server(config-group-policy)# wins-server value 192.168.0.11
Server(config-group-policy)# vpn-session-timeout 15
Server(config-group-policy)# split-tunnel-policy tunnelspecified
Server(config-group-policy)# split-tunnel-network-list
       value split-tunnel
Server(config-group-policy)# client-firewall req
       sygate-personal-pro
Server(config-group-policy)# exit
Server(config)# ip local pool salespool                (4)
       192.168.0.200-192.168.0.254
Server(config)# username salesuser password sales123         (5)
Server(config)# tunnel-group salesgroup type ipsec-ra         (6)
Server(config)# tunnel-group salesgroup general-attributes
Server(config-general)# address-pool salespool
Server(config-general)# exit
Server(config)# tunnel-group salesgroup ipsec-attributes
Server(config-ipsec)# pre-shared-key salesgroup123
Server(config-ipsec)# isakmp keepalive threshold 20 retry 10
Server(config-ipsec)# exit
Server(config)# crypto ipsec transform set trans1           (7)
       esp-3des esp-md5-hmac
Server(config)# crypto dynamic-map dyn1 1 set             (8)
       transform-set trans1
Server(config)# crypto dynamic-map dyn1 1 set reverse-route
Server(config)# crypto map mymap 999 ipsec-isakmp dynamic dyn1
Server(config)# crypto map mymap interface outside
Server(config)# sysopt connection permit-ipsec

Here’s an explanation of the references in the above example:

1. An ISAKMP/IKE Phase 1 policy is defined for pre-shared keys and ISAKMP is enabled on the PIX’s outside interface.

2. A split tunneling ACL is configured: only the traffic sent to and from the Remotes to the cisco.com site is protected.

3. A policy called “salespolicy” is defined with the split tunneling policy, and with other parameters, including the requirement of Sygate’s firewall with the AYT feature.

4. An address pool is created to be used in the assignment of internal addresses to the Remotes.

5. A user is defined and will inherit its attributes from the group it authenticates to.

6. A remote access group is created and associated with the address pool in reference (4) along with a pre-shared key of “salesgroup123.”

7. A transform set is defined to protect the data SAs.

8. A dynamic and static crypto map are enabled, in addition to being activated on the outside interface; IPsec traffic is also exempted from ACL processing on the outside interface.

As you can see from this example, the configuration is more complex than an Easy VPN PIX Server running 6.2 or 6.3 code; however, you have much more flexibility and management in defining and associating polices for the Remote devices.

Note

The ASAs support the ability to terminate WebVPN sessions; however, the PIXs do not. The configuration of WebVPN is very similar to the configuration of it on Cisco routers, which was discussed in Chapter 18, “Router Remote Access Connections.” Therefore, I’ve omitted the discussion of WebVPN from this chapter.