How NAT Works

[BarryStiefel]

How NAT Works

Contributed by BenSmith
Published in geeklog Tuesday, June 24 2003 @ 01:51 PM EST
Published in oldfaq 2002-Nov-12 00:32 dwelchATphoneboyDOTcom



Overview



Network Address Translation (NAT) allows networks that would normally not be able to talk with one another to co-exist and interact peacefully. For instance, it allows an RFC-1918 network to interact with the Internet. FireWall-1 performs NAT by rules much like the security policy as packets leave the gateway.

There are three NAT modes in FireWall-1, and they can be mixed and matched as necessary: Source Static, Destination Static, and Hide. The Policy Editor application is used to edit the address translation "rules," which can either be created manually or by editing the NAT tab on individual objects (also known as "Automatic Address Translation").

Source Static translates the source IP address in an IP packet to a specific IP address. This is a 1 to 1 address translation for connections that originate from "inside" the firewall. Return traffic, as necessary, is allowed back.

Hide is a many-to-1 translation. To do this, the source port of the packet is always changed to something else. Based on this source port (which "replies" will be sent back to), the firewall will know where to direct the return traffic. Most standard applications (e.g. telnet, http, ftp, https) work fine, but any application that requires a connection initiated from the outside will not work with the hide translation, however, anything using an IP datagram other than TCP or UDP may not work correct (ICMP is handled properly, though).

Destination Static translates the destination IP address in an IP packet to a specified IP address. This is a 1 to 1 address translation for connections that originate from "outside" the firewall. Return traffic, as necessary, is allowed back.

In FireWall-1 4.1 and earlier, NAT happens last. Packets first pass thru the security policy, then OS-level routing, and then NAT as it leaves the gateway. As such, some additional considerations need to be made with NAT:

For Source Static translations: You will need a 'proxy arp' on the firewall system (or a static route on the external router) that allows the Data-Link Layer to function correctly. The MAC address that needs to be supplied for this proxy arp is that of the external interface of the firewall system. The IP address you need to supply this 'proxy arp' for is the translated IP address.

For Destination Static translations: You will need a 'proxy arp' as above. You will also need a route on the firewall system that will route packets destined for the translated IP addresses to the "untranslated" address.

For Hide translations: If you are hiding to the external interface of the firewall, nothing needs to be done. If you are hiding to a different address on the same subnet as your external interface, a proxy-arp will be needed as above.

Proxy ARPs are discussed in Routing and ARP issues with NAT.

Things are a little different in the NG release. See How NAT works in FireWall-1 NG?.

Typical uses of translations



Hide: Machines that don't provide services that need internet access. Things like user workstations.

Destination Static: Machines that provide external services with illegal IP addresses inside. Mail servers, HTTP servers, and others.

Source Static: Machines that require bi-directional communication with the internet. Typically used in conjunction with a Destination Static.

Generally, Source and Destination Static translations are used in pairs. Nothing prevents you from using any of these independently, though.

A NAT rule can specify translating a source, a destination, or both.

FireWall-1's NAT will not work correctly in cases where the "real" IP address is embedded somewhere in the payload of the packet (i.e. not in the packet headers) and FireWall-1 doesn't know to look for it there. With some protocols like RealAudio, FireWall-1 knows about the protocol and can make adjustments as necessary. FireWall-1 cannot deal with everything, for instance, IP traffic encapsulated in GRE.

One case where a HIDE simply won't work: Where the "server" expects to talk to a client on a specific port (usually for the purpose of a "reverse" connection). For example, IKE negotiations typically take place on port 500, both source and destination ports. Unless the other end of the connection can accept that, IKE will fail. This will only work if FireWall-1 is trained to look for this information and adjust accordingly, but that requires inspect code to be written.

-- RayLodato - 07 Jan 2004

FAQForm FAQs.Class: NetworkAddressTranslationFAQs FAQs.OS: FAQs.Version: