Cisco PIX Firewalls: IPsec Tunnel on a PIX Firewall
Introduction
This month we continue a series of articles on the PIX. The present article explains configuring a PIX for IPsec. We'll assume you've read Pete's prior articles on IPsec. This saves us from having to explain how basic IPsec works all over again. (And saves you having to read all that over again!)
You may find the following articles useful background information:
- Cisco PIX Firewall Basics
- Cisco PIX Firewalls: Access Lists and Management
- Cisco PIX Firewalls: Fixups, Failover, and DHCP
- IPsec Simplified
- IPsec Simplified — Part 2
| Other Resources |
|
| Reference documentation for PIX 6.1 | http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_61/index.htm |
| Cisco CSPFA course (security certification track) | http://www.cisco.com/pcgi-bin/front.x/wwtraining/CELC/index.cgi?
action=CourseDesc&COURSE_ID=1628 |
| A Technical Guide to IPsec Virtual Private Networks, by James S. Tiller | A great book detailing IPsec available on the web at Amazon and similar resellers. ISBN 0-8493-0876-3. Amazon URL: http://www.amazon.com/exec/obidos/ASIN/0849308763/ |
Instant IPsec Review
IPsec requires that participating devices establish a Security Association (SA) where they agree on how to go about encrypting data. This SA is set up when the initial packet(s) of a flow matchs an access list (ACL) on one endpoint of the SA, triggering the endpoint to try to establish an SA with another IPsec endpoint.
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
This article details tunnel mode IPsec. In tunnel mode the endpoints of the VPN, in this example two PIXes sitting on respective Internet perimeters, transparently do the work of encrypting and decrypting the packets received from the hosts they protect. They tunnel the packets by encapsulating them inside a new header bearing the address of the two IPsec (PIX) endpoints. That way an observer cannot see the original source and destination of the packets.
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
In our sample configuration, we show configuration for the left PIX, PIX A. The configuration for the right PIX, PIX B, is extremely similar so we don't show it.
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
Several commands are helpful in troubleshooting IPsec connectivity. Some of these commands are listed below.
| Command | Purpose |
| show crypto ipsec sa | Shows any current security associations with remote peers. Each security protocol defined in the transform set will have an entry. If, for example, you don't use the AH (authentication header) protocol in your transform, there will not be an SA for this protocol. The security protocol "PCP" listed by this command will always be blank and should be ignored as it is contained within the PIX code but not actually supported by the PIX. |
| show crypto isakmp sa | Shows the defined ISAKMP policy which will also display in the PIX's configuration. |
| debug crypto isakmp | A good command to use first if your IPsec connection won't work. ISAKMP (IKE) is the first process in a successful tunnel so check this first. |
| debug crypto ipsec | A good command to use if the ISAKMP (IKE) process seems to be working correctly but your IPsec connection still won't work. IPsec is the second process in a successful tunnel so check this after checking isakmp as seen above. |
| clear crypto ipsec sa (config mode command) | Purposely clears security associations. Usually used during debugging operations where you wish to clear SA's, generate interesting traffic, then using debugging watch the tunnel endpoints attempt to reconnect. Aids in spotting problems. |
The following are some rules of thumb when working with IPsec on the PIX:
- Interesting traffic ACLs should match exactly on each peer set. If the IKE process is completing but traffic is not getting across the tunnel, check your interesting traffic ACLs. We have seen instances where the ACLs were not defining all potentially interesting traffic and that traffic was correctly being pushed out to the Internet via the default gateway where instead the PIX should have been pushing it into the tunnel. The problem was in the ACL entries the administrator had left out. Miss one and you get to troubleshoot.
- When specifying the peer IKE identity method, which can be either address or hostname, use the same method at each peer.
- When changing any IPsec or IKE setting, always turn off IPsec on the interface, make your changes, then turn it back on. In our example, if we need to make a change to the pre-shared key, we should issue the command "no crypto map IPSECMAP interface outside," change the pre-shared key, then issue the command "crypto map IPSECMAP interface outside." Failing to do this may cause operational strangeness which tends to lead to a PIX reboot.
- If you delete your interesting traffic ACL for some reason (maybe you need to redefine it), keep in mind that the previously entered commands "crypto map IPSECMAP 20 match address 101" and "nat (inside) 0 access-list 101" will disappear from the configuration and must be reapplied after you recreate your new ACL 101.
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#debug crypto isakmp (note: these debug messages below start with ISAKMP) PIX#debug crypto ipsec (note: these debug messages below start with IPSEC) VPN Peer: ISAKMP: Added new peer: ip:2.2.2.2 Total VPN Peers:1
Note: The peer is 2.2.2.2 and the local endpoint is 1.1.1.1. We're starting to negotiate with the peer and are starting IKE Phase I Main Mode exchange.
VPN Peer: ISAKMP: Peer ip:2.2.2.2 Ref cnt incremented to:1 Total VPN Peers:1
ISAKMP (0): beginning Main Mode exchange
crypto_isakmp_process_block: src 2.2.2.2, dest 1.1.1.1
OAK_MM exchange
ISAKMP (0): processing SA payload. message ID = 0
ISAKMP (0): Checking ISAKMP transform 1 against priority 10 policy
ISAKMP: encryption 3DES-CBC
ISAKMP: hash SHA
ISAKMP: default group 1
ISAKMP: auth pre-share
ISAKMP: life type in seconds
ISAKMP: life duration (basic) of 28800
ISAKMP (0): atts are acceptable. Next payload is 0
Note: the ISAKMP (IKE) transform proves to be OK with peer.
ISAKMP (0): SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
return status is IKMP_NO_ERROR
Note: the peers are using their IP addresses as part of the authentication process.
crypto_isakmp_process_block: src 2.2.2.2, dest 1.1.1.1
OAK_MM exchange
ISAKMP (0): processing KE payload. message ID = 0
ISAKMP (0): processing NONCE payload. message ID = 0
ISAKMP (0): processing vendor id payload
ISAKMP (0): processing vendor id payload
ISAKMP (0): received xauth v6 vendor id
ISAKMP (0): processing vendor id payload
ISAKMP (0): speaking to another IOS box!
ISAKMP (0): processing vendor id payload
ISAKMP (0): speaking to a VPN3000 concentrator
ISAKMP (0): ID payload
next-payload : 8
type : 1
protocol : 17
port : 500
length : 8
ISAKMP (0): Total payload length: 12
return status is IKMP_NO_ERROR
crypto_isakmp_process_block: src 2.2.2.2, dest 1.1.1.1
Note: if the debug halts at this point you probably have an incorrect pre-shared key though we never actually saw a message stating that the pre-shared key was incorrect . The PIX will wait for a few seconds then delete the SA. A correct configuration debug continues below....
OAK_MM exchange
ISAKMP (0): processing ID payload. message ID = 0
ISAKMP (0): processing HASH payload. message ID = 0
ISAKMP (0): processing vendor id payload
ISAKMP (0): remote peer supports dead peer detection
ISAKMP (0): SA has been authenticated
Note: IKE Phase I is complete. Starting IKE Phase II Quick Mode exchange to set up the IPsec SA.
ISAKMP (0): beginning Quick Mode exchange, M-ID of 2050327879:7a358547IPSEC(key_engine): got a queue event...
IPSEC(spi_response): getting spi 0xeb119f20(3943800608) for SA
from 2.2.2.2 to 1.1.1.1 for prot 3
return status is IKMP_NO_ERROR
ISAKMP (0): sending INITIAL_CONTACT notify
ISAKMP (0): sending NOTIFY message 24578 protocol 1
ISAKMP (0): sending INITIAL_CONTACT notify
crypto_isakmp_process_block: src 2.2.2.2, dest 1.1.1.1
OAK_QM exchange
oakley_process_quick_mode:
ISAKMP (0): processing SA payload. message ID = 2050327879
ISAKMP : Checking IPSec proposal 1
ISAKMP: transform 1, ESP_3DES
ISAKMP: attributes in transform:
ISAKMP: SA life type in seconds
ISAKMP: SA life duration (basic) of 28800
ISAKMP: SA life type in kilobytes
ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0
ISAKMP: encaps is 1
ISAKMP: authenticator is HMAC-SHA
ISAKMP (0): atts are acceptable.IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) dest= 2.2.2.2, src= 1.1.1.1,
dest_proxy= 10.18.1.0/255.255.0.0/0/0 (type=4),
src_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-3des esp-sha-hmac ,
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4 ISAKMP (0): processing NONCE payload. message ID = 2050327879
ISAKMP (0): processing ID payload. message ID = 2050327879
ISAKMP (0): Creating IPSec SAs
inbound SA from 2.2.2.2 to 1.1.1.1 (proxy 10.18.1.0 to 10.1.1.0)
has spi 3943800608 and conn_id 2 and flags 4
lifetime of 28800 seconds
lifetime of 4608000 kilobytes
outbound SA from 1.1.1.1 to 2.2.2.2 (proxy 10.1.1.0 to 10.18.1.0)
has spi 714795608 and conn_id 1 and flags 4
lifetime of 28800 seconds
lifetime of 4608000 kilobytesIPSEC(key_engine): got a queue event...
Note: IKE Phase II ends. The IPsec SA's for transporting the data between PIXes are created and each gets an assigned SPI (Security Parameter Index) which is like a serial number and identifies the SA.
IPSEC(initialize_sas): ,
(key eng. msg.) dest= 1.1.1.1, src= 2.2.2.2,
dest_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4),
src_proxy= 10.18.1.0/255.255.0.0/0/0 (type=4),
protocol= ESP, transform= esp-3des esp-sha-hmac ,
lifedur= 28800s and 4608000kb,
spi= 0xeb119f20(3943800608), conn_id= 2, keysize= 0, flags= 0x4
IPSEC(initialize_sas): ,
(key eng. msg.) src= 1.1.1.1, dest= 2.2.2.2,
src_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4),
dest_proxy= 10.18.1.0/255.255.0.0/0/0 (type=4),
protocol= ESP, transform= esp-3des esp-sha-hmac ,
lifedur= 28800s and 4608000kb,
spi= 0x2a9aea58(714795608), conn_id= 1, keysize= 0, flags= 0x4 VPN Peer: IPSEC: Peer ip:2.2.2.2 Ref cnt incremented to:2 Total VPN Peers:1
return status is IKMP_NO_ERR_NO_TRANS
PIX IPsec Performance Numbers
The Cisco PIX product page at http://www.cisco.com/warp/public/cc/pd/fw/sqfw500/ has the official performance numbers posted on it. See it for more info!
Conclusion
It's been fun working on these articles with Grant. This concludes our series on the PIX.
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.
-Click the Copy button and right click in the Hyper Terminal to paste the file name for copying it into the flash.
3) Inside System Properties, find this parameter: mxe.report.birt.viewerurl
4) Click on the arrow beside mxe.report.birt.viewerurl. Then inside the parameter, change the global value(by default, if left blank is pointing to localhost) to "http://
5) A dialogue will popup, click ok to confirmed changing the engine properties.
6) This is done. All clients that access Maximo 7 Server to generate report, will have their reports generated using Maximo 7 Server Report Only Server.
Windows Server 2008 R2 delivers valuable new functionality and powerful improvements to the core Windows Server operating system to help organizations of all sizes increase control, availability, and flexibility for their changing business needs. New Web tools, virtualization technologies, scalability enhancements, and management utilities help save time, reduce costs, and provide a solid foundation for your information technology (IT) infrastructure.
