Firewalls - Configuring IPSec

Configuring IPSec

IPSec tunnels are sets of security associations that are established between two remote IPSec peers. The security associations define which protocols and algorithms should be applied to sensitive packets, and also specify the keying material to be used by the two peers. IPSec SAs are used during the actual transmission of user traffic. SAs are unidirectional and are established separately for different security protocols AH(and/or ESP). IPSec SAs can be established in two ways:

Manual SAs with Pre-Shared Keys —The use of manual IPSec SAs requires a prior agreement between administrators of the firewall and the IPSec peer. There is no negotiation of SAs, so the configuration information in both systems should be the same for traffic to be processed successfully by IPSec.
IKE-Established SAs—When IKE is used to establish IPSec SAs, the peers can negotiate the settings they will use for the new security associations. This means that you can specify lists (such as lists of acceptable transforms) within the crypto map entry.

The firewall can simultaneously support manual and IKE-established security associations.

Transform Sets

A transform set represents a certain combination of security protocols and algorithms. During the IPSec security association negotiation, the peers agree to use a particular transform set for protecting a particular data flow.
You can specify multiple transform sets, and then specify one or more of these transform sets in a crypto map entry. The transform set defined in the crypto map entry will be used in the IPSec security association negotiation to protect the data flows specified by that crypto map entry's access list.
During IPSec security association negotiations with IKE, the peers search for a transform set that is the same at both peers. When such a transform set is found, it is selected and will be applied to the protected traffic as part of both peers' IPSec security associations. With manually established security associations, there is no negotiation with the peer, so both sides have to specify the same transform set.
If you change a transform set definition, the change will not be applied to existing security associations, but will be used in subsequent negotiations to establish new security associations. If you want the new settings to take effect sooner, clear all or part of the security association database by using the clear [crypto] ipsec sa command. See "Clearing SAs" for further information.

Crypto Maps

Crypto maps specify IPSec policy. Crypto map entries created for IPSec pull together the various parts used to set up IPSec security associations, including the following:

Which traffic should be protected by IPSec (per a crypto access list)
Where IPSec-protected traffic should be sent (who the peer is)
The local address to be used for the IPSec traffic (See "Applying Crypto Maps to Interfaces" for more details.)
What IPSec security should be applied to this traffic (selecting from a list of one or more transform sets)
Whether security associations are manually established or are established via IKE
Other parameters that might be necessary to define an IPSec SA

Crypto map entries with the same crypto map name (but different map sequence numbers) are grouped into a crypto map set. Later, you will apply these crypto map sets to interfaces; then, all IP traffic passing through the interface is evaluated against the applied crypto map set. If a crypto map entry sees outbound IP traffic that should be protected and the crypto map specifies the use of IKE, a security association is negotiated with the peer according to the parameters included in the crypto map entry; otherwise, if the crypto map entry specifies the use of manual security associations, a security association should have already been established via configuration. (If a dynamic crypto map entry sees outbound traffic that should be protected and no security association exists, the packet is dropped.)
The policy described in the crypto map entries is used during the negotiation of security associations. If the local firewall initiates the negotiation, it will use the policy specified in the static crypto map entries to create the offer to be sent to the specified peer. If the peer initiates the negotiation, the firewall will check the policy from the static crypto map entries, as well as any referenced dynamic crypto map entries to decide whether to accept or reject the peer's request (offer).
For IPSec to succeed between two peers, both peers' crypto map entries have to contain compatible configuration statements.
When two peers try to establish a security association, they should each have at least one crypto map entry that is compatible with one of the other peer's crypto map entries. For two crypto map entries to be compatible, they should, at a minimum, meet the following criteria:

The crypto map entries contain compatible crypto access lists (for example, mirror image access lists). In the case where the responding peer is using dynamic crypto maps, the entries in the firewall crypto access list have to be "permitted" by the peer's crypto access list.
The crypto map entries each identify the other peer (unless the responding peer is using dynamic crypto maps).
The crypto map entries have at least one transform set in common.

You can apply only one crypto map set to a single interface. The crypto map set can include a combination of IPSec/IKE and IPSec/manual entries.
If you create more than one crypto map entry for a given interface, use the seq-num of each map entry to rank the map entries: the lower the seq-num, the higher the priority. At the interface that has the crypto map set, traffic is evaluated against higher priority map entries first.
Create multiple crypto map entries for a given firewall interface, if any of the following conditions exist:

