Network Address Translation

The concept of Network Address Translation (NAT) goes back to the origin of the feared IP address shortage. An IP address shortage was a distinct possibility because, historically, huge address blocks were assigned, which were underutilized or were assigned inefficiently, in the early days before the classless interdomain routing (CIDR) and variable-length subnet masking (VLSM) of today's Internet. Today's address-assignment policies are much stricter, and registration authorities now try to free underutilized address aggregates by demanding them back for reassignment. Historically, most addresses were assigned to North America and Europe. NAT improves aggregation and scalability of enterprise routing, too, so it contributes to keeping the global Internet routing table "relatively" small.

From a "workaround" for address exhaustion, NAT has evolved into a flexible vehicle for enterprises and Internet service providers (ISPs). Although NAT per se is not a security vehicle, it arguably improves privacy. An attacker usually does not know which and how many addresses remain hidden (masqueraded) behind corporate NAT gateways. One can attack only the outside addresses of these gateways or the address pools deployed for NAT.

This chapter discusses UNIX NAT approaches, frequently used terminology, and caveats in context with NAT-incapable protocols. The chapter concludes by looking at future developments with regard to IPv4 NAT.

The NAT Foundation—Basic/Traditional NAT

NAT enables hosts with RFC 1918 addresses to access officially routed Internet IPv4 addresses, but it also can be deployed for migration scenarios with overlapping address space. RFC 3022 exhaustively describes the evolution of NAT variants and is highly recommended reading. In the most general case (basic NAT), inside RFC 1918 private address pools are mapped to outside address pools that are transparent to end users. The original approach featured a 1:1 mapping from internal to external addresses, which by itself did not provide address preservation. The introduction of Network Address Port Translation (NAPT or PAT) changed this picture in a way—that is, via TCP/UDP ports, many internal addresses can be mapped into one outside address. This is also referred to as port multiplexing.

NAT gateways store information that is relevant for mapping/reverse mapping in state tables. NAT/PAT mappings come in several flavors:

• One-to-one or bidirectional mapping (1:1) (static mappings)

• One-to-many (1:n) (single gateway address = NAPT/PAT/masquerading or dynamic NAT)

• Many-to-many (n:m) (NAT address pools)

NAT, PAT(NAPT), Masquerading, and Port Mapping/Multiplexing

In the Linux world, the term IP masquerading often is used for historical reasons. In pre-iptables times, the masquerading engine was separate from the packet filter and stateful inspection engine. In a way, IP masquerading is a point of view that emphasizes the stealthy character of the procedure. In contrast, PAT describes the mechanism more accurately.

NAT gateways (NAT translators in Internet Engineering Task Force [IETF] parlance) internally operate as TCP/UDP port multiplexing/demultiplexing engines. This procedure also is referred to as mapping and reverse mapping. NAPT is IETF parlance for PAT.

You occasionally will find that Cisco differentiates between NAT and PAT. From the Cisco perspective, this is a differentiation of one-to-one and many-to-one/many-to-many mappings.

Static NAT and ARP/Routing Issues

Keep in mind that NAT gateways need to reply to Address Resolution Protocol (ARP) requests for NAT-mapped global addresses under their administrative authority. In the case of such pool addresses, the outside gateway interface and the access router's inside interface share the same broadcast domain, ARP is used, and the NAT gateway is required to reply on behalf of the static address pool. This behavior can be accomplished by adding static ARP entries or, even better, alias interface addresses. Most of the time, the firewall/NAT software takes care of this by itself, though.

In the case of ordinary routing such as in Figure 15-1, remember to add explicit routes for NAT pools on screening/access routers toward the NAT engine. In that case, the pool is routed, and this is no longer an ARP issue. On some implementations, however, it might be necessary to add an explicit route for static mappings from the outside to the inside address; others handle this automatically. Now you know the two showstoppers to look out for in case of problems.

Redirection (Port Forwarding/Relaying or Transparent Proxying)

Port forwarding redirects incoming connection requests to the NAT gateway to an arbitrary address/port. In certain configurations (port rewrite), this is referred to as transparent proxying. Also keep in mind that under certain circumstances (in/out on the same interface), it might be necessary to disable Internet Control Message Protocol (ICMP) redirects (sysctl -w net.inet.ip.redirect=0); otherwise, it might interfere with what you want to accomplish.

Future Developments: NAT-T, MPLS+NAT, Load Balancer

Current development focuses on NAT failover solutions, with added functionality of load balancers and transparent proxies. The latter features usually are accomplished via the redirection engine.

Especially interesting for ISP deployments and product offerings is the capability of modern Multiprotocol Label Switching (MPLS) implementations (edge routers) to configure NAT between MPLS virtual private networks (VPNs) with overlapping address space (for example, extranets) and the global routing table.

NAT-T (NAT Traversal) essentially sums up attempts to reduce issues of tunnel deployments and protocol traversal in the context of NAT gateways. For more information, see the IETF draft document "Negotiation of NAT-Traversal in the IKE" (referenced in the "Recommended Reading" section at this end of this chapter), a self-description of which follows:

This document describes how to detect one or more network address translation devices (NATs) between IPSec hosts, and how to negotiate the use of UDP encapsulation of IPSec packets through NAT boxes in Internet Key Exchange (IKE).

With regard to NAT-hostile protocols, the current approach of choice to remedy the problem is described in RFC 3489, "STUN-Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translation." In addition, consult RFC 3519, "Mobile IP Traversal of Network Address Translation (NAT) Devices," for caveats in the context of mobile deployments.

NAT Redundancy—Stateful Failover

Asymmetrical routing in general does not work with NAT gateways and stateful inspection firewalls. (It might even break packet fragmentation/reassembly.) This has to be taken into consideration when designing gateway failover solutions. Dynamic routing protocols might help on occasion, especially with static 1:1 mappings.

This particular potential problem can be overcome if the routers share the same NAT configuration and rapidly and constantly exchange state information to ensure a failsafe backup for each other. Nevertheless, a busy enterprise gateway most likely will still lose some connections or drop packets during a short transitional switch-over phase.

OpenBSD's pf is the first integrated gateway/NAT engine of open-source character that has NAT and stateful inspection table synchronization under development (pfsync). The Cisco PIX Firewall offers a proprietary failover approach, and Cisco IOS routers are capable of dealing with stateful failover translation groups.

Note that stateful NAT (SNAT in Cisco lingo) enables continuous service for dynamically mapped NAT sessions and works with Hot Standby Router Protocol (HSRP). Occasionally, NAT gateways also provide DHCP services to internal network segments. A true redundancy architecture also requires mirroring/synchronizing of DHCP lease tables. This is possible with the ISC dhcpd.