Networking: Classifying NAT

Networking: Classifying NAT

Home

The first step to coping with NAT is determining what kind of address mapping (if any) is being performed on incoming and outgoing packets. One solution is to force the user to indicate ahead of time that his computer is located behind a NAT gateway, but that requires a level of sophistication that may be overly optimistic.

Practically, then, it becomes necessary to detect the presence and nature of a NAT or firewall gateway without user assistance. Let's start then by examining how various kinds address translation affects incoming and outgoing data -- use a single endpoint behind NAT and interact with the following remote endpoints:

Remote Host	A remote Internet endpoint that has received packets from the internal endpoint.
Unsolicited Port	Another port on Remote Host that hasn't received any packets from the internal endpoint.
Unsolicited Host	An Internet host that hasn't received any packets from the internal endpoint.

Effects of Address Translation

CASE 0: Direct Network Connection / No Address Translation
Most computers on the Internet do not sit behind a NAT or firewall gateway, and no address translation is required or performed.

Remote Host	The endpoint exchanges packets with the apparent host:port of the internal endpoint.
Unsolicited Port	The endpoint sends packets to the apparent host:port of the internal endpoint.
Unsolicited Host	The endpoint sends packets to the apparent host:port of the internal endpoint.

CASE 1: Preconfigured NAT / Explicit Mapping
Some software NAT and firewall packages can be configured with default mappings, so that incoming requests on certain "magic" ports are automatically forwarded to the appropriate client port -- even before any packets are sent out. This is often called port forwarding or network DMZ (demilitarized zone).

Remote Host	The endpoint exchanges packets with the apparent host:port of the internal endpoint.
Unsolicited Port	The endpoint sends packets to the apparent host:port of the internal endpoint.
Unsolicited Host	The endpoint sends packets to the apparent host:port of the internal endpoint.

CASE 2: Permissive NAT / Implicit Mapping
More commonly, a NAT gateway requires the client to implicitly create a new mapping by sending a message to the remote server. Once the mapping has been created, the server (or anyone else) can send data to the client at the open port. Each incoming request is forwarded to the client endpoint based on the previous implicit mapping.

Before Mapping

Unsolicited Host

Packets are not forwarded to the internal endpoint because no mapping exists.

After Mapping

Remote Host	The endpoint exchanges packets with the apparent host:port of the internal endpoint.
Unsolicited Port	The endpoint sends packets to the apparent host:port of the internal endpoint.
Unsolicited Host	The endpoint sends packets to the apparent host:port of the internal endpoint.

CASE 3: Protective NAT / Implicit Mapping by Host
For security, some NAT gateways will only create create implicit mappings to a single host. To receive data from another host, the client has to create a separate mapping. Often the second mapping uses a different public port than the first.

Before Mapping

Unsolicited Host

Packets are not forwarded to the internal endpoint because no mapping exists.

After Mapping

Remote Host	The endpoint exchanges packets with the apparent host:port of the internal endpoint.
Unsolicited Port	Any other port on the remote host may also send packets to the apparent host:port.
Unsolicited Host	Packets are not forwarded from unknown hosts to the internal endpoint.

CASE 4: Consistent NAT / Implicit Mapping by Host and Port
A consistent NAT gateway always uses the same apparent port in each outgoing mapping for the same local endpoint. Unfortunately, the gateway is much more selective, entirely refusing packets from unsolicited hosts or ports -- even though they know the apparent port number is the same.

Before Mapping

Unsolicited Host

Packets are not forwarded to the internal endpoint because no mapping exists.

After Mapping

Remote Host	The endpoint exchanges packets with the apparent host:port of the internal endpoint.
Unsolicited Port	Packets are not forwarded from unknown hosts, nor from alternate ports of known hosts.
Unsolicited Host	Packets are not forwarded from unknown hosts to the internal endpoint.

CASE 5: Restrictive NAT / Unique Mapping by Host and Port
Finally, a restrictive NAT gateway is just like a consistent gateway except that it's not consistent. The NAT gateway selects a different value for the apparent port number, either in sequential or pseudo-random fashion, so that each outgoing mapping (even for the same endpoint) is always unique.

Before Mapping

Unsolicited Host

Packets are not forwarded to the internal endpoint because no mapping exists.

After Mapping

Remote Host	The endpoint exchanges packets with the apparent host:port of the internal endpoint.
Unsolicited Port	Packets are not forwarded from unknown hosts, nor from alternate ports of known hosts.
Unsolicited Host	Packets are not forwarded from unknown hosts to the internal endpoint.

CASE 6: Firewall with Proxy or SOCKS support
If the local network (or host) is protected using a network firewall, traffic to and from your endpoint may be blocked. A firewall can be configured to allow traffic on certain ports, but often this requires extra work on the part of the user and the client software.

CASE 7: Blocked network connection or host offline
In this case, the client is simply unable to contact the remote server, and no incoming messages are ever received.

Recently RFC 3489 introduced new terminology to describe NAT behavior. The concepts are the same but the English overlaps a bit, so I've decided to stick with my own terminology for my writing but to provide a quick chart that maps the concepts:

CodeWhore	RFC 3489
Permissive	Full Cone
Protective	Restricted Cone
Consistent	Port Restricted Cone
Restrictive	Symmetric Cone

This said, I feel the terminology and treatment presented here is more thorough and accurate than the other attempts to address NAT limitations. I await further research into the field that adequately addresses my concerns.