NAT Intro and Firewall Limitations

NAT Intro

RFC 1918 specifies three blocks of IP addresses which are to be considered "local to an enterprise" which internet routers should not pass. One block contains all IP address between and This means both that an enterprise is free to allocate and use these IP addresses locally without needing to coordinate with anyone outside the enterprise and that hosts with these "private addresses" can not exchange packets using these addresses with the internet at large. Whereas RFC1918 does not prohibit an enterprise from routing "private addresses" internally, UW does not do so (for the addresses used by the Logical Firewall). Therefore, on the UW campus, these private addresses are confined to their subnet and a host using such an address can communicate directly only with other hosts with similar private addresses on the same subnet. This is the mechanism by which the NDC Logical Firewall isolates its clients without the need for rewiring them. Interestingly, no problems result from mixing public and private IP addresses on the same wire--they ignore each other.

If a host with a private address needs to communicate with a remote host on another network, it must do so indirectly by sending that traffic to an intermediary, such as the Logical Firewall, which will do "Network Address Translation" (NAT). The NAT box changes the source address of outbound packets to a routable/public address and the destination address of inbound traffic to the non-routable/private address so that the remote host should be unaware of the translation.

Because the NAT box must intermediate all traffic between private and public addresses, it is said to be "logically between" remote hosts and those with private addresses and is therefore in a good position to act as a firewall. The NDC Logical Firewall does NAT (putting it logically between its clients and the outside world) and in addition has rules you specify to govern which traffic will be permitted through it.

Masquerading vs Non-Masquerading NAT

Two "flavors" of NAT are supported by the NDC Logical Firewall: "masquerading" and "non-masquerading".

In non-masquerading NAT, each private IP address on a client has a corresponding public/routable IP address on the firewall and NAT translation is done one-to-one between pairs of public and private IP addresses. Port numbers remain unchanged by this type of NAT. This is the type of NAT you need for protecting servers with the Logical Firewall (and is the type you get for clients you've specified to the rule generator). Inbound connections to clients are accepted via the client's public/routable IP address on the firewall.

To simplify assignment of private IP addresses and the mapping between public and private addresses, we simply replace the first octet of a client's public IP address with 10 to get the corresponding private address. Thus, every UW public address automatically has a corresponding and unique private address.

In masquerading NAT, outbound packets are translated to the public/routable IP address of the firewall and may need to be given a different source port (if the original port is already in use on the firewall). This is called "masquerading" NAT because all outbound connections appear to be originating on the firewall itself. Inbound connections can not be accepted for this type of NAT (because the firewall doesn't know which client to send them to).

At UW, we recommend that people avoid masquerading NAT, if possible, because it makes it look like the firewall itself is misbehaving, if one of its clients misbehaves and that increases the risk that our NOC will disconnect the firewall rather than the offending client in an emergency. Using non-masquerading NAT and following instructions in Interaction With UW Network Operations will usually allow the NOC to identify and disconnect only the offending client.

Firewall Limitations

Comparison with Traditional (Physical) Firewalls

  1. With a physical firewall, you must physically isolate the firewall's clients on a segment of network which connects only to the firewall. If the clients are not centrally located, this may require additional wiring. On the other hand, traffic on the protected side of the firewall is available only to hosts on the protected side of the firewall.

    With the Logical Firewall there is no separate wire and except for some degree of protection offered by switches on the subnet, all private address traffic is potentially accessible to any host on the subnet. That is, a compromised host with a public/routable address on the same subnet may be able to sniff or generate private address traffic depending on the capabilities of the host and the intruder. On the other hand, there are thousands of times as many hosts and potential intruders on the internet at large as on any individual subnet, so the logical firewall can vastly reduce (if not totally eliminate) its clients' exposure.

    Note: the NDC Logical Firewall can also be configured as a physical firewall by adding a second network interface card and hooking all the clients to the second interface.

  2. A few protocols (most notably Microsoft WINS) embed the IP address of the sending host inside the data payload of the packet (not the part NAT translates). These protocols will not work with the Logical Firewall unless one of the unsupported NAT-free variations is used.

  3. The Logical Firewall requires its clients be reconfigured with a new IP address and gateway. Some physical firewalls (including Logical Firewall Variation #4) operate as "filtering bridges" avoiding this inconvenience.

  4. If both private and public DHCP addresses co-exist on the same wire, it's difficult to configure DHCP to offer the right (public or private) address to clients. This is why we don't recommend using the Logical Firewall with DHCP clients.

Limitations Shared with other Firewalls

Corey Satten
Email -- corey @
Web --
Date -- Mon Jan 28 12:26:29 PST 2008