If different data flows are to be handled by separate peers.
If you want to apply different IPSec security to different types of traffic (to the same or separate peers); for example, if you want traffic between one set of subnets to be authenticated, and traffic between another set of subnets to be both authenticated and encrypted. In this case, the different types of traffic should have been defined in two separate access lists, and you create a separate crypto map entry for each crypto access list.
If you are configuring manual SAs to establish a particular set of IPSec security associations, and want to specify multiple access list entries, create separate access lists (one per permit entry) and specify a separate crypto map entry for each access list.

Applying Crypto Maps to Interfaces

You need to apply a crypto map set to each interface through which IPSec traffic will flow. The firewall supports IPSec on all of its interfaces. Applying the crypto map set to an interface instructs the firewall to evaluate all the interface's traffic against the crypto map set and to use the specified policy during connection or security association negotiation on behalf of traffic to be protected by crypto IPSec.
Binding a crypto map to an interface will also initialize the run-time data structures, such as the security association database and the security policy database. If the crypto map is modified in any significant manner, reapplying the crypto map to the interface will resynchronize the various run-time data structures with the crypto map configuration.

Access Lists

By default, IPSec and all packets that traverse the firewall are subjected to blocking as specified by inbound conduit, outbound list, or interface access-list. To enable IPSec packets to traverse the PIX Firewall, ensure that you have statements in conduits, outbound lists, or interface access-lists that permit the packets. Optionally, the sysopt connection permit-ipsec command can be configured to enable IPSec packets to bypass the conduit, outbound list, and interface access-list blocking.
The sysopt connection permit-ipsec command enables packets that have been processed by IPSec to bypass the conduit, outbound list, and interface access-list checks.
IPSec packets that are destined to an IPSec tunnel are selected by the crypto map access-list bound to the outgoing interface. IPSec packets that arrive from an IPSec tunnel are authenticated/deciphered by IPSec, and are subjected to the proxy identity match of the tunnel.
Crypto access lists are used to define which IP traffic will be protected by crypto and which traffic will not be protected by crypto. For example, access lists can be created to protect all IP traffic between Subnet A and Subnet Y or between Host A and Host B. (These access lists are similar to access lists used with the access-group command. With the access-group command, the access-list determines which traffic to forward or block at an interface.)
The access lists themselves are not specific to IPSec. It is the crypto map entry referencing the specific access list that defines whether IPSec processing is applied to the traffic matching a permit in the access list.
Crypto access lists associated with IPSec crypto map entries have four primary functions:

Select outbound traffic to be protected by IPSec (permit = protect).
Indicate the data flow to be protected by the new security associations (specified by a single permit entry) when initiating negotiations for IPSec security associations.
Process inbound traffic to filter out and discard traffic that should have been protected by IPSec.
Determine whether or not to accept requests for IPSec security associations on behalf of the requested data flows when processing IKE negotiation from the peer. (Negotiation is only done for ipsec-isakmp crypto map entries.) In order for the peer's request to be accepted during negotiation, the peer should specify a data flow that is "permitted" by a crypto access list associated with an ipsec-isakmp crypto map command entry.

If you want certain traffic to receive one combination of IPSec protection (for example, authentication only) and other traffic to receive a different combination of IPSec protection (for example, both authentication and encryption), you need to create two different crypto access lists to define the two different types of traffic. These different access lists are then used in different crypto map entries which specify different IPSec policies.
Using the permit keyword causes all IP traffic that matches the specified conditions to be protected by crypto, using the policy described by the corresponding crypto map entry. Using the deny keyword prevents traffic from being protected by crypto IPSec in the context of that particular crypto map entry. (In other words, it does not allow the policy as specified in this crypto map entry to be applied to this traffic.) If this traffic is denied in all the crypto map entries for that interface, the traffic is not protected by crypto IPSec.
The crypto access list you define will be applied to an interface after you define the corresponding crypto map entry and apply the crypto map set to the interface. Different access lists should be used in different entries of the same crypto map set. However, both inbound and outbound traffic will be evaluated against the same " outbound" IPSec access list.
Therefore, the access list's criteria are applied in the forward direction to traffic exiting the firewall, and the reverse direction to traffic entering the firewall. In Figure 4-1, IPSec protection is applied to traffic between Host 10.0.0.1 and Host 10.2.2.2 as the data exits firewall A's outside interface toward Host 10.2.2.2. For traffic from Host 10.0.0.1 to Host 10.2.2.2, the access list entry on firewall A is evaluated as follows:

source = host 10.0.0.1
dest = host 10.2.2.2

For traffic from Host 10.2.2.2 to Host 10.0.0.1, that same access list entry on firewall A is evaluated as follows:

source = host 10.2.2.2
dest = host 10.0.0.1

If you configure multiple statements for a given crypto access list that is used for IPSec, in general the first permit statement that is matched will be the statement used to determine the scope of the IPSec security association. That is, the IPSec security association will be set up to protect traffic that meets the criteria of the matched statement only. Later, if traffic matches a different permit statement of the crypto access list, a new, separate IPSec security association will be negotiated to protect traffic matching the newly matched access list statement.
Any unprotected inbound traffic that matches a permit entry in the crypto access list for a crypto map entry flagged as IPSec will be dropped because this traffic was expected to be protected by IPSec.
Access lists for crypto map entries tagged as ipsec-manual are restricted to a single permit entry and subsequent entries are ignored. In other words, the security associations established by that particular crypto map entry are only for a single data flow. To support multiple manually established security associations for different kinds of traffic, define multiple crypto access lists, and apply each one to a separate ipsec-manual crypto map command entry. Each access list should include one permit statement defining which traffic to protect.
If you clear or delete the last element from an access list, the crypto map references to the destroyed access list are also removed.
If you modify an access list that is currently referenced by one or more crypto map entries, the run-time security association database will need to be re initialized using the crypto map interface command. See the crypto map command page for more information.
We recommend that for every crypto access list specified for a static crypto map entry that you define at the local peer, you define a "mirror image" crypto access list at the remote peer. This ensures that traffic that has IPSec protection applied locally can be processed correctly at the remote peer. (The crypto map entries themselves should also support common transforms and refer to the other system as a peer.)
When you create crypto access lists, using the any keyword could cause problems. We discourage the use of the any keyword to specify source or destination addresses.
The permit any any statement is strongly discouraged, as this will cause all outbound traffic to be protected (and all protected traffic sent to the peer specified in the corresponding crypto map entry) and will require protection for all inbound traffic. Then, all inbound packets that lack IPSec protection will be silently dropped.
You need to be sure you define which packets to protect. If you use the any keyword in a permit statement, preface that statement with a series of deny statements to filter out any traffic (that would otherwise fall within that permit statement) that you do not want to be protected.

IPSec SA Lifetimes

You can change the global lifetime values that are used when negotiating new IPSec security associations using isakmp and crypto map . These lifetimes only apply to security associations established via IKE. Manually established security associations do not expire.
There are two lifetimes:

Lifetime Default

timed 28,800 seconds (8 hours)

traffic-volume 4,608,000 kilobytes (10 MB/sec for one hour)

If you change a global lifetime, the new lifetime value will not be applied to currently existing security associations, but will be used in the negotiation of subsequently established security assocrations. If you wish to use the new values immediately, you can clear all or part of the security association database.
IPSec security associations use one or more shared secret keys. These keys and their security associations time out together.
Assuming that the particular crypto map entry does not have lifetime values configured, when the firewall requests new security associations it will specify its global lifetime values in the request to the peer; it will use this value as the lifetime of the new security associations. When the firewall receives a negotiation request from the peer, it will use the smaller of either the lifetime value proposed by the peer or the locally configured lifetime value as the lifetime of the new security associations.
The security association (and corresponding keys) will expire according to whichever occurs sooner, either after the seconds time out or after the kilobytes amount of traffic is passed.
A new security association is negotiated before the lifetime threshold of the existing security association is reached to ensure that a new security association is ready for use when the old one expires. The new security association is negotiated either 30 seconds before the seconds lifetime expires or when the volume of traffic through the tunnel reaches 256 kilobytes less than the kilobytes lifetime (whichever occurs first).
If no traffic has passed through the tunnel during the entire life of the security association, a new security association is not negotiated when the lifetime expires. Instead, a new security association will be negotiated only when IPSec sees another packet that should be protected.

Basic IPSec Configuration

In general, to configure the firewall for using IPSec, perform the following steps:

Create an access list to define the traffic to protect:
access-list access-list-name {deny | permit} ip source source-netmask destination destination-netmask

For example:
access-list 101 permit ip 10.0.0.0 255.255.255.0 10.1.1.0 255.255.255.0

