Learning to speak IP
After our look at the basics of firewalling, on to more advanced stuff – Network Address Translation (NAT).
By David Cartwright

Part of the IP specification defines a set of ‘private’ IP addresses; these are set aside for use within a corporate network and don’t form part of the address space that the Internet’s core routers are willing to route. One nice thing about private addresses is that you don’t have to register your use of them with the Internet authorities. There are also plenty of them set aside so you’re never likely to run out. The other nice thing is that because the addresses are ‘private’, the routers on the Internet don’t route them – which means it’s impossible for an intruder to make a connection over the Internet to one of these private addresses.

This is all very well, but in order for a computer to talk to the Net, it needs to have a unique, properly registered IP address. Network Address Translation, or NAT, is a neat way of combining private address with Internet connectivity.


Example
Let’s say we have a computer A, with address 192.168.1.1 (one of the ‘private’ addresses available for use). We have firewall F, which is connected to the Internet with IP address 194.75.12.12, and which has been configured to perform NAT for us. Computer A wants to make a web connection to server W, whose address is also properly Internet-registered – 139.224.3.4.


As far as A is concerned, F is just a router. A doesn’t know anything about F’s clever NAT ability – it just knows it wants to send a packet to W. So the web browser on A tells the network layer to make a connection to 139.224.3.4 on port 80. The network layer needs to build a proper IP packet; the key components are:


• Source address: 192.168.1.1
• Destination address: 139.222.3.4
• Source port: 4040 (arbitrarily chosen by the network driver)
• Destination port: 80


The network layer now forwards the packet to its default router – which happens to be F, the firewall. It’s expecting to see a reply arrive with destination port 4040 – the same as the source port it sent the request out on.


If F was just a router, it would forward the packet out onto the Internet, and it would reach its destination (W) with no real trouble. Unfortunately, W would then try to deliver the reply to 192.168.1.1, which isn’t a valid Internet address, so the response would never get back to A.


Clever rewriting
So F does some cleverness. First of all, it replaces the source address with its own IP address (194.75.12.12). Next, it chooses a new source port that it knows isn’t currently used by any other communications it’s involved in right now and sets the outgoing packet’s source port to that value (let’s say it’s 5050). Finally, it notes all of this information, both the old and new values, in a local lookup table. The packet now looks like this:


• Source address: 194.75.12.12
• Destination address: 139.222.3.4
• Source port: 5050
• Destination port: 80


The packet is then passed out onto the Internet for forwarding to W. When W sends back its response, it simply switches the source and destination information over:


• Source address: 139.222.3.4
• Destination address: 194.75.12.12
• Source port: 80
• Destination port: 5050


Response
This packet is sent out over the Internet, and because the destination address is 194.75.12.12, it winds up back at F, our firewall. Now F has some work to do. It sees that there’s a packet from 139.222.3.4, destined for its own address, with source port 80 and destination port 5050. It reasons that there might be some work to do if there is an entry in its local lookup table where:


• The table entry’s destination address matches the source address of the packet.
• The table entry’s source port matches the destination port of the packet.
• The table entry’s destination port matches the source port of the packet.


Unsurprisingly it discovers that there is a match, and that it stored the fact that (a) the original source address was 192.168.1.1 and (b) the original destination port was 4040. It therefore makes a couple of changes to the packet:


• The destination address is changed from 194.75.12.12 to 192.168.1.1.
• The destination port is changed from 5050 to 4040.


The packet is now plonked back on the network, with its key parameters set as:


• Source address: 139.222.3.4
• Destination address: 192.168.1.1
• Source port: 80
• Destination port: 4040


Now, we know that machine A, whose address is 192.168.1.1, is sitting waiting for a communication on port 4040. So when the packet arrives, it’s accepted by A as part of the Web server’s reply.


One-way traffic
Although we’ve worked this example using a request-response combination (i.e. A connects to W, and W replies back to A) there’s nothing to stop it working for connections where the connection initiation is inward-bound – for example, a remote desktop computer trying to make a web connection into our web server. In this case, alongside the self-maintaining local lookup table mentioned in the example, the firewall has a permanent table, completed by the system manager, which says ‘Connections on port 80 to address 194.75.12.12 should be forwarded to machine 192.168.5.6’. It’s also perfectly feasible to allow the firewall to have more than one IP address on its Internet-connected interface, allowing it to masquerade as several machines at once whilst actually forwarding the traffic to privately-addressed servers to do the real work.







TechNewsWorld ( requires login )