Easy VPN Server Support for 6.x

Since the release of FOS 6.2, the PIX security appliances, from the 501 all the way up to the 535, can perform the function of an Easy VPN Server; and with the addition of the ASA appliances, they, too, can perform this function. Normally, I prefer to use a VPN 3000 concentrator to support a large number of remote access users; however, if you already have a PIX/ASA appliance in place and need to support only a small number of clients, you can use your existing PIX/ASA for this function. This is preferable to a router if your PIX supports a VAC+ encryption card to perform hardware encryption and your router lacks this, or if you need advanced address translation capabilities or security functions or features, which the router might lack.

The configuration of an Easy VPN Server is different if you're running FOS 6.3 or earlier when compared to 7.0. Because of the differences, I've split up the configuration explanation into the following two sections: one for 6.3 (this section) and one for 7.0 (the following main section).

Easy VPN Server Configuration for 6.x

Starting in FOS 6.2 and in later FOS releases, the PIX and ASA (7.0) appliances support the Easy VPN Server function, which allows them to terminate IPsec sessions from Easy VPN Remote devices, including the Cisco VPN Client software, the 3002 hardware client, the 800, ubr900, and 1700 routers, and the PIX 501 and 506E security appliances. As with the routers and concentrators performing the Easy VPN Server function, groups are used to apply policies to the Remotes connecting the Server.

Configuring an Easy VPN Server is broken into these components:

Step 1.	Create an address pool for remote access devices' internal addresses with the ip local pool command (this is required only for client mode connectionsnetwork extension mode connections do not require this).
Step 2.	Define group policies for remote access users with the vpngroup command.
Step 3.	Disable address translation for the users' internal addresses with the nat (interface) 0 access-list ACL_name command (discussed in Chapter 21).
Step 4.	Enable XAUTH with the crypto map map_name client authentication command.
Step 5.	Create ISAKMP policies with the isakmp policy command (discussed in the last chapter).
Step 6.	Define a compatible tunnel-mode transform set with the crypto ipsec transform-set command (discussed in the last chapter).
Step 7.	Create a dynamic crypto map with the crypto dynamic-map command (discussed in the last chapter).
Step 8.	Create a static crypto map and enable it with the crypto map command (discussed in the last chapter).
Step 9.	Enable IKE Mod Config for the static crypto map that has the dynamic crypto map reference with the crypto map map_nameclient configuration command.
Step 10.	Allow IPsec traffic with an ACL or the sysopt connection permit-ipsec command (discussed in the last chapter).

As you can see from the above steps, many of the things you have to configure I've already discussed in the last chapter, "PIX and ASA Site-to-Site Connections." Therefore, I'll focus primarily on Steps 1, 2, 4, and 9 in my discussions throughout this section. With hardware clients connecting to the PIX Server, additional items may be configured, like the type of connection (client versus network-extension mode) and the type of authentication (default, device, and user).

Address Pool Configuration for 6.x

An address pool is needed on the PIX Server to assign logical internal addresses to connecting Remote clients. The same command used on an IOS router to define an address pool is used on the PIX appliance:

pix(config)# ip local pool pool_name IP_first-IP_last
 [mask subnet_mask]

You can have different pools of addresses for different remote access groups. Each pool needs a unique name, which can contain up to 63 characters. Within a pool, you specify the IP addresses by listing the first address in the pool, followed by a dash (""), and then the last address in the pool, like this: 192.168.0.201-192.168.0.249. Optionally, you can specify a subnet mask value to ensure that the network number and directed broadcast addresses are not assigned to Remotes.

Note

Remember that any type of masking configuration on a PIX/ASA is a subnet mask, not a wildcard mask.

 

Group Configuration for 6.x

Groups are used to assign policies to the Remotes. The groups and policies are defined on the PIX and pushed down to the Remotes during IKE Mode/Client Config. The vpngroup group_name command is used to assign policies to a group. The group name should be descriptive of the group, like "marketing" or "sales," and should contain no more than 63 characters.

Tip

The group names are case-sensitive and must be configured the same way on the Remotes; otherwise, authentication will fail!

Here are the commands you can use to create a group:

pix(config)# vpngroup group_name password preshared_key
pix(config)# vpngroup group_name address-pool pool_name
pix(config)# vpngroup group_name authentication-server AAA_tag
pix(config)# vpngroup group_name backup-server {{IP_1 [IP2...IP10]} |
 clear-client-cfg}
pix(config)# vpngroup group_name default-domain domain_name
pix(config)# vpngroup group_name dns-server DNS_IP_1 [DNS_IP_2]
pix(config)# vpngroup group_name split-dns domain_name1
 [domain_name2 ... domain_8]
pix(config)# vpngroup group_name wins-server WINS_IP_1 [WINS_IP_2]
pix(config)# vpngroup group_name pfs
pix(config)# vpngroup group_name split-tunnel access_list_name
pix(config)# vpngroup group_name idle-time idle_seconds
pix(config)# vpngroup group_name max-time max_seconds
pix(config)# vpngroup group_name secure-unit-authentication
pix(config)# vpngroup group_name user-authentication
pix(config)# vpngroup group_name device-pass-through
pix(config)# vpngroup group_name user-idle-timeout hh:mm:ss
pix(config)# show vpngroup [group_name]

The password parameter specifies a pre-shared key to use for device authentication during ISAKMP/IKE Phase 1. The key can be up to 127 characters in length and is case-sensitive. When using pre-shared keys, aggressive mode is used. In FOS 6.3 and later, if you omit the pre-shared key, certificates and main mode are used instead. In this case, the OU (Organizational Unit)/Department field is used as the group name.

Note

The isakmp key address and vpngroup password commands both specify a pre-shared key to use for device authentication during ISAMP/IKE Phase 1. Cisco recommends that you use the vpngroup password command for Remote authentication if you will have more than one remote access group on your PIX. If you have only one group, you could just as easily use the isakmp key address command instead.

The address-pool parameter assigns an address pool (configured with the ip local pool command) to the associated group. You can assign only one address pool per group.

The authentication-server parameter specifies which AAA group tag to use to perform XAUTH. This parameter is new in 6.3. It allows you to use a different AAA designation for each group configured on the PIX; if all your groups use the same AAA designation, this command isn't necessary. But, for example, if you had two groups, marketing and sales, you could define the marketing accounts (usernames) on the PIX (in 6.3 and later) and the sales accounts on a Cisco Secure ACS AAA server.

The backup-server parameter allows you to assign up to ten backup Easy VPN Servers to the Remote for redundancy. This parameter is new in 6.3. The clear-client-cfg parameter allows you to erase any configured backup servers on the Remote device.

The default-domain parameter assigns a domain name to the Remotes authenticating to the group. The dns-server parameter allows you to assign up to two DNS servers to the group. The split-dns parameter, new in 6.3, allows the Remotes to use the DNS servers in the dns-server parameter for the domain names listed (up to eight) in the split-dns command; otherwise, the Remote's locally configured DNS servers are used to resolve names. The wins-server parameter allows you to assign up to two WINS server addresses to the Remote, overriding any locally configured WINS server addresses.

The pfs parameter, new in 6.3, allows Remote devices to use PFS to exchange the keying information (via DH) instead of using the protected management connection. Before enabling this, be sure all Remotes in the group support this feature.

The split-tunnel parameter specifies an ACL that defines which traffic is to be protected (permit statements in the ACL) and which traffic doesn't need to be protected (deny or the implicit deny statements in the ACL).

Note

If you don't configure split tunneling, all Remote traffic must be sent to the PIX in a protected fashion. In 6.x and earlier, that means the Remote won't be able to access the Internet because all traffic must be sent to the PIX and the PIX can't send the Internet traffic back out the same interface. In 7.0, this has been rectified; therefore, in 6.3 and earlier, it is very common to use split tunneling on the PIX when it is an Easy VPN Server.

Caution

If you allow Remotes to use split tunneling, be sure they have some kind of firewall feature configured to protect themselves from nontunneled traffic.

The idle-time parameter specifies the number of seconds to wait before terminating an idle Remote session. The default is 1,800 seconds (30 minutes), but you can specify a value from 6086,400 seconds. The max-time parameter specifies the maximum number of seconds a Remote is allowed to have a session up. The default is infinite, but you can restrict this by specifying a value from 6031,536,000 seconds. The timers specified in these commands take precedence over the timers configured with the isakmp policy lifetime command for the management connection and the crypto map set security-association lifetime seconds or crypto ipsec security-association lifetime seconds commands for the data connections.

The commands from here on out in the above code section apply only to Remote hardware clients and are new in FOS 6.3. The secure-unit-authentication (SUA) parameter enables what the VPN 3000 concentrators refer to as interactive unit authentication (Interactive UA); the password for the XAUTH user account is not saved on the hardware client (Remote). Instead, a user behind the Remote must supply this to bring up the tunnel. Once the tunnel is up, all users behind the Remote can use the tunnel. Note that the SUA feature is configured on the Server, not the Remote.

The user-authentication parameter enables individual user authentication for users behind the Remote (hardware client). The first user must supply XAUTH credentials to bring up the tunnel and each user that wants to use the tunnel also must authenticate. When either SUA or individual user authentication are configured and pushed down to the Remote during IKE Mode Config, any XAUTH password that has been hard-configured on the Remote is erased.

One problem with individual user authentication is that certain types of devices, such as IP Phones, can't perform HTML-based XAUTH authentication, which would prevent them from using the tunnel. The device-pass-through parameter exempts devices that can't perform authentication themselves; however, the actual list of exempted clients must be configured on the Remote, assuming it's a PIX, with the vpnclient mac-exempt command. The user-idle-timeout parameter is used when individual user authentication is enabled. It specifies when the tunnel is brought down when there is no user activity.

Last in the previous list of commands, the show vpngroup command displays the vpngroup commands you've configured on your PIX. You can restrict the output to just one group by specifying the name of that group.

XAUTH User Authentication Configuration for 6.x

The user accounts used for XAUTH (user authentication) can be defined locally on the PIX or on an AAA server that supports either TACACS+ or RADIUS. If you want to use local authentication and are going to create the user accounts on the PIX for XAUTH, you'll first need to make sure you are running FOS 6.3, and then you'll use the following configuration:

pix(config)# aaa-server LOCAL protocol local
pix(config)# username name password password
pix(config)# crypto map static_map_name client authentication LOCAL

The aaa-server LOCAL command is not necessary because it is pre-configured on a 6.3 PIX: this command specifies that the user accounts specified by the local username commands will be used. Any passwords configured with the username command are automatically encrypted by the PIX. The show username command displays all of the username commands configured on the PIX. The crypto map client authentication command specifies the static crypto map for which XAUTH user authentication will be enabled; this crypto map contains a reference to the dynamic crypto map for the remote access users. The LOCAL parameter at the end of the command points to the aaa-server command to use for XAUTH.

Note that if you don't have any user accounts created when executing the crypto map client authentication command, you'll see this message on the PIX: "Warning: local database is empty! Use 'username' command to define local users." If you already have user accounts defined when executing the command, but then subsequently delete them, you'll see this message on the PIX: "Warning: Local user database is empty and there are still commands using LOCAL for authentication."

If you are running 6.2, you can't use local authentication on the Server, but must define the user accounts on an AAA server that supports either TACACS+ or RADIUS as a communications protocol. In this case, you would use the following PIX commands:

pix(config)# aaa-server group_tag protocol {radius| tacacs+}
pix(config)# aaa-server group_tag (if_name)
 host AAA_server_IP encryption_key
pix(config)# crypto map static_map_name client [token]
 authentication group_tag

The preceding commands will work with both 6.2 and 6.3. The first aaa-server command specifies the protocol the PIX should use when communicating with the AAA server: either TACACS+ or RADIUS. The group_tag parameter in the AAA configuration is used to group related AAA commands together. The second aaa-server command specifies the interface the AAA server resides off of (you must give the logical interface name, like "inside"), the IP address of the AAA server, and the encryption key used either to encrypt the AAA payload for TACACS+ communications or any password information for RADIUS communications. The encryption key must match the key used on the AAA server for communications to the local PIX. The crypto map client authentication command then activates XAUTH authentication for the static crypto map. Optionally, the token parameter specifies that a token card server associated with the AAA server will be used to handle the authentication.

IKE Mode Config Activation for 6.x

To enable IKE Mode Config on your PIX so that you can apply group policies to IPsec remote access devices, use the following command:

pix(config)# crypto map static_ map_name client
 configuration{initiate| respond}

The respond parameter is used most commonly, where the remote access client will initiate the IKE Mode Config process; this is necessary for Cisco client devices. For the old 2.5 Cisco software client or non-Cisco IPsec clients (Microsoft's L2TP client), use the initiate parameter, which causes the Server PIX to initiate IKE Mode Config. If you have both types of clients, configure the command twice, using each parameter separately.

Note

You still have to create an ISAKMP/IKE Phase 1 policy, configure a transform set supported by the remote access devices, associate the transform set with a dynamic crypto map entry, possibly enable RRI, create a static crypto map entry that references the dynamic crypto map, and then enable the static crypto map; however, I discussed these commands in Chapter 21.

 

Easy VPN Server Example for 6.x

Now that you have a basic understanding of the extra commands required to configure a 6.2 or 6.3 PIX as an Easy VPN Server, I'll look at an example to illustrate the use of these commands, using the network shown in Figure 22-1. In this situation, only a small number of remote access users need to set up IPsec sessions, so I'll use pre-shared keys for device authentication; however, since an AAA server is already in the network, I'll use the user accounts defined there instead of replicating this information locally on the PIX.

Figure 22-1. 6.x PIX Easy VPN Server Example

Example 22-1 illustrates the PIX Server configuration, where I'll assume the PIX is running FOS 6.3. There are two basic requirements in this example: split tunneling is required because the remote access users need access to both the LAN segment behind the PIX and the Internet, and split-DNS should be used. Remote access users will be assigned an internal address from 192.168.0.240192.168.0.254. The reference numbers to the right of various command sections are explained below Example 22-1.

Example 22-1. 6.3 PIX Easy VPN Server Configuration

server(config)# isakmp enable outside (1)
server(config)# isakmp policy 10 encryption aes
server(config)# isakmp policy 10 hash sha
server(config)# isakmp policy 10 group 5
server(config)# isakmp policy 10 authentication pre-share
server(config)# access-list NONATREMOTE permit ip (2)
 192.168.0.0 255.255.255.0
 192.168.0.0 255.255.255.0
server(config)# nat (inside) 0 access-list NONATREMOTE
server(config)# crypto ipsec transform-set mytrans (3)
 esp-aes esp-sha-hmac
server(config)# crypto dynamic-map dynmap 10 (4)
 set transform-set mytrans
server(config)# crypto map statmap 999 ipsec-isakmp
 dynamic dynmap
server(config)# crypto map statmap interface outside
server(config)# sysopt connection permit-ipsec
server(config)# aaa-server AAASERVER protocol radius (5)
server(config)# aaa-server AAASERVER (inside) host 192.168.0.2
 cisco123
server(config)# crypto map statmap client authentication AAASERVER
server(config)# crypto map statmap client configuration (6)
 address respond
server(config)# ip local pool remotepool
 192.168.0.240-192.168.0.254
server(config)# access-list splittunnelACL permit ip (7)
 192.168.0.0 255.255.255.0
 192.168.0.0 255.255.255.0
server(config)# vpngroup smallgroup address-pool remotepool (8)
server(config)# vpngroup smallgroup password 123cisco
server(config)# vpngroup smallgroup dns-server 192.168.0.10
server(config)# vpngroup smallgroup default-domain cisco.com
server(config)# vpngroup smallgroup split-dns cisco.com
server(config)# vpngroup smallgroup wins-server 192.168.0.11
server(config)# vpngroup smallgroup split-tunnel splittunnelACL
server(config)# vpngroup idle-time 600

Here is an explanation of the sections found in Example 22-1:

1.	ISAKMP is enabled on the outside interface and an ISAKMP policy is created for the remote access users. For the 2.5 Cisco client, only DH group 1 is supported. If you also terminated L2L sessions on this PIX and were using pre-shared keys, when configuring the pre-shared key for each L2L peer, you would use the no-xauth and no-config-mode parameters to disable XAUTH and IKE Mode Config, respectively, for the L2L peers.
2.	The access-list and nat commands disable address translation between the local LAN (source addresses in the ACL) and the remote access user's internal addresses (destination addresses in the ACL).
3.	A supported transform set for the remote access users is defined.
4.	A dynamic crypto map entry is created for the remote access users, specifying the transform set to use to protect the users' data SAs. This is then referenced in the static crypto map applied to the Server's outside interface; remember that if you have both L2L and remote access sessions terminated on the Server, use a high-sequence number for the dynamic crypto map entry in the static map, giving it a lower priority than the static map entries for L2L peers. The sysopt command then exempts the IPsec traffic by being processed by any ACL applied to the PIX's outside interface.
5.	An AAA server, which contains the user accounts, is identified and XAUTH is associated with the static crypto map and the AAA server; notice that the AAA protocol used between the PIX and the AAA server is RADIUS.
6.	IKE Mode Config is enabled on the Server, with the assumption that this is a Cisco client; for non-Cisco clients or the 2.5 Cisco client, you would use the initiate parameter instead of the respond parameter. Also, an address pool containing the remote access users' internal addresses is defined with the ip local pool command.
7.	An ACL is defined to allow for split tunneling. All traffic between 192.168.0.0/24 devices will be protected from the remote access clients to the local LAN segment and all other traffic from the remote access clients is sent in clear text. The first 192.168.0.0/24 reference, the source addresses, is for the local LAN traffic (the inside interface of the Server) and the second 192.168.0.0/24 reference, the destination addresses, is for the internal addresses of the Remotes.
8.	One group, called "smallgroup," is created. This group specifies the address pool to use ("remotepool"), the pre-shared key to use for device authentication ("123cisco"; if you were using certificates, this command would be omitted), the DNS servers, domain name, and split DNS, the WINS server, the split tunneling ACL to use ("splittunnelACL"), and an idle timeout (600 seconds).

As you can see from this example, the configuration in 6.3 is somewhat similar to configuring an Easy VPN Server on an IOS router. The only thing you might want to do is ensure that the Remotes have a personal firewall installed because split tunneling is enabled; unfortunately, you can't enforce that kind of group policy on the PIX/ASA until Version 7.0.