Example 4-27 Correcting the Peering Inconsistency in Example 4-15 and Example 4-16 and Creating a Mismatched IPsec Transform Set on Router_B
Router_B#conf t Enter configuration commands, one per line. End with CNTL/Z. Router_B(config)#crypto map pki4 10 Router_B(config-crypto-map)#no set peer 200.0.0.3 Router_B(config-crypto-map)#set peer 200.0.0.1 Router_B(config-crypto-map)#exit Router_B(config)#crypto IPsec transform-set pki4 esp-aes esp-md5-hmac Router_B(cfg-crypto-trans)#end Router_B#
As with IPsec peering inconsistencies, an IPsec transform set mismatch will not prevent the establishment of an ISAKMP SA. Indeed, the agreement of a transform to use occurs in Phase 2 negotiation—the negotiation of the IPsec SA. The routers in Figure 4-5 are now configured to use different transforms. Originally, Router_A and Router_B would use SHA1 Hash-based Message Authentication Code (HMAC) authentication in their transform sets. But, Router_B now uses the incorrect algorithm (MD-5 vs. SHA-1) to create the HMACs. As such, the routers are not able to agree on an IPsec proposal. As before, we will confirm this by debugging the IPsec crypto engine (debug crypto IPsec). The diagnostic output in Example 4-28 highlighted below confirms a mismatch in the IPsec transform causing a quick mode to fail to negotiate an IPsec SA.
Example 4-28 Diagnosing IPsec Proposal Inconsistencies—Identifying Mismatched IPsec Transform Sets
Router_A#
Feb 24 12:01:01.121: IPSEC(key_engine): request timer fired: count = 1,
(identity) local= 200.0.0.1, remote= 200.0.0.2,
local_proxy= 202.1.1.0/255.255.255.0/0/0 (type=4),
remote_proxy= 202.2.2.0/255.255.255.0/0/0 (type=4)
Feb 24 12:01:01.121: IPSEC(sa_request): ,
(key eng. msg.) OUTBOUND local= 200.0.0.1, remote= 200.0.0.2,
local_proxy= 202.1.1.0/255.255.255.0/0/0 (type=4),
remote_proxy= 202.2.2.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
lifedur= 5000s and 4608000kb,
spi= 0xEBD24B7A(3956427642), conn_id= 0, keysize= 128, flags= 0x400B
Router_B#
Feb 24 12:00:31.537: IPSEC(key_engine): got a queue event with 1 kei messages
Feb 24 12:00:31.705: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 200.0.0.2, remote= 200.0.0.1,
local_proxy= 202.2.2.0/255.255.255.0/0/0 (type=4),
remote_proxy= 202.1.1.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x42
Feb 24 12:00:31.705: Crypto mapdb : proxy_match
src addr : 202.2.2.0
dst addr : 202.1.1.0
protocol : 0
src port : 0
dst port : 0
Feb 24 12:00:31.705: IPSEC(validate_transform_proposal): transform proposal not supported for identity:
{esp-aes esp-sha-hmac }
Feb 24 12:00:31.705: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Quick mode failed with peer at 200.0.0.1
Crypto-Protected Address Space Issues (Crypto ACL Errors)
As we had mentioned during our IPsec overview in Chapter 2 and earlier in this chapter, crypto-protected address spaces between VPN endpoints must be consistent for an IPsec SA to be established. These crypto-protected address spaces are defined with ACLs, commonly referred to as crypto ACLs.
When crypto ACLs specify inconsistent scopes of addresses between two peers, the expected result is that ISAKMP SA negotiation will complete successfully, but IPsec SA negotiation will fail. We will now walk through several examples of acceptable and unacceptable crypto ACL definition, and then explore some methods for diagnosing crypto ACL definition problems using Cisco IOS IPsec debugging capabilities.
Note - The protected address and port ranges specified in crypto ACLs are commonly shown as "proxies" in the crypto debugging output in Cisco IOS and ASA IPsec VPN endpoints.
The first case we will discuss demonstrates a crypto ACL definition that will facilitate successful IPsec SA negotiation. However, the next three examples of crypto ACLs present inconsistencies in crypto-protected address spaces that will cause Phase 2 SA proposals to be rejected. Configurations illustrating a valid crypto ACL match for Router_A and Router_B are provided in Example 4-29.
Note - The crypto ACL's described in Cases 2 through 4 below will not preclude Phase 2 SA negotiation when TEDv3 is used. Although the ACL's are inconsistent, TEDv3 probes will dynamically discover consistent crypto-protected scopes and install the appropriate information in the IPsec SADB. The use of TED is discussed in greater detail in Chapter 12, "Solutions for Handling Dynamically Addressed Peers."
Example 4-29 Crypto ACL Match
Router_A#show access-list 101 Extended IP access list 101 10 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 Router_A# Router_B#show access-list 101 Extended IP access list 101 10 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 Router_B#
In Example 4-30, Router_B has an extra access-list entry (ACE) in the crypto ACL (ACE #20). However, ACE 10 is consistent between routers A and B. As such, traffic matching ACE 10 will facilitate successful Phase1 and 2 SA negotiations. Traffic matching ACE 20 on Router-B will initiate a Phase 2 SA proposal that will be rejected by Router_A, which has no corresponding ACE in its Crypto ACL for Router_B's ACE 20 in crypto ACL 101. The traffic matching ACE 20 will subsequently be dropped. Example 4-30 provides the configurations on Router_A and Router_B illustrating the missing crypto ACE on Router_A.
Example 4-30 Crypto ACL Mismatch Due to Missing ACE on Router_A
Router_A#sh access-list 101 Extended IP access list 101 10 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 Router_A# Router_B#sh access-list 101 Extended IP access list 101 10 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 20 permit ip 192.168.2.0 0.0.0.255 202.1.3.0 0.0.0.255 Router_B#
Example 4-31 provides a configuration in which the crypto ACLs on both Router_A and Router_B define scopes of protected address spaces that are inconsistent with the opposite peer's scope of protected source addresses. For example, Router_A protects traffic destined for any IP address that is sourced from 192.168.1.0/24. What would occur if traffic was sent from 192.168.1.1 to Router_A's physical IP address, 200.0.0.2? Router_A would encrypt the traffic as it matches ACE 10 in ACL 101. Router_B, however, would not encrypt the return traffic, as traffic sourced from 200.0.0.2 is not defined anywhere in its crypto ACL. For this reason, Phase 2 SA negotiation will fail when such an inconsistency is defined in the crypto ACL's of two IPsec peers.
Example 4-31 Crypto ACL Mismatch Due to Inconsistent Destination Address Ranges
Router_A#show access-list 101 Extended IP access list 101 10 permit ip 192.168.1.0 0.0.0.255 any Router_A# Router_B#show access-list 101 Extended IP access list 101 10 permit ip 192.168.2.0 0.0.0.255 any Router_B#
In the case provided in Example 4-32, the ACL defines a tighter scope of address space on Router_B's crypto ACL. As such, if Router_B initiates the Phase 2 exchange, then an IPsec SA will be established successfully in the SADB, and traffic will pass. However, if Router_A initiates the Phase 2 exchange, the IPsec SA proposal will be rejected by Router_B for the same reasons discussed in Example 4-31.
Example 4-32 Crypto ACL Mismatch Due to Inconsistent Destination Address Scope on Router_B
Router_A#sh access-list 101 Extended IP access list 101 10 permit ip 192.168.1.0 0.0.0.255 any (24 matches) Router_A# Router_B#sh access-list 101 Extended IP access list 101 10 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 Router_B#
Architectural and Design Issues with IPsec VPNs
Aside from issues related to configuring ISAKMP and IPsec policy, there is a variety of network elements that can interfere with optimal operation of an IPsec VPN if it is not managed correctly. In this section, we will discuss several of the most common troubleshooting challenges present IPsec VPN implementations today face. We will also discuss several effective techniques for diagnosing the problems that can result from improper design, and the appropriate solutions to remediate those problems.
Troubleshooting IPsec VPNs in Firewalled Environments
As we've discussed in our overview of the IPsec protocol in Chapter 2, many items need to be passed between two VPN endpoints in order to dynamically create tunnels securely using IKE and to successfully pass IPsec packets once a Phase 2 SA has been established. Most firewalls, by default, employ a "closed" model of security (by default, nothing is allowed) in which the firewall must be explicitly instructed to allow the required protocols through by an administrator. When deploying IPsec in firewalled environments, care must be taken to allow the required elements to securely pass, or problems could arise with VPN operation and performance. We will discuss two common issues in firewalled VPN environments—firewall fragmentation handling, filtering of required IPsec protocols, and filtering of Internet Control Message Protocol (ICMP) unreachables.
Allowing the Required IPsec Protocols to Pass
It is very common to see IPsec VPN sessions that traverse firewalls. One such example that we've discussed in Chapter 2 is in a DMZ design. Another popular application for such a design is in secure extranet designs. Most firewalls available in today's marketplace employ a closed policy by default, allowing no traffic to pass from low-security interfaces to interfaces assigned higher security levels. This includes protocols necessary for IPsec and IKE to operate effectively.
Unless manual IPsec session keys are used, firewalls between IPsec peers must allow ISAKMP traffic (UDP port 500) to pass between the IPsec VPN endpoints. Additionally, IPsec traffic must be allowed through the firewall, or encrypted traffic will get blocked at the firewall outside interface. These protocols include Encapsulating Security Payload (ESP) (IP Protocol 50) and Authentication Header (AH) (IP Protocol 51), depending on which of the two are included in the IPsec transforms used in that SA.
Note - Although IPsec transforms can include the ESP protocol, AH protocol, or both ESP and AH protocols together, it may not be necessary to open up firewall configurations to allow them both. Figure 4-6 assumes that all Remote Nets use ESP and AH. Administrators should verify the protocol selected in their IPsec transforms, as it may not be necessary to allow both ESP and AH through the firewall.
Figure 4-6 illustrates a firewalled IPsec VPN tunnel deployment in which tunnels are built from a central, firewalled aggregation site out to smaller remote locations.
IPsec VPN Traffic Through Firewalls
Example 4-33 provides the firewall ACL configuration that is employed to enable IPsec tunnels to be built between the Campus_Net and Remote_Nets A, B, and C in Figure 4-6.
Example 4-33 Firewall Configuration for Crypto Traffic in Figure 4-6
DMZ-PIX-MAIN(config)# show access-list 101 access-list 101; 9 elements access-list 101 line 1 permit udp host 160.1.0.2 host 201.1.1.1 eq isakmp access-list 101 line 2 permit udp host 160.1.0.2 eq isakmp host 201.1.1.1 access-list 101 line 3 permit esp host 160.1.0.2 host 201.1.1.1 access-list 101 line 3 permit ah host 160.1.0.2 host 201.1.1.1 access-list 101 line 4 permit udp host 160.1.0.6 host 201.1.1.1 eq isakmp access-list 101 line 5 permit udp host 160.1.0.6 eq isakmp host 201.1.1.1 access-list 101 line 6 permit esp host 160.1.0.6 host 201.1.1.1 access-list 101 line 3 permit ah host 160.1.0.2 host 201.1.1.1 access-list 101 line 7 permit udp host 160.1.0.10 host 201.1.1.1 eq isakmp access-list 101 line 8 permit udp host 160.1.0.10 eq isakmp host 201.1.1.1 access-list 101 line 9 permit esp host 160.1.0.10 host 201.1.1.1 access-list 101 line 3 permit ah host 160.1.0.2 host 201.1.1.1 DMZ-PIX-MAIN(config)# show access-group access-group 101 in interface outside
Firewall's Handling of Fragmented IPsec Packets
In addition to ensuring that the appropriate protocols are allowed to communicate through the firewall, it is critical that network designers should also account for the design considerations presented by the way that firewalls handle fragmented packets. When an IPsec packet is fragmented, the information relevant to the firewall's filtering decision, such as data found in the Layer 3 and 4 headers, is obscured in noninitial fragments.
Note - All fragments of a fragmented IPsec packet must be decrypted before they can be reassembled. This behavior can bypass the crypto hardware switching path, leading to performance degradation in IPsec networks. It is therefore critical to account for fragmentation issues in IPsec designs. We will discuss IPsec MTU and fragmentation issues and available solutions for fragment handling in IPsec networks (virtual fragmentation reassembly, IPsec prefragmentation, and path MTU discovery) later in this chapter.
As such, the firewall will potentially allow fragments to pass without inspection, as shown in Figure 4-7.
Firewall Fragment Handling in IPsec Networks
Cisco PIX firewalls by default are configured to detect when a fragmented packet has been received and to make filtering decisions on the initial fragment and all noninitial fragments without actually reassembling the packet. This feature is called Virtual Fragment Reassembly. Virtual Fragmentation Reassembly provides the firewall with the ability to make filtering decisions on fragments without having to decrypt each packet in the fragmented chain. Virtual Fragmentation Reassembly does indeed consume computational resources on the firewall, but does provide an ideal solution when filtering decisions must be made on noninitial IPsec packet fragments.