Cisco PIX Firewalls: IPsec on a PIX

In order to establish an SA, the two IPsec devices typically use an automatic technique called IKE (ISAKMP). IKE stands for Internet Key Exchange. IKE uses asymmetric public key cryptography to securely establish the SA between the two devices. The first stage of IKE, Phase 1, is for the devices to authenticate to each other. In the second stage of IKE, Phase 2, the devices then negotiate securely as to what form of encryption to use, and the other parameters of the SA (lifetime for example). The outcome of all this is the secure exchange of a single key. This key is subsequently used by both endpoints for encoding and decoding messages using the DES or 3DES symmetric encryption algorithm.

IPsec uses DES or 3DES because using public key cryptography to encrypt large data flows is still too processor intense. Public key cryptography is only used during IKE to encode small amounts of data, namely the negotiation to agree upon rules for the security association and the symmetric key exchange. IKE is simply the preliminary asymmetric process used to get the two endpoints talking and agreeing on a symmetric key.

IPsec Modes

Packets that pass the interesting traffic test are the only ones inserted into the tunnel. For example, suppose LAN A and B are the inside LANs of PIX A and B. Host A requires periodic communication with Host B and ABC Corp's security policy dictates that it must be done securely over the Internet. The configurations of the two PIX units specify that when traffic is seen destined to or from Host A or B this is considered to be interesting and that the data should be sent via the IPsec tunnel.

The beauty of this is that neither Host A nor B have knowledge this process is happenning. The PIX IPsec endpoints take care of all the encrypting, decrypting, and key management. You also arrange for them to deal with the VPN routing. Insertion into the tunnel, as previously mentioned, means that an entire packet from Host A destined for Host B is encrypted and becomes the payload of a new packet which is Internet routable. It is sent to PIX B. PIX B pulls out the encrypted payload data, decrypts it with the symmetric key, and forwards it to Host B. For a picture of this and more description, see Pete's earlier IPsec articles ( above ).

By way of contrast, transport mode VPN is where Host A and B are themselves the VPN endpoints and do the work of IPsec encryption and authentication. Transport mode VPNs might be appropriate in some instances but can create increased sensitivity to topology changes. For example, the introduction of network address translation (NAT) at a perimeter is likely to break IPsec between two hosts because NAT alters packet source or destination, but IPsec tracks identities based on those addresses.

VPN endpoints might be two PIXes, a PIX and a router supporting IPsec, a Cisco VPN concentrator and a non-Cisco firewall, etc. The endpoints just needs to implement the IPsec standard. The caveat is that the protocol has many options and sometimes two devices might not fully handle every part of the IPsec specification. IPsec has been mainstream long enough though that you generally have lots of options when it comes to matching up endpoints. A coming new version of IPsec may simplify IKE to make things simpler and reduce interoperability versions.

PIX IPsec Configuration

There are basically two parts to the configuration. One is to specify IKE policy, the other is to specify what forms of encryption and hashing are allowed in forming the Security Association. And what traffic to encrypt.

First we have the IKE parameters. See the configuration sample in the left column of the table below. The right column explains each command.


