|
|
This chapter provides information about how to configure optional IPSec-related features, such as dynamic IP address assignment for VPN clients.
This chapter includes the following sections:
Private Link is no longer supported in the PIX Firewall starting with version 5.0. It is supported in version 4. The Private Link feature allows Virtual Private Networks (VPNs) to be established between PIX Firewall is connected to the same public (or outside) network. It enables incoming Private Link packets to bypass the NAT and ASA features and terminate on the corresponding sending interface on the destination network. A sending interface is the interface from which the IPSec packet was sent from. For example, IPSec packets sent from a perimeter interface from one network would be terminated at the equivalent perimeter interface at the destination network. With the use of the sysopt ipsec pl-compatible command, the IPSec feature simulates the Private Link feature by allowing IPSec packets to also bypass the NAT and ASA features and terminate on the sending interface. See the sysopt command page for more information regarding the sysopt ipsec pl-compatible command.
This section contains the following topics:
While IPSec is a much larger feature set than Private Link, the two feature sets do not have a complete parent-child inheritance relationship. The main difference between Private Link and IPSec is that a Private Link tunnel begins on the receiving interface and ends on the sending interface while an IPSec tunnel begins on the sending interface and terminates on the receiving interface.
This section contains the following topics:
Table 8-1 outlines the mapping of the core Private Link commands with the corresponding IPSec commands. A description of each command follows.
| Private Link Commands | IPSec Commands |
|---|---|
- | sysopt ipsec pl-compatible |
link (inside) remote_peer_ip key_id key
| 1. isakmp policy priority authentication pre-share 2. isakmp key keystring address peer-address 3. crypto map map-name interface interface-name |
link remote_peer_ip md5 | 1. crypto ipsec transform-set transform-set-name esp-des ah-md5-hmac 2. crypto map map-name seq-num set transform-set transform-set-name |
linkpath remote_network_ip remote_netmask remote_peer_ip | 1. access-list access-list-name permit ip any remote_network_ip remote_netmask 2. crypto map map-name seq-num match address access-list-name 3. crypto map map-name seq-num set peer ip-address |
age minutes | crypto ipsec security-association lifetime seconds seconds |
For more information about the IPSec-related commands listed in Table 8-1, see the access-list command page within the "Command Reference" chapter of the Configuration Guide for the Cisco Secure PIX Firewall Version 6.0 and the following command pages in "Command Reference":
 |
Note Private Link uses up to seven shared keys between two hosts and rotates among the seven keys. ISAKMP uses only one shared key between any two hosts to authenticate and dynamically negotiate other keys to protect the communication as necessary. |
The link command allows for the configuration of per packet authentication protection. In IPSec, the analogous protection is provided by the transform-set combination of ah-md5-hmac or esp-md5-hmac. You configure a transform set using the crypto ipsec transform-set command.
In IPSec, the access-list command statement address selectors in the crypto map are used to select outbound traffic from the interface to encrypt and tunnel to the remote peer. In the reverse direction, the access-list command statement address selectors are used to decrypt inbound traffic, which originated from the remote peer, at the outside interface.
Use the following steps to convert from a linkpath tunnel into an IPSec tunnel. These steps are included within the "Private Link to IPSec Conversion" section.
Step 2 Associate the defined access-list command statement with a crypto map entry. (Step 7 in the "Private Link to IPSec Conversion" section.)
Step 3 Associate the linkpath remote peer as the crypto map peer. (Step 10 in the "Private Link to IPSec Conversion" section.)
In IPSec, the crypto ipsec security-association lifetime second command is used to define how long the current shared key and the security association are used before their set time expires.
This section provides the steps to convert your Private Link configuration into an IPSec configuration. An example of a Private Link configuration between two PIX Firewall units is provided for reference.
Figure 8-1 shows the Private Link network diagram example to which to refer in this section.
The Private Link network diagram shown in Figure 8-1 corresponds to the following configurations.
On PIX Firewall A, the Private Link configuration is:
link 192.168.37.1 1 fadebacfadebac link 192.168.37.1 2 bacfadefadebac link 192.168.37.1 3 baabaaafadebac link 192.168.37.1 4 beebeeefadebac linkpath 10.3.0.0 255.255.255.0 192.168.37.1
On PIX Firewall B, the Private Link configuration is:
link 192.168.35.1 1 fadebacfadebac link 192.168.35.1 2 bacfadefadebac link 192.168.35.1 3 baabaaafadebac link 192.168.35.1 4 beebeeefadebac linkpath 10.1.0.0 255.255.255.0 192.168.35.1
In this configuration, the link command specifies 192.168.35.1 as the external network interface IP address of PIX Firewall B, and 192.168.37.1 as the external network interface IP address of PIX Firewall A. The key IDs are 1 through 4. The four keys to be shared between the two PIX Firewall units are fadebacfadebac, bacfadefadebac, baabaaafadebac, and beebeeefadebac.
The linkpath command identifies the internal and external network interfaces belonging to the remote peer. So on the PIX Firewall A, PIX Firewall B's internal network interface IP address of 10.3.0.0 with a netmask of 255.255.255.0 and its external network interface IP address of 192.168.37.1 is set. On PIX Firewall B, PIX Firewall A's internal network interface IP address of 10.1.0.0 with a netmask of 255.255.255.0 and its external network interface IP address of 192.168.35.1 is set.
Follow these steps to convert your Private Link configuration into an IPSec configuration where IKE is used to establish security associations. Perform your configuration on each PIX Firewall:
PIX Firewall A:
sysopt ipsec pl-compatible
PIX Firewall B:
sysopt ipsec pl-compatible
Step 2 Specify that a pre-shared key will be used between PIX Firewall A and PIX Firewall B for authentication:
PIX Firewall A:
isakmp policy 10 authentication pre-share
PIX Firewall B:
isakmp policy 10 authentication pre-share
Step 3 Specify a pre-shared key that PIX Firewall A and PIX Firewall B will share. For example:
PIX Firewall A:
isakmp key fadebacfadebac address 192.168.37.1
PIX Firewall B:
isakmp key fadebacfadebac address 192.168.35.1
Step 4 Define a crypto map entry that uses IKE to establish security associations. For example:
PIX Firewall A:
crypto map Firewall-A 10 ipsec-isakmp
PIX Firewall B:
crypto map Firewall-B 10 ipsec-isakmp
Step 5 Apply the crypto map set to the interface through which IPSec traffic will flow. For example:
PIX Firewall A:
crypto map Firewall-A interface outside
PIX Firewall B:
crypto map Firewall-B interface outside
Step 6 Create an access list to define the traffic to protect. Use the same address selectors used in your linkpath statement. For example:
PIX Firewall A:
access-list linkpath-aclA permit ip any 10.3.0.0 255.255.255.0
PIX Firewall B:
access-list linkpath-aclB permit ip any 10.1.0.0 255.255.255.0
Step 7 Assign the access list to the crypto map entry you defined. For example:
PIX Firewall A:
crypto map Firewall-A 10 match address linkpath-aclA
PIX Firewall B:
crypto map Firewall-B 10 match address linkpath-aclB
Step 8 Configure the transform set that defines how the traffic will be protected. Use either esp-des ah-md5-hmac or esp-md5-hmac. Either one provides the analogous Private Link standard encryption and authentication protection. For example:
PIX Firewall A:
crypto ipsec transform-set private-link-base esp-des ah-md5-hmac
PIX Firewall B:
crypto ipsec transform-set private-link-base esp-des ah-md5-hmac
Step 9 Specify the transform set to be used with the crypto map entry. For example:
PIX Firewall A:
crypto map Firewall-A 10 set transform-set private-link-base
PIX Firewall B:
crypto map Firewall-B 10 set transform-set private-link-base
Step 10 Specify the remote peer to which the IPSec protected traffic can be forwarded. Specify the remote peer specified in your linkpath statement. For example:
PIX Firewall A:
crypto map Firewall-A 10 set peer 192.168.37.1
PIX Firewall B:
crypto map Firewall-B 10 set peer 192.168.35.1
Step 11 Apply the crypto map set to an interface through which IPSec traffic will flow.
For example:
PIX Firewall A:
crypto map Firewall-A interface outside
PIX Firewall B:
crypto map Firewall-B interface outside
|
Note Although PIX Firewall version 6.0 supports the following VPN clients, we strongly suggest that you use the Cisco VPN Client version 3.0. |
Refer to the telnet command page within the "Command Reference" chapter of the Configuration Guide for the Cisco Secure PIX Firewall Version 6.0, for more information about this command.
This section applies only if you are using a Cisco Secure VPN Client. To encrypt your Telnet connection to the PIX Firewall's outside interface, perform the following steps as part of your PIX Firewall configuration. In the following examples, the IP address of the PIX Firewall's outside interface is 168.20.1.5, and the Cisco Secure VPN Client's IP address stemming from the virtual pool of addresses is 10.1.2.0.
access-list 80 permit ip host 168.20.1.5 10.1.2.0 255.255.255.0
Step 2 Specify which host can access the PIX Firewall console with Telnet. Specify the VPN client's address from the local pool and the outside interface:
telnet 10.1.2.0 255.255.255.0 outside
Step 3 Within the VPN client, create a security policy that specifies the Remote Party Identity IP address and gateway IP address as the same IP address—the IP address of the PIX Firewall's outside interface. In this example, the IP address of the PIX Firewall's outside is 168.20.1.5.
Step 4 Configure the rest of the security policy on the VPN client to match the PIX Firewall's security policy.
|
Note You will need to have two security policies set up on your Cisco Secure VPN Client. One security policy is used to secure your Telnet connection and another to secure your connection to the inside network. |
This section applies only if you are using a Cisco VPN 3000 Client. To encrypt your Telnet connection to the PIX Firewall's outside interface, perform the following step as part of your PIX Firewall configuration. In the following example, the IP address of the PIX Firewall's outside interface is 168.20.1.5, and the Cisco VPN 3000 Client's IP address stemming from the virtual pool of addresses is 10.1.2.0.
Specify which host can access the PIX Firewall console with Telnet. Specify the VPN client's address from the local pool and the outside interface:
telnet 10.1.2.0 255.255.255.0 outside
The PIX Firewall supports the Extended Authentication (Xauth) feature within the IKE protocol. Xauth lets you deploy IPSec VPNs using TACACS+ or RADIUS as your user authentication method. This feature, which is designed for VPN clients, provides a user authentication by prompting the user for username and password and verifies them with the information stored in your TACACS+ or RADIUS database. Xauth is negotiated between IKE Phase 1 (IKE device authentication phase) and IKE
Phase 2 (IPSec SA negotiation phase). If the Xauth fails, the IPSec security association will not be established and the IKE security association will be deleted.
|
Note The IKE Mode Config feature also is negotiated between these IKE Phase 1 and 2. If both features are configured, Xauth is performed first. |
The Xauth feature is optional and is enabled using the crypto map map-name client authentication aaa-group-tag command. AAA must be configured on the PIX Firewall using the aaa-server group_tag (if_name) host server_ip key timeout seconds command before Xauth is enabled. Use the same AAA server name within the aaa-server and crypto map client authentication command statements. See the aaa-server command page within the "Command Reference" chapter of the Configuration Guide for the Cisco Secure PIX Firewall Version 6.0 and the crypto map command page within the "Command Reference" chapter for more information about these commands.
|
Note The VPN client remote user must be running the Cisco Secure VPN Client, version 1.1 or Cisco VPN 3000 Client, version 2.5 or later. |
If you have both security gateway and VPN client peers terminating on the same interface, and have the Xauth feature configured, configure the PIX Firewall to make an exception to this feature for the security gateway peer. With this exception, the PIX Firewall will not challenge the security gateway peer for a username and password. The command that you employ to make an exception to the Xauth feature depends on the authentication method you are using within your IKE policies. See Table 8-2 for the guidelines to follow.
| IKE authentication method | no-xauth Related Command to Use |
|---|---|
pre-shared key | isakmp key keystring address ip-address [netmask] [no-xauth] [no-config-mode] See isakmp command page within the "Command Reference" chapter for more information. See Step 3 within the section "Configuring Extended Authentication" in this chapter for the no-xauth configuration step. |
rsa signatures | isakmp peer fqdn fqdn [no-xauth] [no-config-mode] See isakmp command page within the "Command Reference" chapter for more information. See Step 4 within the section "Configuring Extended Authentication" in this chapter for the no-xauth configuration step. |
Follow these steps to configure Xauth on your PIX Firewall:
aaa-server group_tag (if_name) host server_ip key
For example:
aaa-server TACACS+ (outside) host 10.0.0.2 secret123
This example specifies that the authentication server with the IP address 10.0.0.2 resides on the outside interface and is in the default TACACS+ server group. The key "secret123" is used between the PIX Firewall and the TACACS+ server for encrypting data between them.
Step 2 Enable Xauth. Be sure to specify the same AAA server group tag within the crypto map client authentication command statement as was specified in the aaa-server command statement.
crypto map map-name client authentication aaa-group-tag
For example:
crypto map mymap client authentication TACACS+
In this example, Xauth is enabled at the crypto map "mymap" and the server specified in the TACACS+ group will be used for user authentication.
Step 3 (Optional) Perform this step for each security gateway that shares the same interface as the VPN client(s) and is configured to use a pre-shared key. This steps allows the PIX Firewall to make an exception to the Xauth feature for the given security gateway.
isakmp key keystring address ip-address[netmaskmask] [no-xauth] [no-config-mode]
For example:
isakmp key secretkey1234 address 10.2.2.2 netmask 255.255.255.255 no-xauth
Step 4 (Optional) Perform this step for each security gateway that shares the same interface as the VPN client(s) and is configured to use RSA-signatures. This step allows the PIX Firewall to make an exception to the Xauth feature for the given security gateway.
isakmp peer fqdn fqdn[no-xauth] [no-config-mode]For example: isakmp peer fqdn hostname1.example.com no-xauth
The IKE Mode Configuration (Config) feature allows a security gateway (in this case a PIX Firewall) to download an IP address (and other network level configuration) to a VPN client peer as part of an IKE negotiation. Using this exchange, the PIX Firewall gives an IP address to the VPN client to be used as an "inner" IP address encapsulated under IPSec. This provides a known IP address for a VPN client, which can be matched against the IPSec policy.
The following topics are covered in this section to provide background information you will need to know prior to configuring IKE Mode Config. The steps for configuring the IKE Mode Config are provided in the section "Configuring IKE Mode Config."
|
Note If you use IKE Mode Config on the PIX Firewall, the routers handling the IPSec traffic must also support IKE Mode Config. The Cisco IOS Release 12.0(6)T and later, supports the IKE Mode Config. |
To implement IPSec VPNs between remote access VPN clients with dynamic (or virtual) IP addresses and a corporate gateway, you have to dynamically administer scalable IPSec policy on the gateway once each client is authenticated. With IKE Mode Config, the gateway can set up scalable policy for a very large set of clients irrespective of the IP addresses of those clients.
There are two types of IKE Mode Config for a VPN:
The following is a summary of the major steps to perform when configuring IKE Mode Config on your PIX Firewall. See the "Configuring IKE Mode Config" section for the complete configuration steps.
If you have both a security gateway and VPN client peers terminating on the same interface, and have the IKE Mode Config feature configured, configure the PIX Firewall to make an exception to this feature for the security gateway peer. With this exception, the PIX Firewall will not attempt to download an IP address to the peer for dynamic IP address assignment. The command that you employ to bypass the IKE Mode Config feature depends on the authentication method you are using within your IKE policies. See Table 8-3 for the guidelines to follow.
| IKE authentication method | no-config-mode Related Command to Use |
|---|---|
pre-shared key | isakmp key keystring address ip-address [netmask] [no-xauth] [no-config-mode] See the isakmp command page within "Command Reference," for more information. See Step 4 within the section "Configuring Extended Authentication" in this chapter for the no-config-mode configuration step. |
rsa signatures | isakmp peer fqdn fqdn [no-xauth] [no-config-mode] See the isakmp command page within "Command Reference," for more information. See Step 5 within the section "Configuring Extended Authentication" in this chapter for the no-config-mode configuration step. |
To configure IKE Mode Config on your PIX Firewall, perform the following steps:
ip local pool pool-name start-address-[end-address]
For example:
ip local pool ire 172.16.1.1-172.16.1.254
Step 2 Reference the defined pool of IP addresses in the IKE configuration:
isakmp client configuration address-pool local pool-name[interface-name]
For example:
isakmp client configuration address-pool local csvc outside
Step 3 Define which crypto maps should attempt to configure clients:
crypto map map-name client configuration address initiate | respond
For example:
crypto map mymap client configuration address initiate
Step 4 (Optional) Perform this step for each security gateway that shares the same interface as the VPN client(s) and is configured to use a pre-shared key. This step allows the PIX Firewall to make an exception to the IKE Mode Config feature for the given security gateway.
isakmp key keystring address ip-address[no-xauth] [no-config-mode]
For example:
isakmp key secretkey1234 address 10.2.2.2 255.255.255.255 no-config-mode
Step 5 (Optional) Perform this step for each security gateway that shares the same interface as the VPN client(s) and is configured to use RSA-signatures. This step allows the PIX Firewall to make an exception to the IKE Mode Config feature for the given security gateway.
isakmp peer fqdn fqdn[no-xauth] [no-config-mode]
For example:
isakmp peer fqdn hostname1.example.com no-config-mode
Examples
The following partial configuration shows a PIX Firewall that has been configured to both set IP addresses to clients and to respond to IP address requests from clients whose packets arrive on the outside interface using dynamic crypto map without explicitly specifying the peer. The IKE Mode Config-related commands are in bold.
: define the ip address poolip local pool csvc 172.16.1.1-172.16.1.254: reference the defined pool of IP addresses in ikecrypto isakmp client configuration address-pool local ire outside:access-list 103 permit ip host 172.21.230.34 172.21.1.0 255.255.255.0:crypto ipsec transform-set pc esp-des esp-md5-hmac:crypto dynamic-map dyn 10 set transform-set pccrypto dynamic-map dyn 10 match address 103: enable address assignment in crypto mapcrypto map dyn client configuration address initiate crypto map dyn client configuration address respond:crypto map dyn 10 ipsec-isakmp dynamic dyncrypto map dyn interface outside
This section provides background information you will need to know prior to configuring L2TP with IPSec. The steps for configuring L2TP with IPSec are provided in the following section, "Configuring L2TP with IPSec in Transport Mode." Refer to the "Configuring Interoperability with a Windows 2000 L2TP Client" section in "VPN Client Configuration Examples," for detailed information about configuring the PIX Firewall to interoperate with the Windows 2000 client.
Windows 2000 uses IPSec transport mode when tunneling L2TP data. Transport mode must be configured on the PIX Firewall to receive the L2TP IPSec transport mode data from a Windows 2000 client.
|
Note L2TP requires the client to have Microsoft DUN configured. L2TP is solely supported by Windows 2000 MS-DUN (L2TP is not supported by Windows 95, Windows 98, or Windows NT). L2TP clients from other vendors are supported as well. |
Layer 2 Tunneling Protocol (L2TP) is a VPN tunneling protocol which allows remote clients to use the public IP network to securely communicate with private corporate network servers. L2TP uses PPP over UDP (port 1701) to tunnel the data. L2TP protocol is based on the client/server model. The function is divided between the L2TP Network Server (LNS), and the L2TP Access Concentrator (LAC). The LNS typically runs on a network gateway such as a router, while the LAC can be a dail-up Network Access Server (NAS), or a PC with a bundled L2TP client such as Microsoft Windows 2000.
PIX Firewall version 6.0 with L2TP/IPSec support provides the capability to deploy and administer an L2TP VPN solution alongside the IPSec VPN and PIX Firewall services in a single platform.
|
Note Only L2TP with IPSec is supported, native L2TP itself is not supported on PIX Firewall. |
|
Note The purpose of introducing L2TP with IPSec in PIX Firewall version 6.0 is to attain the function of L2TP LNS to terminate on the Windows 2000 L2TP client. Interoperatibility with LACs from Cisco and other vendors will not be supported in PIX Firewall version 6.0. |
The primary benefit of configuring L2TP with IPSec in a remote access scenario is that remote users can access a VPN over a public IP network without a gateway or a dedicated line, enabling remote access from virtually anyplace with POTS. An additional benefit is that the only client requirement for VPN access is the use of Windows 2000 with Microsoft Dial-Up Networking (DUN). No additional client software, such as Cisco VPN Client software, is required.
The following is a summary of the major steps to perform when configuring L2TP with IPSec on your PIX firewall. See the "Configuring L2TP with IPSec in Transport Mode" section for the complete configuration steps for each task.
|
Note The configuration of L2TP with IPSec supports certificates using the pre-shared keys or RSA signature methods, and the use of dynamic (as opposed to static) crypto maps. This summary of tasks assumes completion of IKE, as well as pre-shared keys or RSA signature configuration. Refer to the "Configuring Interoperability with a Windows 2000 Client" section in "VPN Client Configuration Examples," for the steps to configure pre-shared keys, RSA, and dynamic crypto maps. |
| Command | Purpose | |
|---|---|---|
Step 1 | crypto ipsec transform-set trans_name 1 | Specify IPSec to use transport mode rather than tunnel mode. |
Step 2 | sysopt connection permit-ipsec | Steps 2 and 3 together allow L2TP traffic to bypass conduit/access-list checking. |
Step 3 | sysopt connection permit-l2tp | See Step 2. |
Step 4 | vpdn group group_name accept dial-in l2tp | Instruct the PIX Firewall to accept L2TP dial-in requests. |
Step 5 | vpdn group group_name ppp authentication pap/chap/mschap | Specify PPP protocol and authentication protocol (PAP or CHAP or MS-CHAP). |
Step 6 | vpdn group group_name client configuration address local address_pool_name2 | Specify the local address pool used to allocate the IP address to the client. |
Step 7 | (Optional) vpdn group group_name client configuration dns dns_server_ip1 dns_server_ ip2 | Instruct the PIX Firewall to send DNS server IP addresses to the client. |
Step 8 | (Optional) vpdn group group_name client configuration wins wins_server_ip1 wins_server_ip2 | Instruct the PIX Firewall to send WINS server IP addresses to the client. |
Step 9 | vpdn group group_name client authentication aaa aaa_server_tag or vpdn group group_name client authentication local | Specify authentication using the PIX Firewall local username/password database.3 If set to aaa, authenticate using the aaa server. |
Step 10 | (Optional) vpdn group group_name client accounting aaa_server_tag | Generate an aaa accounting start and stop record for an L2TP (and PPTP) session. |
Step 11 | vpdn username username password password | If local authentication is used, this command specifies username/password entries. |
Step 12 | (Optional) vpdn group_name l2tp tunnel hello hello timeout | Specify the L2TP keep-alive/hello timeout value. The default timeout value is 60, and the lower and upper limits are 10 and 300, respectively. |
Step 13 | vpdn enable ifname | Enable vpdn function on a PIX Firewall interface. |
| 1If set to local. 2Use IP local pool command to create the pool. 3If set to local. |
Posted: Mon Jun 10 16:36:10 PDT 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.