NAT and port forwarding

This is a follow-up article to the one I posted yesterday about port forwarding in pfSense. The intent i to clarify a bit about what NAT is, what it is for, how it relates to port forwarding and packet filtering, the latter responsibility typically assigned the term Firewall.

If you’re wondering about the term IP Masquerade, then it’s just another, more illustrative name for the NAT concept. Machines masquerading or pretending to be other machines.

Network Address Translation – NAT

Q: So what is NAT?
A: It’s a way of extending the IP network address range to include non-addressable endpoints.

Ok, that was concise, but what does that really mean?

Consider a typical IP address you get assigned by you ISP, such as 80.1.2.3
If all you get is one IP address, but your household / office has more than one machine which need to access the Internet, then you can either take turns using the sole internet cable on the premises, or you can assign some kind of proxy to mediate requests to the Internet. This proxy has the “internet cable” attached and will make all connections on your behalf. Each time a request for an internet resource is requested, the proxy intercepts the request and fetches the resource for you and then forwards the resource to your machine.

Now a NAT component can be viewed as a special case of a proxy. It does intercept your requests, but it isn’t itself actively fetching stuff on your behalf. Instead it hacks your requests and forges the sender address to be its own address (the ISP assigned address) before forwarding your request to the Internet. This means that whatever internet server responds to the request, that server will send the response to the “NAT proxy” instead of to you. When the reply arrives to the NAT proxy, the proxy also forges the response, the destination address. The original response was addressed to the NAT proxy, but the NAT “remembered” that it forged your request, so it uses that recollection to forge the response as well, before forwarding the response to the LAN where your computer resides.

This constant packet forging of incoming destination addresses and outgoing sender addresses and the pairing of incoming responses to outgoing requests is what NAT basically does.

The problem it is trying to solve is one of extending the address range on your LAN so that machines which don’t have any real public IP addresses can still be routed to and from, as if they had publicly routable addresses.

The tactic NAT uses to achieve this goal is by pretending that the NAT appliance’s available ports are part of the Internet IP-address range, so that it is possible to route IP packets between machines, as if they had real addresses. So the combination <IP> : <Port> gets translated into <IP>.<Port> for routing purposes.

Let’s illustrate.

Now the challenge is that this solution only works one way. Consider the scenario depicted above. How does the packet modifier know which address to forge and when? If we follow the numbered scenario, your NAT appliance is obviously able to handle that, since you’re apparently able to read this post :)

So how does it know to forge your LAN addresses but not the addresses of the machines on the Internet?

Well easy, it has a general rule which states that all requests from the network on the right should have their sender addresses forged and that all responses to those forged requests should have their sender addresses spoofed.

Leveraging this default rule yields a minimal configuration solution for 99% of the internet users, since most of the population consume content, but do not host it.

Now what would happen if the Internet machine wanted to request some resource off say a web server running on the LAN machine? It wouldn’t get any, since the packet modifier has no rule nor knowledge of what to do when a request arrives addressed to it, targeting port 80 (the standard web server port), so the packet modifier would either just drop the package into the big void, or send back a response telling the Internet machine “You can’t connect to me on that port”.

So the way to mitigate this problem is to tell the packet modifier what to do, by specifying a rule which defines what should happen when requests from the “wrong side” arrive to it on a specific port. This is what is commonly known as port forwarding.

Port forwarding

The concept is pretty self-explanatory from its phrasing. A connection established on a given port should be forwarded somewhere, where somewhere is an IP address and [another] port. Port forwarding is achieved by defining one or more rules which each state where to forward to under a given circumstance.

For our web server example, we would define a forwarding rule which states:

Requests arriving on our Internet network card, addressed to the Packet modifier machine at port 80, should be forwarded to LAN machine on port 80.

When we define such a rule, a decent firewall such as pfSense will also add a filtering rule for requests arriving from anywhere addressed to LAN Machine at port 80, to be allowed through as well. The firewall would otherwise stop the packet dead in its tracks, since a firewall’s primary job is to stop/control traffic, not to facilitate it. The latter is what routers, switches and certain kinds of proxies are for.

When a request packet initially arrives from a machine on the Internet addressed to the firewall, the Packet modifier checks if the port the request is arriving on has a forwarding rule defined. If not the request will be discarded, but if it has one then the modifier will spoof the sender and change the destination port to whatever the forwarding rule defined and make a note of the Internet machine’s IP address and Port, so that it knows where to send a potential reply. It will also jot down the translated address for the LAN machine plus the translated port so it knows that a potential reply from the LAN machine on the addressed port should be sent to the Internet machine on the port it advertised in the request.

When this is done, the packet is handed over to the packet filter (security part) of the firewall which if it approves of the package being sent to the LAN machine at port 80, will let the packet through to the LAN so that it can be serviced by the LAN machine.

The entire round-trip would look like this:

To recap the flow:

1. A packet arrives on the Internet network interface, addressed to the firewall’s public IP (A1) on port (P1).
2. The packet modifier looks up where it should forward the request to and jots down in its mapping [state] table a record consisting of the sender’s IP address (A2), the port the sender wants the reply on (P2), plus the LAN destination IP address (A3) and port (P3) the forwarding rule dictates (A2:P2 -> A3:P3). It then changes A1:P1 -> A3:P3 in the packet before forwarding it to the security enforcement point.
3. The protocol filters are evaluated (by the packet inspector component) and if all looks fine, the packet is forwarded to the LAN where it winds up at the address and port the packet now contains; A3:P3 which in our previous scenario was LAN machine at port 80.
4. The program on the LAN machine which serviced the request sends a response addressed to A2:P2 which arrives at the LAN interface of the firewall.
5. The Packet inspector looks at the package and if it satisfies the inspector’s scrutiny, the packet is then forwarded to the Packet modifier.
6. The Packet modifier checks to see if it has a record of A2:P2 -> A3:P3 and it has, so it uses that information to modify the packet. It changes the sender to be itself as well as the sender port to the port the Internet machine’s original request arrived on (A3:P3 -> A1:P1) and then forwards the request to the Internet.
7. The response to the LAN machine’s request finds it way through the cloud to the Internet machine, which consumes the packet without ever realizing its request and the response had been through a number of transformations and was in fact serviced by another machine than the one it asked the service of.

To the Internet machine it it looks like an ordinary conversation took place with a program running on the Firewall machine and that the foreign endpoint of the conversation was with A1:P1, when in reality the conversation was with A3:P3.

If you’re completely new to networking, then I hope this illustration provided some insight into what NAT is, why some people need port forwarding, how they relate and how you go about making Internet citizen able to get at your local resources.

Disclaimer: This explanation isn’t 100% accurate in that packet inspection (Allow/Deny evaluation and enforcement) can occur before/after or before and after address and port translation occurs. In addition, some firewall products are more monolithic than others and include the NAT/IP Masquerading in the rule chains of the protocol filtering itself.  However the depicted flow illustrates what generally happens, which should be sufficient for configuring NAT on your favorite firewall product.