NAT Incompatibilities

By David Phillips

June 4, 2009

            Network Address Translation (NAT) enabled devices typically reside on the outside of a private network.  A very commonly used NAT device is a router which is assigned an Internet Protocol (IP) address in the public address space and is able to assign private IP addresses to other computers that it is servicing.

            The IP addresses that are issued by the router only have meaning to that specific router and are therefore considered “non-routable” by other routers on any outside network.  Computers that are outside of the network must send their data to the router if they want to communicate with machines that are behind the router.  The router must inspect the packets sent from the outside network and forward the data to the intended machine.  The router maintains an table of addresses and ports that it uses to map traffic back and forth from the global router address to the computers behind the router.

Consider the following very simple private network:

If the outside host wants to send a data packet to Host A, it cannot simply construct a packet with destination address 127.0.0.2 because the internet routers do not know who host 127.0.0.2 is.  Instead, the outside host must send a data packet with the address of the router (62.189.43.12) and assume that the router will forward the packet to Host A. 

The router maintains a table of address/port mappings that it uses route packets to the private machines.  The table is typically configured on the fly as private hosts initiate communication sessions with outside hosts.  For example, Host A will send a data packet to the router with destination address 62.189.43.12 and source address 127.0.0.2.  The router notes the source address, destination address, destination port, and source port in the data packet and saves them in its translation table.  The router then re-writes the packet’s source address with its public IP (62.189.43.12) address.  The router also re-writes the source port with the index of the translation table that contains the mapping information.  The router then forwards the modified packet to host A.  Host A can then send a packet back to the router using the return address (62.189.43.12) and port.  The router will look up the entry in its table that corresponds to the destination port and address and re-write the packet’s destination port and address with the values that it saved from before (127.0.0.2).  The packet can then be forwarded back to Host A.

As demonstrated in the previous example, the communication workflow is one-directional where the packet flow must always begin from a private host behind the firewall.  Consider the scenario where the router has been powered on and its table of mappings is empty and the outside host wants to send a packet to Host A.  Suppose that the outside host knows that Host A is behind the router so it goes ahead and sends a data packet to the router with destination address 62.189.43.12.  The packet arrives at the router, but since the address translation table is empty, the router cannot determine which machine the packet needs to be forwarded to and therefore drops the packet.  The table will not be updated until Host A first sends a packet to the outside host.

Due to the previously described one-way oriented initiation from the inside-out-style architecture, NAT causes incompatibility problems with internet protocols that require hosts to be able to accept “unsolicited” traffic.  An example protocols that have compatibility problems with NAT are Voice Over IP (VoIP) protocols.  Suppose that you had a phone that was behind a firewall which would block all incoming calls to your phone until you called them first.  Clearly, such a protocol would not work as the phone must be able to accept communications from sources that it does not initially solicit first.  An example is the Session Initiation Protocol (SIP) which is used in Internet Telephony that requires end-to-end hosts to be able to accept unsolicited traffic.

The Universal Plug and Play (UPnP) solution proposed by Microsoft attempts to allow services or devices running behind the router to advertise their presence to the router.  For example, suppose Host A is running a VoIP application that is UPnP compatible.  The application will broadcast its service to the network which will be seen by the UPnP compatible NAT-enabled router which will then make the necessary entries in its internal tables to allow outside hosts to call in unsolicited and be routed successfully.  This solution requires that the router and the services all implement the UPnP protocol and it also requires the router to implement a back-door in its firewall rules to allow the UPnP communication which is considered to be a potential security hole and therefore not allowed by institutions with strict security policies.

The Simple Traversal of User Datagram Protocol through Network Address Translators (NATs) (abbreviated STUN) protocol defines a special “STUN server” that is available on the internet that accepts special requests from STUN-enabled applications so that they can determine at runtime which IP address and port number are being assigned by the NAT device on their network.  For example, a phone or instant messaging application running on Host A behind the NAT router will send a message to the well-known STUN server on the internet.  The STUN server will extract the source IP address and port from the received message and send them back to the application.  The application will examine the returned IP address and port to determine the type of NAT that is being used by the network.  The application can then use its knowledge of the NAT structure to resolve any end-to-end processing incompatibilities arising from unroutable addresses inserted into the packets.  The problem with STUN is that it does not support TCP communication and it does not work with Symmetric NAT architectures because the information sent back by the STUN server will not be usable by hosts with different IP addresses.  It also does not scale well and is typically used as a temporary solution.

Security protocols such as IPSec encounter NAT compatibility issues as well due to the NAT router’s modification of the packets in transit which breaks the end-to-end authentication processing.  For example, before sending a packet to a remote host, the originating host will compute a Hashed Message Authentication Code (HMAC) for the packet and send it with the original packet to the host.  The HMAC is computed using a shared key that only the two end-point hosts have knowledge of.  The HMAC calculation produces a hash over multiple fields in the original packet, including the source and destination addresses.  If these fields are modified by a NAT router while in-transit, then the corresponding HMAC will become invalidated as the packet arrives at the destination, the receiver will re-compute the HMAC for the arriving packet and compare it to the HMAC that was sent by the source.  If a NAT device modified any of the addresses in the packet header then the receiver will calculate a different HMAC than was sent by the original source of the packet and the packet will be dropped.

Manual configuration of the NAT device can also be used to pre-configure a NAT device with static mappings to allow a private machine to accept unsolicited traffic from the outside network.  For example, a computer can be placed into an organization’s “DMZ” where the router will forward all incoming packets on a pre-specified port to the target machine.  This requires that the private machine be issued a static IP address and that the administrator of the network to manually configure the router to map incoming traffic to the specified machine.  Typically this solution is only used in small networks and requires that the user possess skill in router configuration.

The IPSec compatibility problem can be solved using packet tunneling techniques where the original packet is encapsulated within another packet which is forwarded between routers along a tunnel.  At the final end-point, the original packet is extracted and pushed up to the application layer, unmodified.  Using this technique, since the original packet is encapsulated within the payload of another packet, NAT routers are free to modify the outer packet’s fields without potentially breaking any end-point communication.  For example, the sending host would calculate the HMAC of the outgoing packet and embed it into the packet.  The sending host would then construct a new packet and insert the authenticated packet into the new packet’s payload.  Since no HMAC was computed for outer packet, intermediate NAT routers can modify the packet without potentially breaking the end-to-end processing as the receiver will extract the authenticated packet from the arriving packet’s payload and re-compute the HMAC which will result in a match since the encapsulated packet was not modified in transit.

Sources

http://en.wikipedia.org/wiki/Network_address_translation

http://en.wikipedia.org/wiki/Simple_traversal_of_UDP_over_NATs

http://en.wikipedia.org/wiki/UPnP

http://www.voip-info.org/wiki-NAT+and+VOIP

http://en.wikipedia.org/wiki/NAT_traversal