IPSec and NATNetwork Address Translation (NAT) is typically used to connect a private network such as a corporate network with private IP addresses to a public network such as the Internet. Because private addresses are not routable on the Internet, NAT replaces the private IP addresses with routable addresses in the public network. Keep in mind that to function, NAT doesn't just swap IP source and destination addresses, but it may also swap TCP source and destination ports, change the IP and TCP header checksums, change the TCP sequence and acknowledgment numbers, and change IP addresses contained in the data payload. NAT is supposed to be transparent to whatever applications it works with, but this assumption is not true when NAT is used in conjunction with IPSec. Next, you'll see how NAT affects IPSec protocols. Effect of NAT on AHYou may recall from Chapter 2, "IPSec Overview," that AH protects the entire IP packet, including invariant header fields such as the source and destination IP address, through a message digest algorithm to produce a keyed hash. The recipient uses the hash to authenticate the packet. If any field in the original IP packet is modified, authentication will fail and the recipient will discard the packet. AH is intended to prevent unauthorized modification, source spoofing, and man-in-the-middle attacks. But NAT, by definition, modifies IP packets. Therefore, NAT on AH does not work. Effect of NAT on ESPLike AH, ESP also employs a message digest algorithm for packet authentication. But unlike AH, the hash created by ESP does not include the outer packet IP header fields. This solves one problem, but leaves other problems with ESP. When TCP or UDP are involved, as they are in transport mode ESP, there are two caveats for ESP and NAT to work together. First, because NAT modifies the TCP packet, NAT must also recalculate the checksum used to verify integrity. On the other hand, ESP authentication will fail if NAT updates the TCP checksum. If NAT does not update the checksum (for example, if the payload is encrypted), TCP verification will fail. In tunnel mode, however, ESP has no issues with NAT. In this mode, the original IP address and transport information is included as payload. So, NAT and ESP can work together in tunnel mode when the NAT translation is 1:1 on addresses with no multiplexing of inside addresses to a single outside address using the transport layer port for differentiation. Effect of NAT on IKEIKE has problems when NAT devices transparently modify outgoing packets. The first issue is that some devices might depend on IKE negotiation being made by incoming packets sent from UDP port 500. If a NAT device is introduced, the final packet port will, most surely, not be the expected port; therefore, IKE negotiation will not even begin. Another issue comes about when IKE includes IP addresses as part of the authentication process, which depends on which IKE mode is used. If the authentication is based on the IP address, the changes made by a NAT device will cause IKE negotiation to fail. IPSec and NAT SolutionsThe easiest way to get around IPSec issues with NAT is to avoid the problem by performing NAT before IPSec, but this is not always possible. In this section, you will examine other options for tackling IPSec issues with NAT. NAT Traversal (NAT-T)The IPSec NAT Traversal (NAT-T) feature introduces support for IPSec traffic to travel through NAT points in the network. There are three parts to NAT Traversal. The first is to determine if the remote peer supports NAT Traversal. The second is to detect the presence of a NAT function along the path between the peers. The third is to determine how to deal with NAT using UDP encapsulation. The ability of a peer to support NAT-T and detection of NAT along the path is performed as part of the IKE phase 1 negotiation process. NAT-T capability exchange is done in the first two messages of the IKE phase 1 exchange with the addition of a new vendor identification (ID) payload. Both peers need to exchange the ID for the NAT-T support between the peers. Once the NAT-T capability is successfully exchanged, the detection of NAT along the path is accomplished. To detect whether a NAT device exists along the network path, the peers send a payload with hashes of the IP address and port of both the source and destination address from each end. If both ends calculate the hashes and the hashes match, each peer knows that a NAT device does not exist on the network path between them. If the hashes do not match (that is, if the address or port have been translated), then each peer needs to perform NAT Traversal to get the IPSec packet through the network. The hashes are sent as a series of NAT-D payloads. Each payload contains one hash. If multiple hashes exist, multiple NAT-D payloads are sent. In most environments, there are only two NAT-D payloadsone for the source address and port and one for the destination address and port. The destination NAT-D payload is sent first, followed by the source NAT-D payload, which implies that the receiver should expect to process the local NAT-D payload first and the remote NAT-D payload second. The NAT-D payloads are included in the third and fourth messages in Main Mode and in the second and third messages in Aggressive Mode. Once the responder sends the NAT-D payload, the initiator must change ports when sending the ID payload if there is NAT between the hosts. The initiator must set both UDP source and destination ports to 4500. All subsequent packets sent to this peer must be sent on port 4500. The changing of the port by IKE is called floating IKE. Figure 3-11 shows the IKE phase 1 exchange using pre-shared keys and NAT-T. Figure 3-11. IKE Phase 1 Key Exchange Using Pre-shared Keys and NATSimilarly, if the responder needs to rekey the phase 1 SA, then it must start the negotiation using UDP (4500,Y). Any implementation that supports NAT traversal must support negotiations that begin on port 4500. If a negotiation starts on 4500, then it doesn't need to change anywhere else in the exchange. After IKE phase 1 is complete, both peers know if there is NAT between them. The final decision of using the NAT-T is left to IKE phase 2 (that is, Quick Mode). The use of NAT-T is negotiated inside the SA payloads of Quick Mode. In Quick Mode, both ends can also send the original addresses of the IPSec packets (in case of the transport mode) to the other end such that the other end has the possibility to fix the TCP/IP checksum field after NAT. Let's now look at the packet format of an actual data packet once IKE and IPSec SAs have been negotiated between the peers using UDP encapsulation. Shown in Figure 3-12 is an UDP-encapsulated ESP packet in tunnel mode. Figure 3-12. UDP-encapsulated ESP Packet in Tunnel ModeChapter 2, "IPSec Overview." After ESP, the UDP header is inserted and the total length, protocol, and header checksum is recalculated in the new IP outer header. At the decryption end, the UDP header is first removed from the packet and the total length, protocol, and header checksum field is edited to match the new resulting IP packet and processed for decryption. One more thing worth mentioning is that most NAT devices expire the translation after an idle period of time. To ensure that the translations do not expire, NAT keepalive messages are sent between the peers with a payload that resembles the one shown in Figure 3-13. Figure 3-13. NAT Keepalive PacketThe only field that is different here compared to the other UDP-encapsulated packets is the checksum field. The sender should use a one-octet long payload with the value 0xFF. The receiver should ignore a received NAT keepalive packet. A topology with a NAT device in front of SPOKE-1-EAST is shown in Figure 3-14. Example 3-12 shows the configuration and debugs for SPOKE-1-EAST doing NAT-T negotiation. Peers that run IOS code that support NAT-T automatically exchange this capability. The CLI to control the NAT keepalive timer to disable NAT-T is also indicated in Example 3-12. Figure 3-14. NAT Device Introduced in the Topology[View full size image] Example 3-12. NAT Keepalive Configuration in IOS
Note IPSec over TCP encapsulation is also supported on the VPN 3000 Concentrator to pass through NAT devices. The reason is most firewalls allow TCP ports. IPSec Pass-throughThis section deals with another method for resolving IPSec and NAT incompatibilities. This method, however, applies only to ESP-based IPSec traffic. The feature, IPSec pass-through, supports IKE and ESP (IP protocol 50) only in tunnel mode through an IOS PAT box. AH or ESP in transport mode are not supported. With ESP, we know that the IP header is not authenticated, so NAT can change the IP addresses. In case of AH, authentication includes the IP header of the packet as seen in Chapter 2, "IPSec Overview. There is no way to perform address translation on a packet using NAT and recover it. NAT will change the source address, destination address, or port; therefore, authentication will fail at the remote peer. The same reason holds true for ESP in transport mode. There are two issues to be considered hereone is IKE and the other is ESP in tunnel mode. We will again refer to Figure 3-13 to explain these issues. IKE Passing Through PATIKE uses UDP port 500. If there is just one device behind the NAT/PAT box, then there is nothing that needs to be done by the PAT gateway, as the IKE flow will pass unmodified as standard UDP traffic. When there is more than one IPSec device behind the PAT gateway, a unique delimiter is required to identify the IKE session for each of the IPSec endpoints. The delimiter used is the initiator cookie that is part of IKE header. ESP Passing Through PATIn the case of ESP, PAT needs to use some other field in the packet to multiplex. The only field that is accessible to PAT and is unique is the security parameter index (SPI) that is part of the ESP header. The same principles apply if there is just one IPSec endpoint passing through the PAT gateway. The SPI of the endpoint can be used to map to the translation. The problem arises when more than one IPSec endpoint exists behind the PAT gateway and they all establish connections to the same remote peer. The IPSec SA is unidirectional. When the packets return from the remote peer, it will have a different SPI. The PAT gateway sitting in the middle has no way to associate inbound and outbound SPIs and decide that they belong to same ESP connection of one IPSec endpoint. Next, you examine one of the most commonly used methods to overcome this problem. Restricted ESP Through PAT ModeThe first method, referred to as the restricted method, allows PAT to serially establish translation tables on ESP traffic initiated from inside IPSec endpoints to an outside IPSec endpoint. Once the outside endpoint starts replying, PAT assumes the packets are associated with the only outstanding IPSec session allowed to go, and "binds" the two SPIs in the translation. From this moment on, the next inside IPSec endpoint is allowed to send ESP traffic and establish its unique translation map, and so on. Refer to the topology shown in Figure 3-14, which explains the workings of restricted ESP. The NAT translation on INTERNET-PAT-ROUTER is shown in Example 3-13. You can see that the there is both in and out mapping of the translation along with SPIs. Example 3-13. NAT/PAT Translation with ESP
From this point on, all ESP traffic between 9.1.1.146 and 9.1.1.35 using SPI1 and SPI2 uses these translations. If the endpoints decide to change SPI values, essentially a new ESP translation must be established. The one critical restriction with this approach is that PAT must first see the in-to-out connection requesting a new SPI in order to create the in-to-out translation capable of mapping the returning out-to-in reply packets. Example 3-14 shows the configuration that is needed on the PAT box to allow ESP in a restricted way. You can see that the SPIs from the NAT translation on the NAT-ROUTER match the inbound and outbound SPIs of IPSec SAs created between VPN-GW1-EAST and SPOKE-1-EAST. Example 3-14. PAT Configuration to Allow ESP
|
لطفا منتظر باشید ...
