Date: Fri, 13 Oct 2000 09:46:00 -0500 From: Jim Gray <jim.gray@motorola.com> To: freebsd-questions@FreeBSD.ORG Subject: NAT and IPsec MVP Message-ID: <39E72027.E5D8A374@motorola.com>
next in thread | raw e-mail | index | archive | help
Hello, First, many thanks for FreeBSD and the great online support! I have used an old 386 box with FreeBSD to connect my home network to dial up ISP and have now built a second box with two NIC cards running FreeBSD 4.0 in anticipation of cable modem sevice comming up. I rebuilt the kernal and got NAT and DIVERT running with the OPEN option in the rc.firewall template provided. I tested it end to end using an addonics web sharing box as the DHCP host. Everything was working fine until my employer announced they were changing the Virtual Private Network software we have to use to a version that uses "IPsec". Now I cannot tunnel into my corporate anymore(WWW access is ok). I have appended their PROPOSED SOLUTION below, as well as a white paper describing NAT problems with IPsec protocol. My first and simplest question is: How do I implement the ESP protocol and UDP port protocols suggested in the PROPOSED SOLUTION(below) in the firewall rules? I think the UDP rules should be: $(fwcmd) add pass udp from any to 500 $(fwcmd) add pass udp from 500 to any is this correct? The IP ESP protocol has no ports associated with it so I am clueless. Any suggestions? My second question is: Do you think this plus the designated subnet(below) will fix the NAT problem? Thanks in advance for any help. Best Regards, Jim Gray *************************************** **********PROPOSED SOLUTION: Answer: Users with cable, ISDN or DSL access to the Internet and have a small home network connected with a generic firewall sitting between network and Internet, will have to open following protocols on the firewall. IP protocol 50(ESP) to/from any UDP port 500(IKE ) to/from any The Home LAN solution The Home LAN solution was developed to accommodate users who have a network set up at home. In the past, users could not access the resourceson their home network, such as printers, while they were using MVP. This created problems for users who wanted to print to their local network printer, for example. By reserving a specific subnet, we were able to solve this problem. With split tunneling technologies, users are now able to access the intranet and the Internet through MVP as well as local resources on their home network. How do I set it up? First, you must have a device that handles smart NAT (Network Address Translation). An example of such a device is the LinkSys Cable/DSL Router. You can get more information on the LinkSys Cable/DSL Router and similar devices on the Remote Access - Personal Firewalls web page. Next, you must set up your home LAN with the appropriate subnet. The following subnet is reserved for the Home LAN solution: 192.168.128.x You must make sure that your LinkSys Cable/DSL Router or other such device is configured appropriately with the reserved subnet. Make sure that all of the other devices in your home LAN have IP addresses in this reserved subnet as well. ******************************************** *************PROVIDED WHITE PAPER: Question: How do I get MVP 4.0 to work with NAT? Answer: The Obstacles for NAT with IPsec By Kate Pence Network Address Translation (NAT) was originally implemented to circumvent the problem with IPV4 of running out of address space, but it has also become a solution for network designers that do not want to incur the costs associated with purchasing registered addresses. There are several issues with using Many-to-One NAT with IPsec, which utilizes either ESP or AH protocols. This paper will discuss the most common implementation of Many-to-One NAT, and the issues surrounding its use with IPsec. The scope of this document is limited to IPsec as implemented between the Contivity Extranet Switch and its Extranet Access Clients. Branch office support behind a NAT device is not discussed or recommended. Many-to-One NAT, as its name implies, associates many addresses on a private network with one address on the NAT device’s public interface. Typically a NAT device has at least two interfaces. One has an Internet assigned address, the other has a private address. Usually, the private address is from one of the pools set aside for private use, for example 10.x.x.x. There are Network Address Translators that allow static mapping of IP addresses so that each private address maps to a unique public address. The issues with One-to-One NAT are out of the scope of this document. The NAT device will receive a request from a client and map the client’s source port to one of its own and modify the packet to use its own public address and its own source (see Figures 1 and 2). The NAT device will then forward the packet to the destination device. The destination device will respond to the destination port and address of the NAT device. When the NAT device receives the response it will look in its table to see which IP address and port combination matches the destination port in its Network Address Translation table. It will then modify the packet with the appropriate destination IP address and port and ship the packet off to the client. There is no RFC on how Many-to-One must be implemented, but the above description is the most common implementation. Some protocols will not function across a NAT device and in some instances, FTP for example, Application Layer Gateway functionality is added to the NAT device to account for them [REK98]. Unfortunately at this time, there is no ALG that will handle the IPsec issues. The difficulty in building an ALG for IPsec on a box external to the IPsec peers, lies in the fact that it would have to modify data which is encrypted or otherwise protected by the dynamically-generated keys which are kept (and must be kept) as a secret between the IPsec peers. The Contivity Extranet Switch can be configured to use either AH or ESP encapsulation. ESP allows for encryption, authentication, and integrity, whereas AH is used for authentication and integrity only. AH does not lend itself to NAT because it was designed as an end-to-end protocol. "The IP Authentication Header seeks to provide security by adding authentication information to an IP datagram. This authentication information is calculated using all of the fields in the IP datagram (including not only the IP Header but also other headers and the user data) which do not change in transit." [ATK95] "So when NAT does what it is supposed to do by altering the address information in the header of the packet, the destination host receives the altered packet and begins digesting the AH message. The AH routines at this host will invalidate the packet since the contents of the headers have been altered [HS98]." AH will not work through any type of device that alters the address including One-to-One NAT. See Figures 3 and 4 for AH packet information. Figure 3 BEFORE APPLYING AH ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING AH --------------------------------- IPv4 |orig IP hdr | | | | |(any options)| AH | TCP | Data | --------------------------------- |<------- authenticated ------->| except for mutable fields Figure 4 Authentication Header Format: [KA98c] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication Data (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When selecting DES or 3-DES encryption on the CES, ESP (protocol 50) is used. Making an IPsec connection to the CES using DES or 3-DES encryption is a two step process. The security association is made using ISAKMP/Oakley Key Negotiation. The issue with NAT and ISAKMP is that it requires that both the source and destination be UDP port 500. Most Many-to-One NAT implementations map one of the dynamic user ports of the NAT device to the client’s source port. Some NAT implementations will allow static mapping of ports, and some use the client’s source port when possible. In instances where the NAT maps its own source port 500 to the client’s source port, one client will be able to authenticate through ISAKMP. If the first client is able to connect, then the problem will arise when there is more than one client making requests. The NAT device only has one port 500, so the second request would most likely get mapped to a different port. The CES’ Public Interface filters out UDP packets that do not have a source port of 500. If the request came in on the Private Interface of the CES, which does not have as many filter restrictions, the CES would respond back to the NAT’s port 500, which would undoubtedly confuse a NAT device not equipped to handle ISAKMP traffic. If the NAT vendor wants to support IPsec then they will need to develop a method to handle the multiple clients requesting the use of UDP port 500. Note: The Contivity Extranet Switch does not imbed any IP addresses requiring translation in the ISAKMP packets for Extranet Access Clients, but some implementations of ISAKMP do imbed IP addresses that may require translation and this would be a further obstacle for NAT that may not be circumventable. The second piece of the IPsec connection is the protocol 50 (ESP) traffic that handles the encrypted/encapsulated packets. See Figure 5 for ESP packet information. Protocol 50 has no ports associated with it, again causing problems for the NAT device. The NAT implementation would need to somehow be aware of the security associations so that it could map the outbound SA to the inbound SA for a specific IP address. Since the packets are encrypted this becomes a little trickier. However, each SA has an SPI associated with it, so if the NAT can implement some way to keep track of the SPI’s and determine a valid amount of time to keep them active then theoretically, a NAT device could handle IPsec traffic. Figure 5 [KA98b] BEFORE APPLYING ESP ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING ESP ------------------------------------------------- IPv4 |orig IP hdr | ESP | | | ESP | ESP| |(any options)| Hdr | TCP | Data | Trailer |Auth| ------------------------------------------------- |<----- encrypted ---->| |<------ authenticated ----->| The Nortel Networks’ Instant Internet and Nautica 200 products have implemented a method of Many-to-One NAT that allows for Extranet Access Clients to communicate with the Contivity Extranet Switch. There are some restrictions in the design that require only one connection to be initiated at a time. Several connections can exist at a time, but they must be initiated independently. REFERENCES [ATK95] R. Atkinson, "IP Authentication Header," RFC 1826, August 1995. [EF94] K. Egevang, P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994. [HAI98] T. Hain, "Architectural Implications of NAT", Internet Draft, July 1998. [HS98] Matt Holdrege, Pyda Srisuresh, "IP Network Address Translator (NAT) Protocol Issues", Internet Draft, August 1998. [KA98a] Steve Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft, July 1998. [KA98b] Steve Kent, Randall Atkinson, "IP Encapsulating Security Payload (ESP)", Internet Draft, July 1998. [KA98c] Steve Kent, Randall Atkinson, "IP Authentication Header", Internet Draft, July 1998. [REK98] Yakov Rekhter, "Implications of NAT’s on the TCP/IP architecture", Internet Draft, August 1998. [SH98] P. Srisuresh, Matt Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", Internet Draft, July 1998. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39E72027.E5D8A374>