Foundation TopicsOverview of Virtual Private Network TechnologiesBefore the creation of VPN technologies, the only way for companies to secure network communications between different locations was to purchase or lease costly dedicated connections. VPNs allow companies to create secure encrypted tunnels between locations over a shared network infrastructure such as the Internet. A VPN is a service that offers secure, reliable connectivity over a shared public network infrastructure. VPNs are broken into three types based on the business component accessing the VPN and the assets available by using the VPN:
Internet Protocol SecurityInternet Protocol Security (IPSec) is not a protocol. It is a framework of open-standard protocol suites designed to provide data authentication, data integrity, and data confidentiality. IPSec runs at the Internet Protocol (IP) layer and uses Internet Key Exchange (IKE) to negotiate the security association (SA) between the peers. There are actually two phases of negotiation that must take place. The phase 1 negotiation establishes the IKE SA. The IKE SA must be established to begin the phase 2 negotiations to establish the IPSec SA. The following items must be negotiated as phase 1 of IKE SA negotiation:
As soon as the IKE SA negotiation is complete, the established SA is bidirectional. The phase 2 negotiations establish unidirectional SAs between two IPSec peers. The SAs determine the keying, protocols, and algorithms to be used between the peers. Two primary security protocols are included as part of the IPSec standard supported by the PIX:
It is important to note that ESP authenticates only the payload, and AH authenticates the entire packet including the IP header. Support for Network Address Translation and Port Address TranslationPIX Version 6.3 supports ESP with NAT using a new fixup protocol that allows for application inspection of ESP. PIX OS Version 6.3 also supports ESP with Port Address Translation (PAT) by restricting ESP to a single port (port 0) but with only a single ESP tunnel. Application inspection of ESP is disabled by default and can be enabled with the fixup protocol esp-ike command. This fixup protocol performs ESP tunnel serialization and the matching and recording of Security Parameter Indexes (SPIs) for each ESP connection. The SPI is a number that combines with the destination IP address and security protocol to uniquely identify the SA. AH does not support either a NAT or PAT device between the two AH peers. Another feature supported by PIX Version 6.3 is NAT Traversal. NAT Traversal allows ESP packets to pass through one or more NAT devices. The command for NAT Traversal is isakmp nat-traversal [ natkeepalives ]. The values for natkeepalives is between 10 and 3600 seconds. Supported Encryption AlgorithmsBoth ESP and AH can be configured to use a specific encryption algorithm and hash algorithms. An encryption algorithm is the mathematical algorithm used to encrypt and decrypt the data. The hash algorithm is used to ensure data integrity. Chapter 3, "Cisco PIX Firewall," for the specific licenses available for each firewall model. The PIX supports the following encryption algorithms:
A hash algorithm takes a message as input and creates a fixed-length output called the message digest . The message digest is put into the digital signature algorithm, which generates or verifies the signature for the message. Signing the message digest rather than the actual message usually improves the processing of the message, because the message digest is smaller than the message. The same hash algorithm must be used by the originator and verifier of the message. The Cisco PIX Firewall supports the Keyed-Hash Message Authentication Code (HMAC) variant of the following hash algorithms:
Internet Key ExchangeInternet Key Exchange is the protocol that is responsible for negotiation. IKE is the short name for ISAKMP/Oakley, which stands for Internet Security Association and Key Management Protocol (with Oakley distribution). The terms IKE and ISAKMP are used interchangeably throughout this chapter. IKE operates over User Datagram Protocol (UDP) port 500 and negotiates the key exchange between the ISAKMP peers to establish a bidirectional SA. This process requires that the IPSec systems first authenticate themselves to each other and establish ISAKMP (IKE) shared keys. This negotiation is called phase 1 negotiation, and it is during this phase that the Diffie-Hellman key agreement is performed. During phase 1, IKE creates the IKE SA, which is a secure channel between the two IKE peers. IKE authenticates the peer and the IKE messages between the peers during IKE phase 1. Phase 1 consists of main mode or aggressive mode . A main mode negotiation consists of six message exchanges:
Figure 11-6 shows aggressive mode key exchanges. Figure 11-6. Aggressive Mode Key ExchangesNote Diffie-Hellman is a public-key cryptography protocol that is used between two IPSec peers to derive a shared secret over an unsecured channel without transmitting it to each peer. The PIX Firewall supports three Diffie-Hellman groups: Group 1 is 768-bit, group 2 is 1024-bit, and group 5 is 1536-bit. Peers that want to participate in the IPSec session must authenticate themselves to each other before IKE can proceed. Peer authentication occurs during the main mode/aggressive mode exchange during IKE phase 1. The IKE protocol is very flexible and supports multiple authentication methods as part of the phase 1 exchange. The two entities must agree on a common authentication protocol through a negotiation process. IKE phase 1 has three methods to authenticate IPSec peers in Cisco products:
Having completed the phase 1 negotiation, IKE provides a secure channel for the completion of phase 2. The phase 2 exchange occurs only after the IKE SA negotiation is complete. It is used to derive keying material and negotiate policies for non-ISAKMP SAs (such as the IPSec SA). IKE performs the following functions and provides the following benefits:
Perfect Forward SecrecyPerfect Forward Secrecy (PFS) is the function of two parties agreeing on a temporary session key that is different for each message. This provides confidence that the compromise of the long-term private key does not compromise previous session keys. PFS prevents an eavesdropper from being able to decrypt traffic even if the eavesdropper has the private keys from both parties because the parties negotiate the temporary session key. Certification AuthoritiesIKE interoperates with X.509v3 certificates for authentication that requires public keys. Certification authorities (CAs) manage certificate requests, issue digital certificates, and publish certificate revocation lists (CRLs) to list certificates that are no longer valid. A digital certificate contains information about the user or device and includes a copy of its public key. This technology enables IPSec-protected networks to scale, because the peers simply exchange digital certificates that have been authenticated by a CA, removing the requirement to configure the preshared key manually for each IPSec peer. The PIX interoperates with CA server products from the following vendors:
After ensuring that you have correctly configured the firewall host name, domain name, and the system date/time, you can initiate enrollment with a CA server. It is important that your date and time are correctly configured so that you can verify the validity of the certificate when received. The process that a PIX uses to enroll with a CA server is as follows:
Configuring the PIX Firewall as a Virtual Private Network GatewayConfiguring the Cisco PIX Firewall as a VPN gateway or VPN termination point is a process that requires four specific tasks:
Selecting the ConfigurationSelecting a standardized configuration is perhaps the most important step in creating a VPN. You need to follow these steps when selecting your configuration: It is extremely important to ensure that VPN peers have configurations with matching elements. If both peers are not configured to have compatible VPN components, they will be unable to create the encrypted connection. Configuring IKERemember that IKE is the method used by the peers to negotiate and establish the SA. Determining which IKE configuration to use is not difficult. Most companies have a standard configuration that they employ when creating any VPN connection. If you do not have a preestablished policy, you should select a policy that allows your minimum amount of security to be not less than that required for the most sensitive data to travel across the connection. The following steps are required to configure IKE on a Cisco PIX Firewall:
Configuring IPSecNow that you have successfully configured IKE on your firewall, you are ready to configure IPSec. Follow these steps:
Step 1: Creating a Crypto Access ListCrypto access lists are used to identify which IP traffic is to be protected by encryption and which traffic is not. After the access list is defined, the crypto maps reference it to identify the type of traffic that IPSec protects. The permit keyword in the access list causes IPSec to protect all IP traffic that matches the access list criteria. If the deny keyword is used in the access list, the traffic is not encrypted. The crypto access lists specified at the remote peer should be mirror images of the access lists specified at the local peer. This ensures that traffic that has IPSec protection applied locally can be processed correctly at the remote peer. The crypto map entries should also support common transforms and should refer to the other system as a peer. It is not recommended that you use the permit ip any any command, because it causes all outbound traffic to be encrypted (and all encrypted traffic to be sent to the peer specified in the corresponding crypto map entry), and it requires encryption of all inbound traffic. With this type of access list, the firewall drops all inbound packets that are not encrypted. The syntax for the access-list command is as follows: access-list acl_name permit | deny protocol src_addr src_mask [ operator port [ port ]] dest_addr dest_mask [ operator port [ port ]] Table 11-3 lists and describes the command arguments and options for the access-list command.
Note The configuration examples in this chapter build on each other (they include the previous portion). The specific items that are being addressed as part of the current configuration are highlighted. Example 11-1 shows the current ISAKMP policy configuration with the access list added: Example 11-1. Crypto Access Listtgpix(config)# isakmp policy 10 authentication pre-share tgpix(config)# isakmp policy 10 encryption 3des tgpix(config)# isakmp policy 10 group 2 tgpix(config)# isakmp policy 10 hash md5 tgpix(config)# isakmp policy 10 lifetime 86400 tgpix(config)# isakmp enable outside tgpix(config)# isakmp identity address tgpix(config)# isakmp key abc123 address 192.168.2.1 netmask 255.255.255.255 tgpix(config)# access-list 90 permit ip 10.10.10.0 255.255.255.0 10.10.20.0 255.255.255.0 Step 2: Configuring a Transform SetA transform set defines the combination of encryption algorithms and message integrity algorithms to be used for the IPSec tunnel. Transforms are combined to make transform sets . Both peers agree on the transform set during the IPSec negotiation. You can define multiple transform sets because both peers search for a common transform set during the IKE negotiation. If a common transform set is found, it is selected and applied to the protected traffic. Table 11-4 shows the transform sets supported on the Cisco PIX Firewall.
Note hmac represents Keyed-Hashing for Message Authentication and is outlined in RFC 2104. The syntax for the transform-set command is as follows: crypto ipsec transform-set transform-set-name transform1 [ transform2 [ transform3 ]] Example 11-2 shows the current ISAKMP policy configuration with the access list and transform set defined: Example 11-2. Crypto Transform Settgpix(config)# isakmp policy 10 authentication pre-share tgpix(config)# isakmp policy 10 encryption 3des tgpix(config)# isakmp policy 10 group 2 tgpix(config)# isakmp policy 10 hash md5 tgpix(config)# isakmp policy 10 lifetime 86400 tgpix(config)# isakmp enable outside tgpix(config)# isakmp identity address tgpix(config)# isakmp key abc123 address 192.168.2.1 netmask 255.255.255.255 tgpix(config)# access-list 90 permit ip 10.10.10.0 255.255.255.0 10.10.20.0 255.255.255.0 tgpix(config)# crypto ipsec transform-set strong esp-3des esp-md5-hmac Step 3: Configuring IPSec Security Association LifetimesTo preclude any opportunity to gather sufficient network traffic using a single encryption key, it is important to limit the key lifetime. This forces a key exchange, changing the encryption scheme and greatly reducing the possibility of cracking the key. Technology continues to advance, producing computers that can break code at faster rates. However, these systems require a certain amount of traffic encrypted under a single key. The idea is to change encryption keys before any system can feasibly crack your encryption. The PIX enables you to configure your SA lifetimes, forcing a key exchange. It is possible to limit the SA lifetime either by the amount of traffic passing through the connection or by how long the encrypted connection remains open. The command for configuring SA lifetimes is as follows: crypto ipsec security-association lifetime [kilobytes | seconds] Example 11-3 shows the current configuration, including an SA lifetime of 15 minutes (900 seconds): Example 11-3. Crypto IPSec SA Lifetimetgpix(config)# isakmp policy 10 authentication pre-share tgpix(config)# isakmp policy 10 encryption 3des tgpix(config)# isakmp policy 10 group 2 tgpix(config)# isakmp policy 10 hash md5 tgpix(config)# isakmp policy 10 lifetime 86400 tgpix(config)# isakmp enable outside tgpix(config)# isakmp identity address tgpix(config)# isakmp key abc123 address 192.168.2.1 netmask 255.255.255.255 tgpix(config)# access-list 90 permit ip 10.10.10.0 255.255.255.0 10.10.20.0 255.255.255.0 tgpix(config)# crypto ipsec transform-set strong esp-3des esp-md5-hmac tgpix(config)# crypto ipsec security-association lifetime seconds 900 Step 4: Configuring Crypto MapsJust as the isakmp policy command configures the parameters for the IKE negotiations, crypto map tells the PIX Firewall how to negotiate the IPSec SA. The crypto map command is the final piece of the puzzle that is used on both peers to establish the SA. Again, it is extremely important that the settings are compatible on both ends. If both peers do not have a compatible configuration, they cannot establish the VPN connection. This does not mean that the configuration must be an exact match (like the isakmp configurations), but the peers must have matching elements within the crypto map. Many different components are covered by the crypto map command. The following parameters are set using this command:
Three steps are required for configuring crypto maps:
It is important that you ensure that all three steps are completed. Although each line of the crypto map is considered "creating the crypto map," specific lines apply the crypto map and specify the IPSec traffic. These lines are discussed next. Normally, you have at least five crypto map entries with the same name. These entries combine to list your IPSec SA configuration. Each line of the configuration has its own purpose. The following text shows and explains the syntax of each line. crypto map map-name seq-num ipsec-isakmp This line establishes the crypto map by name and sequence number and specifies that IKE negotiates the SA. crypto map map-name seq-num match address acl_name This line binds the access list to the crypto map. It establishes which traffic is encrypted and which is not. This line specifies which IPSec traffic is permitted. It defines the traffic as "interesting." crypto map map-name seq-num set transform-set transform-set-name This line identifies which transform set is to be used. The transform-set-name is assigned to the transform set using the crypto ipsec transform-set command. crypto map map-name seq-num set peer ip-address This line identifies the SA peer by IP address. crypto map map-name interface if_name This line applies the crypto map to a specific interface. In much the same way that the access-group command is used to bind the access lists to an interface for standard ACLs, this command binds the entire crypto map process (including the crypto access list) to the interface. This line applies the crypto map set to a specific interface on the firewall. Additional crypto map entries can include set pfs, set security-association lifetime , and client authentication settings. Example 11-4 shows the current configuration, including the crypto map entries. Note that the access list is numbered 90 and the match address command references 90 . The ipsec transform-set is named strong , and the set transform-set references the name strong . Example 11-4. Crypto Map Entriestgpix(config)# isakmp policy 10 authentication pre-share tgpix(config)# isakmp policy 10 encryption 3des tgpix(config)# isakmp policy 10 group 2 tgpix(config)# isakmp policy 10 hash md5 tgpix(config)# isakmp policy 10 lifetime 86400 tgpix(config)# isakmp enable outside tgpix(config)# isakmp identity address tgpix(config)# isakmp key abc123 address 192.168.2.1 netmask 255.255.255.255 tgpix(config)# access-list 90 permit ip 10.10.10.0 255.255.255.0 10.10.20.0 255.255.255.0 tgpix(config)# crypto ipsec transform-set strong esp-3des esp-md5-hmac tgpix(config)# crypto ipsec security-association lifetime seconds 900 tgpix(config)# crypto map gonder 10 ipsec-isakmp tgpix(config)# crypto map gonder 10 match address 90 tgpix(config)# crypto map gonder 10 set transform-set strong tgpix(config)# crypto map gonder 10 set peer 192.168.2.1 tgpix(config)# crypto map gonder interface outside Table 11-5 describes the different crypto map command arguments and options that are available when you are configuring crypto maps.
sysopt connection permit-ipsec CommandThe sysopt command reconfigures the system options. The command sysopt connection permit-ipsec implicitly permits all packets that arrive from the IPSec tunnel to bypass any checking of access lists, conduits, or access-group command statements for IPSec connections. If the sysopt connection permit-ipsec command is not specified, an explicit rule (conduit or ACL) must be coded to allow the traffic arriving from the IPSec tunnel through the firewall. Example 11-5 shows the current configuration with this command included: Example 11-5. sysopt connection permit-ipsectgpix(config)# isakmp policy 10 authentication pre-share tgpix(config)# isakmp policy 10 encryption 3des tgpix(config)# isakmp policy 10 group 2 tgpix(config)# isakmp policy 10 hash md5 tgpix(config)# isakmp policy 10 lifetime 86400 tgpix(config)# isakmp enable outside tgpix(config)# isakmp identity address tgpix(config)# isakmp key abc123 address 192.168.2.1 netmask 255.255.255.255 tgpix(config)# nat (inside) 0 access list 90 tgpix(config)# access-list 90 permit ip 10.10.10.0 255.255.255.0 10.10.20.0 255.255.255.0 tgpix(config)# crypto ipsec transform-set strong esp-3des esp-md5-hmac tgpix(config)# crypto ipsec security-association lifetime seconds 900 tgpix(config)# crypto map gonder 10 ipsec-isakmp tgpix(config)# crypto map gonder 10 match address 90 tgpix(config)# crypto map gonder 10 set transform-set strong tgpix(config)# crypto map gonder 10 set peer 192.168.2.1 tgpix(config)# crypto map gonder interface outside tgpix(config)# sysopt connection permit-ipsec Troubleshooting the Virtual Private Network ConnectionConfiguring an SA peer can be extremely complicated and must be exact. If both peers are not configured correctly, they cannot successfully establish the VPN connection. The most common VPN issue is an incorrect configuration of either of the SA peers. The first step of troubleshooting a VPN should always be to compare the configurations of both peers and verify that they match. Three commands and a variety of command options are available to help you troubleshoot VPN issues:
show CommandThe show command lets you view different portions of the configuration and see the condition of ISAKMP and IPSec SAs. Table 11-6 explains the different show commands.
Example 11-6 displays the output from the show crypto isakmp sa command on the PIX Firewall in 192.168.1.2 that is configured for a VPN connection to 192.168.2.1. Example 11-6. show crypto isakmp sa Command Outputtgpix# show crypto isakmp sa dst src state conn-id slot 192.168.2.1 192.168.1.1 QM_IDLE 1 0 Example 11-7 displays the output from show crypto ipsec sa for the same firewall. Example 11-7. show crypto ipsec sa Command Outputtgpix# show crypto ipsec sa interface: outside Crypto map tag: 10, local addr. 192.168.1.1 local ident (addr/mask/port/port): (10.10.10.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (192.168.2.1/255.255.255.255/0/0) current_peer: 192.128.1.1 dynamic allocated peer ip: 192.168.2.1 PERMIT, flags={} #pkts encaps: 345, #pkts encrypt: 345, #pkts digest 0 #pkts decaps: 366, #pkts decrypt: 366, #pkts verify 0 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 192.168.1.1, remote crypto endpt.: 192.168.2.1 path mtu 1500, ipsec overhead 56, media mtu 1500 current outbound spi: 9a46ecae inbound esp sas: spi: 0x50b98b5(84646069) transform: esp-3des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 1, crypto map: Chapter11 sa timing: remaining key lifetime (k/sec): (460800/21) IV size: 8 bytes replay detection support: Y inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0x9a46ecae(2588339374) transform: esp-3des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2, crypto map: Chapter11 sa timing: remaining key lifetime (k/sec): (460800/21) IV size: 8 bytes replay detection support: Y outbound ah sas: clear CommandThe clear command allows you to remove current settings. You must be very careful when using the clear command to ensure that you do not remove portions of your configuration that are needed. The most common use of the clear command for troubleshooting VPN connectivity is to clear current sessions and force them to regenerate. Table 11-7 explains the two clear commands used to troubleshoot VPN connectivity.
debug CommandThe debug command lets you watch the VPN negotiation take place. This command is available only from configuration mode on the PIX and will not display any output in a Telnet session. Table 11-8 explains the two debug commands most commonly used to troubleshoot VPN connectivity.
Example 11-8 displays the output from the debug crypto isakmp command on the PIX Firewall in 192.168.1.1 that is configured for a VPN connection to 192.168.2.1. Note the highlighted comments "atts are not acceptable" and "atts are acceptable" that are generated during the negotiation as address transforms attempt to find a match. Example 11-8. debug crypto isakmp Command Outputcrypto_isakmp_process_block: src 192.168.1.1, dest 192.168.2.1 OAK_AG exchange ISAKMP (0): processing SA payload. message ID = 0 ISAKMP (0): Checking ISAKMP transform 1 against priority 1 policy ISAKMP: encryption DES-CBC ISAKMP: hash MD5 ISAKMP: default group 1 ISAKMP: auth pre-share ISAKMP (0): atts are not acceptable. Next payload is 3 ISAKMP (0): Checking ISAKMP transform 3 against priority 1 policy ISAKMP: encryption ESP_3DES ISAKMP: hash HMAC-MD5 ISAKMP: default group 2 ISAKMP: auth pre-share ISAKMP (0): atts are acceptable. Next payload is 3 ISAKMP (0): processing KE payload. message ID = 0 ISAKMP: Created a peer node for 192.168.2.1 OAK_QM exchange ISAKMP (0:0): Need config/address ISAKMP (0:0): initiating peer config to 192.168.2.1. ID = 2607270170 (0x9b67c91a) return status is IKMP_NO_ERROR crypto_isakmp_process_block: src 192.168.2.1, dest 192.168.1.1 ISAKMP_TRANSACTION exchange ISAKMP (0:0): processing transaction payload from 192.168.2.1. message ID = 2156506360 ISAKMP: Config payload CFG_ACK ISAKMP (0:0): peer accepted the address! ISAKMP (0:0): processing saved QM. oakley_process_quick_mode: OAK_QM_IDLE ISAKMP (0): processing SA payload. message ID = 448324052 ISAKMP: Checking IPSec proposal 1 ISAKMP: transform 1, ESP_DES ISAKMP: attributes in transform: ISAKMP: authenticator is HMAC-MD5 ISAKMP: encaps is 1 IPSec(validate_proposal): transform proposal (prot 3, trans 2, hmac_alg 1) not supported ISAKMP (0): atts not acceptable. Next payload is 0 ISAKMP: Checking IPSec proposal 2 ISAKMP: transform 1, ESP_3DES ISAKMP: attributes in transform: ISAKMP: authenticator is HMAC-MD5 ISAKMP: encaps is 1 ISAKMP (0): atts are acceptable. ISAKMP (0): processing NONCE payload. message ID = 448324052 ISAKMP (0): processing ID payload. message ID = 44 ISAKMP (0): processing ID payload. message ID = 44 INITIAL_CONTACTIPSec(key_engine): got a queue event... Example 11-9 displays the output from debug crypto ipsec for the same firewall. Notice that this debug command actually depicts the real address of the node behind the firewall that is initiating the VPN connection. Example 11-9. debug crypto ipsec Command OutputIPSec(key_engine): got a queue event... IPSec(spi_response): getting spi 0xd532efbd(3576885181) for SA from 192.168.2.1 to 192.168.1.1 for prot 3 return status is IKMP_NO_ERROR crypto_isakmp_process_block: src 192.168.2.1, dest 192.168.1.1 OAK_QM exchange oakley_process_quick_mode: OAK_QM_AUTH_AWAIT ISAKMP (0): Creating IPSec SAs inbound SA from 192.168.2.1 to 192.168.1.1 (proxy 10.10.10.3 to 192.168.1.1.) has spi 3576885181 and conn_id 2 and flags 4 outbound SA from 192.168.1.1 to 192.168.2.1 (proxy 192.168.1.1 to 10.10.10.3) has spi 2749108168 and conn_id 1 and flags 4IPSec(key_engine): got a queue event... IPSec(initialize_sas): , (key eng. msg.) dest= 192.168.1.1, src= 192.168.2.1, dest_proxy= 192.168.1.1/0.0.0.0/0/0 (type=1), src_proxy= 10.10.10.3/0.0.0.0/0/0 (type=1), protocol= ESP, transform= esp-3des esp-md5-hmac , lifedur= 0s and 0kb, spi= 0xd532efbd(3576885181), conn_id= 2, keysize= 0, flags= 0x4 IPSec(initialize_sas): , (key eng. msg.) src= 192.168.1.1, dest= 192.168.2.1, src_proxy= 192.168.1.1/0.0.0.0/0/0 (type=1), dest_proxy= 10.10.10.3/0.0.0.0/0/0 (type=1), protocol= ESP, transform= esp-3des esp-md5-hmac , lifedur= 0s and 0kb, spi= 0xa3dc0fc8(2749108168), conn_id= 1, keysize= 0, flags= 0x4 return status is IKMP_NO_ERROR Configuring PIX Firewalls for Scalable Virtual Private NetworksEarlier in this chapter, you learned about the different methods of negotiating an IPSec connection:
|