In this example, the permit keyword causes all traffic that matches the specified conditions to be protected by crypto.

To configure a transform set that defines how the traffic will be protected. You can configure multiple transform sets, and then specify one or more of these transform sets in a crypto map entry (Step 4d).
crypto ipsec transform-set transform-set-name transform1 [transform2, transform3]

For example:
crypto ipsec transform-set myset1 esp-des esp-sha-hmac
crypto ipsec transform-set myset2 ah-sha-hmac esp-3des esp-sha-hmac

In this example, "myset1" and "myset2" are the names of the transform sets. "myset1" has two transforms defined, while "myset2" has three transforms defined.
Create a crypto map entry by performing the following steps:

Create a crypto map entry in IPSec ISAKMP mode:
crypto map map-name seq-num ipsec-isakmp

For example:
crypto map mymap 10 ipsec-isakmp

In this example, "mymap" is the name of the crypto map set. The map set's sequence number is 10, which is used to rank multiple entries within one crypto map set. The lower the sequence number, the higher the priority.
Assign an access list to a crypto map entry:
crypto map map-name seq-num match address access-list-name

For example:
crypto map mymap 10 match address 101

In this example, access-list 101 is assigned to crypto map "mymap."
Specify the peer to which the IPSec protected traffic can be forwarded:
crypto map map-name seq-num set peer ip-address

For example:
crypto map mymap 10 set peer 192.168.1.100

The security association will be set up with the peer having an IP address of 192.168.1.100. Specify multiple peers by repeating this command.
Specify which transform sets are allowed for this crypto map entry. List multiple transform sets in order of priority (highest priority first). You can specify up to six transform sets.
crypto map map-name seq-num set transform-set transform-set-name1 [transform-set-name2, transform-set-name6]

For example:
crypto map mymap 10 set transform-set myset1 myset2

In this example, when traffic matches access list 101, the security association can use either "myset1" (first priority) or "myset2" (second priority) depending on which transform set matches the peer's transform set.
(Optional) Specify security association lifetime for the crypto map entry, if you want the security associations for this entry to be negotiated using different IPSec security association lifetimes other than the global lifetimes.
crypto map map-name seq-num set security-association lifetime {seconds seconds | Kb Kb}

For example:
crypto map mymap 10 set security-association lifetime seconds 2700

This example shortens the timed lifetime for the crypto map "mymap 10" to 2700 seconds
(45 minutes). The traffic volume lifetime is not changed.
(Optional) Specify that IPSec should ask for perfect forward secrecy (PFS) when requesting new security associations for this crypto map entry, or should require PFS in requests received from the peer:
crypto map map-name seq-num set pfs [group1 | group2]

For example:
crypto map mymap 10 set pfs group2

This example specifies that PFS should be used whenever a new security association is negotiated for the crypto map "mymap 10." The 1024-bit Diffie-Hellman prime modulus group will be used when a new security association is negotiated using the Diffie-Hellman exchange.
Apply a crypto map set to an interface on which the IPSec traffic will be evaluated:
crypto map map-name interface interface-name

For example:
crypto map mymap interface outside

In this example, the firewall will evaluate the traffic going through the outside interface against the crypto map "mymap" to determine whether it needs to be protected.
Specify that IPSec traffic be implicitly trusted (permitted):
sysopt connection permit-ipsec

This command also permits L2TP/IPSec traffic.

Using Dynamic Crypto Maps