Command	Purpose
isakmp enable outside	Enable IKE on the interface named "outside".
isakmp key d$$f%ghYtQweoiu 2.2.2.2 netmask 255.255.255.255	Defines the shared information (key) to set up the initial tunnel during the Diffie-Hellman process (see Pete's IPsec Simplified article). This key is for peer 2.2.2.2 only (the mask 255.255.255.255 is a subnet-style mask specifying an exact match only). Likewise peer 2.2.2.2 will use the same pre-shared key in its configuration when referring to our PIX.
isakmp identity address	The identity is either address or hostname. If RSA authentication is being used, it is better to use "hostname" for source of identity.
isakmp policy 10 authentication pre-share	IKE policy 1 is the highest priority. So if we start with 10 as the typical peer policy to use, we can plug in other higher priority ones if we later need to. The command shown to the left specifies IKE authentication should use a pre-shared key (defined above). RSA ("rsa-sig") is the other possible choice.
isakmp policy 10 encryption des	Continuing policy 10, a DES encryption key is to be used by IKE to determine policy. 3DES is the other possible choice.PIX DES keys are free from Cisco whereas 3DES keys must be bought.
isakmp policy 10 hash sha	Hash has to be MD5 or SHA, as one would expect. Cisco regards SHA as a stronger algorithm for fingerprinting and makes it the default.
isakmp policy 10 group 1	768-bit Diffie Hellman group (group 2 means 1024-bit Diffie-Hellman). Group 2 is stronger but requires more processing time.
isakmp policy 10 lifetime 28800	Default lifetime of the SA policy is 86,400 seconds (1 day). For any peer, the shorter of the two lifetimes will be selected.

After setting up how the PIX is to go about doing IKE, we also need to tell it how to go about doing IPsec.


Command	Purpose
sysopt connection permit-ipsec	Permits incoming IPsec packets to pass through the PIX and bypass the access lists (ACLs) that govern non-IPsec traffic. In our example, traffic matching ACL 101 will be allowed through the PIX without examination by a packet-filtering ACL due to this command.
crypto ipsec transform-set IPSECXFORM esp-des esp-sha-hmac	Defines the type of security protocols to be used between peers in an IPsec security association. In this case the transform set named IPSECXFORM will use single DES encapsulating security payload (ESP) for the encryption of the payload data and will use SHA1 as the authentication mechanism on that payload to ensure it has not been altered in transit. Each transform-set can contain up to 3 transforms like this at the end of the same line.
crypto map IPSECMAP 20 ipsec-isakmp	Specifies that IKE will be used to establish the IPsec security associations for this crypto map. IPSECMAP is the administrator assigned name of the map and 20 is a sequence number (in case of multiple peer blocks in the same crypto map). Sequence numbers allow different crypto combinations for different peers reached by the interface this crypto map is applied to. There can only be one crypto map per interface, so we use the sequence number blocks to put different policies into that one crypto map.
crypto map IPSECMAP 20 match address 101	Specifies that traffic matching access list 101 will be viewed as "interesting" and will be encrypted or decrypted (depending on direction) per this crypto map block (sequence number 20). Traffic matching another access list for another crypto map block ("chunk") might use the security association information specified there to do things somewhat differently. So you should make sure there's no ambiguity due to sloppiness or overlapping access lists.
crypto map IPSECMAP 20 set peer 2.2.2.2	For a static crypto map, this specifies a peer using the crypto map security policy. Repeat the command to use the same crypto map for multiple peers.
crypto map IPSECMAP 20 set transform-set IPSECXFORM	This is what form of hashing and/or encoding (transform sets) to use for these peers as defined above in the second row.
crypto map IPSECMAP interface outside	And this is the interface where this crypto map is to be used. Again, there can only be one crypto map per interface.
access-list 101 permit ip 10.1.1.0 255.255.255.0 10.18.1.0 255.255.255.0	Access list 101 specifies what traffic to encrypt. In this case, all traffic from 10.1.1.0 /24 to 10.18.1.0 /24 will be encrypted. Unencrypted inbound traffic that matches the access list gets discarded, to prevent spoofing. The assumption is that such traffic should have arrived encrypted. It is extremely important to note that the interesting traffic ACLs for each peer must match exactly or you will see unpredictable results in getting traffic across the tunnel. Grant recently encountered this head scratcher of a problem.
nat (inside) 0 access-list 101	Instructs the PIX to allow traffic matching the IPsec interesting traffic ACL to bypass other defined NAT processes . Packets defined as "interesting" are involved in connecting our two privately addressed (RFC 1918) hosts A and B and are traversing the Internet. However, they are doing so by being encrypted and embedded within routable packets. Essentially the PIX is not performing the NAT process for these packets then performing the encrypting and repackaging of the packet to get it to its peer whereupon the peer unwraps, decrypts, and sends the packet to the destination host.

The other endpoint of this connection is configured very similarly. The only changes needed are the peer address and the access-list (which probably just needs to have source and destination address/mask pairs swapped).

Monitoring and Debugging

The following output, that happens to be for a tunnel mode VPN from a PIX to VPN3000 concentrator, shows debug of the Phase 1 and Phase 2 IKE process and the IPsec process that follows that.

PIX IPsec Performance Numbers

Conclusion

Pete expects to shift gears, so the next articles will cover topics such as High Availability, the Cisco GRIP program, and some new MPLS capabilities. Meanwhile, Grant will be looking at some of Cisco's newer IDS features, functions, and security reporting capabilities.

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .

Grant P. Moerschel (CCNP #CSCO10108676) works for NovatoSystems.com LLC, an Internet security and network architecture consultancy and developers of FlackJacket security. NovatoSystems specializes in creating multi-layered secure networks based on the Cisco SAFE blueprint. FlackJacket, the premiere product offering of NovatoSystems, uses best-of-breed security components and advanced reporting systems to provide your organization with greater peace of mind regarding data protection. See http://www.flackjacket.net for more information. Questions, suggestions for articles, etc. can be sent to gm@flackjacket.net .