How does NAT Work?
NAT means Network Address Translation. If you've never been aware of NAT, you've probably been used it extensively without realising it. Most home broadband routers use Network Address Translation. Your router, or gateway, essentially provides a mechanism for one single public IP address provided by your internet service provider to be shared amongst all of the devices on your home network.
If you're following my "From Scratch" series of articles, this is the second in the series. It's a slight detour that's intended to put into context the networking configuration changes we will need to apply in order for our Ubuntu Server install (running on Oracle VM Virtual Box) to be accessible to the rest of your home network.
Devices that use NAT networking generally work well when those devices are consuming network and internet services, for example web browsing and reading email. NAT networking isn't so hot if that device is say, running a web or email server. It's worth taking a bit of time to understand why.
In a NATted network, all communication between the internal network and the outside world is routed by a gateway. When a computer inside the network needs to talk to a computer outside of the network, it will send it's request to the gateway. When the gateway receives the request, it will remember what IP address and port it received the request from, the source address and source port. It will also keep a record of where the request is addressed to, the target address and the target port. This information is maintained in a lookup table or state table. The gateway will forward the request to the internet server, substituting the source address for it's own Internet IP address and changing the source port for one that it made up.
In this example, the computer on the internal network has an IP address of 192.168.0.2 and it is sending a HTTP request to a web server that has an IP address of 22.214.171.124. This could be the result of the user visiting a web site. The computer realises that the address it has to send the request to is not in the local network, so it sends the request to the gateway. The gateway receives the request and it makes some notes about the request and before it sends the request onward, it re-writes the source IP address of 192.168.0.2 with it's own public internet IP address of 126.96.36.199. It also replaces the source port of 54321 with a new randomly generated source port of 12345. The gateway, once it has sent the request, will listen for a response on port 12345.
The internet server receives the request and notes the source address and the source port accompanying the request. The internet server then processes the request and sends back it's response. The internet server's response will be given a destination address and destination port that matches the source address and the source port that the gateway put into the original request.
In our example, the internet server crafts a response addressed to the gateway with a destination IP address of 188.8.131.52 and a destination port of 12345.
When a gateway receives back a response from an internet server, it will usually recognise the that this response relates to a request it dealt with moments earlier. The gateway recognises the response by checking it's destination port, source port and source IP address. The gateway knows that it received a request from a computer inside the network destined to this internet server. It also knows it received the original request on one particular port, and forwarded the request to the internet server using a different port. Ergo, the gateway can determine that a response returned from a particular address, to a particular port must be forward back to a given computer, the computer on the internal network that created the request in the first place.
The gateway takes the response and changes the destination address and destination port to match the original source address and source port from the request that the computer inside the network sent in the first place, and then re-transmits it back to that computer inside the network.
This sounds a bit complicated, so lets turn back to our example. The gateway receives the response, which has a source IP address of 184.108.40.206 and source port 80. The response also has a target port of 12345. The gateway has of course being maintaining its lookup table or state table. In the state table is a record that was created when it received the original request from the networked home computer. The record associates any responses recieved on port 123456 from source address 220.127.116.11 and source port 80 with a destination address of 192.168.0.2 and a destination port of 54321. In other words, the gateway cross references the information included with the responses with information it collected when it processed the request in order to determine where to send the response when it receives it back.
The gateway takes the response, changing the destination IP address from 18.104.22.168 to 192.168.0.2 and changing the destination port from 12345 to 54321. That means the response is forward back to the computer that created the request in the first place. And, if you like, that's the cycle complete.
Neat, huh? Well, almost. Recalling what I said earlier, NAT works really well where users are browsing the internet or retrieving their email. But there are other scenarios in which NAT breaks inter-network communications, for example, playing on-line games or running your own internet server.
What's Wrong With NAT?
NAT devices or gateways work well in scenarios where requests eminate from the internal network and responses are returned from an external network. What happens however, if I set-up a different type of connection that can't necessarily rely on requests coming from inside the network? I could for example, create a Minecraft server. Or a website that allows me to control my central heating at home. In these scenarios, the gateway would receive a request from the internet - but wouldn't know what to do with it. The gateway would have no way of knowing where in the internal network it should forward that request. To all intents and purposes, a request from the internet would look like an unsolicited response and the gateway, with no relevant data in it's state table, will usually just ignore it.
If I really did want to run my own mail server and my ISP would allow it, then I could configure my gateway to do something called port forwarding. I could tell the gateway to forward any traffic it receives on port 25 to a particular device on my home network. This approach still has it's shortcomings. For applications that don't suit request-reply style protocols, like two-way voice and video communication, developers have to effectively use hacks like continually polling an internet server or peer for a response instead of just waiting for the internet server or peer to send the response when it's ready.