Figure 4-7 demonstrates the improved handling of fragmented packets in IPsec networks. In the case illustrated in Figure 4-7 above, packets are being fragmented at an intermediary point between the two IPsec VPN gateways, ISP_GW_A and ENT_DMZ_IN. The DMZ firewall, ENT_FW, receives the fragments, and is configured for virtual fragmentation reassembly. The firewall therefore does not do any reassembly. Instead, it will initially allow only the first fragment in the fragment chain through without being inspected. Virtual Fragment Reassembly enables the firewall to inspect the remaining fragments of the original packet without reassembling the packet. Virtual Fragmentation Reassembly therefore plays a vital role in this example, as the firewall would have to decrypt each fragment in the chain in order to reassemble the packet, which it is not configured to do.
Filtering of ICMP Unreachables
ICMP unreachables are commonly used by hackers to find and exploit network vulnerabilities, and are a fundamental component of scanning techniques used to find openings in firewalled environments. As such, it is very common that firewalls not reply to filtered messages with ICMP unreachables. This behavior breaks a fundamental tool that IPsec can use to avoid the performance problems that can arise from fragmenting packets after encryption—Path MTU Detection (PMTUD).
As discussed in greater detail later in this chapter, PMTUD sends ICMP messages along the path, relying on information in ICMP unreachable messages to throttle down the MTU that the PMTUD device must fragment to before encrypting with IPsec. The insertion of a firewall along the PMTUD path effectively breaks this model, because it will suppress the response of the ICMP unreachable that is to carry MTU sizing information back to the fragmenting PMTUD device.
NAT Issues in IPsec VPN Designs
NAT was introduced to solve problems with the depletion of publicly available address space. It does this by translating the private source or destination IP addresses into public ones. As we had discussed previously in Chapter 2, "IPsec Fundamentals," IPsec was designed, in part, to prevent the manipulation of data while in transit between the two endpoints of the IPsec VPN tunnel. Considering that IPsec in tunnel mode protects the IP header from manipulation, incompatibilities arise when a device attempts to perform NAT on an IPsec packet protected in tunnel mode. This section will cover some intrinsic incompatibilities between the two technologies and explore some solutions for deploying them in tandem.
Intrinsic IPsec/NAT Incompatibilities
Deployment of IPsec VPNs in NAT environments should be approached with care, as there are many known incompatibilities between NAT and IPsec. The nature of NAT is to modify, or translate, a portion of the IP packet, specifically the source and destination addresses or ports, when the packet is en route from a given source to a given destination. The nature of IPsec is to detect and prevent the malicious manipulation of packets between a given source and destination. Therein lies the origin of IPsec/NAT incompatibilities—the nature of NAT is to manipulate a packet, while the nature of IPsec is to preserve the packet's integrity.
Recall from our discussion in Chapter 2 that IPsec defines a suite of protocols, such as AH and ESP, that can operate in different modes, such as tunnel or transport, and include varying degrees of authentication, or strengths in optional HMACs within a given transform. Because each protocol protects different portions of the IP packet in different ways, the effect of NAT can vary on a per-protocol basis. Some of the protocol-specific examples of inherent IPsec/NAT incompatibility include:
IPsec AH Keyed Message Integrity Check (MIC) Failures in NAT Environments
Inbound IPsec SA Selector Inconsistencies in NAT Environments
IKE Rekeying Failures in PAT Environments
Overlapping IPsec Security Policy Database Entries
IPsec Security Parameter Index Conflicts on NAT Devices
Embedded IP Address Translation Limitations
Unidirectional NAT Support
TCP and User Datagram Protocol (UDP) Checksum Failures
IPsec AH Keyed MIC Failures in NAT Environments
Authentication Header protocol includes source and destination addresses in the keyed MIC in order to provide a greater scope of authentication and integrity than the ESP protocol. Manipulating the source/destination address of the packet between VPN endpoints using AH will cause a MIC failure at the receiving VPN endpoint. ESP does not have this specific incompatibility, as source and destination information is not included in the integrity check.
Inbound IPsec SA Selector Inconsistencies in NAT Environments
If IKE authenticates Phase 2 selectors, and the initiator's source address is translated en route to the responder, then RFC 2401 requires that the responder drop the decapsulated packet, as the translated IP address does not match the SA selector value.
IKE Rekeying Failures in PAT Environments
An IKE responder must respond to IKE requests on the correct port. In nonPAT environments, this is UDP 500 by default. However, in situations in which IKE initiators have their ports translated to something other than 500, the IKE responder must be able to respond to the IKE request on the translated port, and must be able to do so predictably and reliably for IKE rekey messages to reach their correct destinations (correct IKE initiators).
Overlapping IPsec Security Policy Database Entries
When two or more IPsec initiators use their source address as its Phase 2 identifiers, an IPsec responder could view the two sources as identical. The responder could, therefore, potentially install overlapping security policy database entries for multiple sources. As a result, the responder is at risk of forwarding traffic over the incorrect SAs to its sources. The creation of overlapping security policy database entries in an IPsec responder resulting from duplicate NAT inside local addresses used as Phase 2 SA identifiers is illustrated in Figure 4-8.
SPD Confusion in NAT Environments
IPsec Security Parameter Index Conflicts on NAT Devices
When two initiators attempt to negotiate a Phase 2 SA with the same destination, and Security Parameter Index (SPI)-based NAT is occurring between source and destination, SPI conflicts can sometimes occur on that NAT device leading to forwarding confusion from responder to initiator. Consider the scenario in Figure 4-9. The responder will install two different SPI entries (i.e., 2001 and 2002). However, because inbound and outbound SPI creation occurs independently of one another, the two initiators could indeed install similar SPI entries (i.e., both would claim to have installed SPI 2000 for the same destination). Because traffic from both Router_A and Router_B use the same UDP source port information, the NAT devices use overlapping SPIs for forwarding decisions. As a result, the traffic from the responder could be forwarded to the incorrect initiator due to the SPI conflict in the NAT device (i.e., the NAT device does not know which initiator to forward SPI 2000 traffic to).
SPI Overlap in NAT Device
Embedded IP Address Translation Limitations
Some applications have addressing information embedded in to the payload of the IP packet. In both ESP and AH protocols, the payload of the packet is integrity protected. Therefore, changes to that payload, such as those NAT would attempt to execute, are not possible within the ESP and AH encapsulated payloads.
Unidirectional NAT Support
In some cases, a NAT device will install an NAT/PAT entry only once a packet is received from a given interface (i.e., inside to outside). Once that entry is installed on the NAT device, traffic can be forwarded in both directions. However, until that entry is installed, traffic received in other directions (i.e., outside to inside) will not get forwarded, as a NAT/PAT entry will not be dynamically created for traffic received on that interface.
TCP and UDP Checksum Failures
TCP and UDP checksums include IP source and destination addresses as part of the calculation. Therefore, translating the source or destination address with NAT can cause these checksum calculations after NAT processing. This problem arises in IPsec and NAT environments where TCP and UDP checksums are calculated and verified. This specific incompatibility does not affect IPsec in tunnel mode or IPsec+GRE, as neither of these methods requires validation of UDP/TCP checksums that use a translated source and destination IP address in their calculations.
IPsec NAT Transparency (NAT-T)
IPsec NAT-T enables an IPsec VPN endpoint to dynamically detect the support for NAT-T on its remote endpoint and to detect the presence of NAT devices between the two endpoints. If NAT is detected through the use of NAT-T, then the two endpoints will dynamically agree on the appropriate handling of IPsec NAT-T packets (such as UDP encapsulation of ESP packets, and so on). NAT-T, therefore, enables the two VPN endpoints to seamlessly establish an IPsec VPN endpoint across one or more NAT points that may exist between the two endpoints.
Consider the example described in Figure 4-10 in which two routers, Router_A and Router_B, communicate with one another through a firewall, Ent_FW.
The Operation of IPsec NAT-T
Routers A and B are both capable of NAT-T, and dynamically agree on the handling of IPsec packets across the NAT'd path through the following sequence of exchanges:
Router_A sends its vendor ID to Router_B during IKE Phase 1 negotiation. This phase of NAT-T is commonly referred to as a "NAT Support" exchange.
Router_B sends its vendor ID string payload to Router_A during IKE Main Mode (MM1 and MM2, Phase 1) negotiation, letting Router_A know that it does indeed support NAT-T. This is also known as a "NAT Support" exchange in NAT-T context.
After Routers A and B have agreed on NAT-T Support, they must determine if NAT exists between the two of them. This phase is commonly referred to as "NAT Detect." In this phase of NAT-T, multiple NAT-D payloads are exchanged between source and destination. NAT-D payload consists of an address and a hash. Each peer typically sends two NAT-D payloads to the other in main mode (MM3 and MM4)—one for the destination address followed by another for the source address. When NAT-D payloads are sent between each peer, the hashes are verified at the remote end. If the hash values match, then it can safely be determined that NAT does not exist. If the hash values do not match, then it can safely be determined that NAT does exist.
After NAT-D payloads are exchanged to detect NAT information, IPsec Quick Mode messages are exchanged to decide which peer (none, either, or both) will use NAT-T. This negotiation is performed during IKE Phase 2 in Quick Mode (QM1 and QM2).
In Figure 4-10, inside source address translation is being performed by the PIX. IPsec endpoints have determined this behavior using NAT-T steps 1-4 described above. In this case, Routers A and B will both encapsulate ESP packets in UDP, hereby remedying three incompatibilities with IPsec and NAT:
Incompatibility between ESP and AH with PAT
Incompatibility between IKE fixed ports and PAT
Incompatibility between UDP checksums and NAT (intermediate NAT-T UDP header checksum set to 0)
Note - As noted above, Cisco IOS will attempt NAT-T during IKE Phase 1 negotiation. Cisco IOS configures NAT-T automatically, and there is no manual configuration required. To disable the encapsulation of ESP packets in UDP using NAT-T, execute the following command from the IOS CLI:
Router_A(config)#no crypto IPsec nat-transparency udp-encapsulation
SPI-Based NAT
IPsec SPIs provide another element that a NAT device can use to forward data between two endpoints. When IPsec traffic is passed through a NAT device, various crypto-protected elements are often translated by NAT, including source IP addresses, destination IP addresses, source ports, and destination ports. Another field that can be use to populate the translation table in a NAT device is the IPsec SPI. As we had discussed previously, though, IPsec and NAT incompatibilities arise when overlapping IPsec tunnels with overlapping SPIs are passed through the NAT device.
Cisco IOS releases 12.2T and later employ a predictive SPI selection algorithm on IPsec crypto endpoints that enable them to select unique SPIs during IKE. This effectively enables a NAT device in the crypto path to use IPsec SPIs to build its translation table without encountering the translation and forwarding issues caused by overlapping SPIs discussed earlier in this chapter.
Consider again the scenario in Figure 4-9, but with predictively selected SPIs and SPI matching enabled on the NAT device. The NAT device is now capable of differentiating between multiple initiators (sources) in its forwarding table without the use of PAT. Instead, SPI matching is used to differentiate between the two IPsec VPN tunnel initiators, Routers A and B.
The Influence of IPsec on Traffic Flows Requiring QoS
As networking technologies begin to mature and become more widespread, time- and delay-sensitive applications are increasingly migrating toward a converged solution. Many of these applications are considered critical to the needs of businesses in different vertical markets. As such, a need for guaranteed timely delivery and ordering of these applications emerges. In today's networked environment, a variety of QoS mechanisms exist to guarantee the timely delivery of delay-sensitive business critical data communications in IP networks. QoS in and of itself is so broad and deep in scope that we cannot cover it in its entirety. We will, however, discuss several common inconsistencies between IPsec and QoS that present design challenges: