|
|
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 sites 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 "Command Reference" chapter of the Configuration Guide for the Cisco Secure PIX Firewall Version 5.2 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.
The following are the steps to use to convert from a linkpath tunnel into an IPSec tunnel. These steps are included within the Private Link to IPSec configuration conversion procedure.
Step 2 Associate the defined access-list command statement with a crypto map entry. (Step 7 in the "Conversion" section.)
Step 3 Associate the linkpath remote peer as the crypto map peer. (Step 10 in the "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.
Covered in this section are 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
Refer to the telnet command page within the "Command Reference" chapter of the Configuration Guide for the Cisco Secure PIX Firewall Version 5.2, 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 5.2 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.06(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 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 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-config-mode 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 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
Posted: Thu Aug 31 19:35:10 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.