Dynamic crypto maps are recommended for use in networks where the peers are not always predetermined. Use dynamic crypto maps for VPN clients and routers that obtain dynamically assigned IP addresses.
Dynamic crypto maps can only be used for negotiating SAs with remote peers that initiate the connection. They cannot be used for initiating connections to a remote peer. With a dynamic crypto map entry, if outbound traffic matches a permit statement in an access list and the corresponding security association is not yet established the firewall will drop the traffic.
A dynamic crypto map entry is essentially a crypto map entry without all the parameters configured. It acts as a policy template where the missing parameters are later dynamically configured (as the result of an IPSec negotiation) to match a peer's requirements. This allows peers to exchange IPSec traffic with the firewall even if the firewall does not have a crypto map entry specifically configured to meet all the peer's requirements.
Only the transform-set field is required to be configured within each dynamic crypto map entry.
A dynamic crypto map set is included by reference as part of a crypto map set. Any crypto map entries that reference dynamic crypto map sets should be the lowest priority crypto map entries in the crypto map set (that is, have the highest sequence numbers) so that the other crypto map entries are evaluated first; that way, the dynamic crypto map set is examined only when the other (static) map entries are not successfully matched.
If the firewall accepts the peer's request at the point that it installs the new IPSec security associations, it also installs a temporary crypto map entry. This entry is filled in with the results of the negotiation. At this point, the firewall performs normal processing, using this temporary crypto map entry as a normal entry, even requesting new security associations if the current ones are expiring (based upon the policy specified in the temporary crypto map entry). Once the flow expires (that is, all the corresponding security associations expire), the temporary crypto map entry is then removed.
Dynamic crypto map entries, like regular static crypto map entries, are grouped into sets. A set is a group of dynamic crypto map entries all with the same dynamic-map-name but each with a different dynamic-seq-num. If this is configured, the data flow identity proposed by the IPSec peer should fall within a permit statement for this crypto access list. If this is not configured, the firewall will accept any data flow identity proposed by the peer.
You can add one or more dynamic crypto map sets into a crypto map set via crypto map entries that reference the dynamic crypto map sets. You should set the crypto map entries referencing dynamic maps to be the lowest priority entries in a crypto map set (that is, use the highest sequence numbers).
Use care when using the any keyword in permit entries in dynamic crypto maps. If it is possible for the traffic covered by such a permit entry to include multicast or broadcast traffic, the access list should include deny entries for the appropriate address range. Access lists should also include deny entries for network and subnet broadcast traffic, and for any other traffic that should not be IPSec protected.
The procedure for using a crypto dynamic map entry is the same as the basic configuration described in the Basic IPSec Configuration, except that instead of creating a static crypto map entry, you create a crypto dynamic map entry. You can also combine static and dynamic map entries within a single crypto map set.
Create a crypto dynamic map entry by performing the following steps:

Assign an access list to a dynamic crypto map entry:
crypto dynamic-map dynamic-map-name dynamic-seq-num match address access-list-name

This determines which traffic should be protected and not protected.
For example:
crypto dynamic-map dyn1 10 match address 101

In this example, access list 101 is assigned to dynamic crypto map "dyn1." The map's sequence number is 10.
Specify which transform sets are allowed for this dynamic crypto map entry. List multiple transform sets in order of priority (highest priority first).
crypto dynamic-map dynamic-map-name dynamic-seq-num set transform-set transform-set-name1, [transform-set-name2, transform-set-name9]

For example:
crypto dynamic-map dyn 10 set transform-set myset1 myset2

In this example, when traffic matches access list 101, the security association can use either "myset1" (first priority) or "myset2" (second priority) depending on which transform set matches the peer's transform sets.
Specify security association lifetime for the crypto dynamic map entry, if you want the security associations for this entry to be negotiated using different IPSec security association lifetimes other than the global lifetimes:
crypto dynamic-map dynamic-map-name dynamic-seq-num set security-association lifetime {seconds seconds | kilobytes kilobytes}

For example:
crypto dynamic-map dyn1 10 set security-association lifetime 2700

This example shortens the timed lifetime for dynamic crypto map "dyn1 10" to 2700 seconds
(45 minutes). The time volume lifetime is not changed.
Specify that IPSec should ask for PFS when requesting new security associations for this dynamic crypto map entry, or should demand PFS in requests received from the peer:
dynamic-map-name dynamic-seq-num set pfs [group1 | group2]

For example:
crypto dynamic-map dyn1 10 set pfs group1

Add the dynamic crypto map set into a static crypto map set.
Be sure to set the crypto map entries referencing dynamic maps to be the lowest priority entries (highest sequence numbers) in a crypto map set.
crypto mapmap-name seq-num ipsec-isakmp dynamic dynamic-map-name

For example:
crypto map mymap 200 ipsec-isakmp dynamic dyn1

Site-to-Site Redundancy

You can define multiple peers by using crypto maps to allow for redundancy. This configuration is also most useful for site-to-site VPNs. If one peer fails, there will still be a protected path. The peer that packets are actually sent to is determined by the last peer that the firewall heard from (received either traffic or a negotiation request from) for a given data flow. If the attempt fails with the first peer, IKE tries the next peer on the crypto map list.

Lifetime	Default
timed	28,800 seconds (8 hours)
traffic-volume	4,608,000 kilobytes (10 MB/sec for one hour)