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.
UNIX NAT Approaches
The topology in Figure 15-1 serves as a basis for the labs in this chapter. This is a generic example featuring a five-interface firewall/NAT gateway, as follows:
The first interface is a special segment inhabited by protocols that cannot coexist with NAT.
The second interface features an Ethernet crossover link to a screening access router.
The third interface represents a demilitarized zone (DMZ) with RFC 1918 addresses.
Finally, two internal interfaces with RFC 1918 address pools complete the picture.
The assumption is that this setup serves a fairly large corporate network. Suppose, for example, we have acquired a /24 address block from our upstream ISP, either a provider aggregate or a PI address block (does not really matter). This prefix is routed toward the firewall. Likewise, the firewall defaults toward the access router, which by itself defaults to the upstream provider.
Note that Figure 15-1 demonstrates two different ways to dynamically map client requests to either an outside address pool (n:m) or a single interface address (n:1 = masquerading). The DMZ design offers great flexibility: 1:1 static mappings, port forwarding, and load balancing can be utilized in a combined fashion.
NAT gateways are an additional hop in an IP packet's path. Therefore, they alter the Time To Live (TTL). Depending on the implementation, NAT gateways always use the same pool of port numbers for multiplexing connections. These are either predetermined at compile time or can be altered via sysctl or user-space configuration such as with ipfilter (ipf). Therefore, if you want to better camouflage your NAT gateway, taking care of a good random distribution of multiplexing ports and an unaltered TTL does not leave an investigator much evidence to detect a NAT gateway.
On the other hand, if you are in the role of an auditor, look for patterns in the high-port range for evidence of NAT conversion. Usually NAT is an integrated function of modern commercial or open-source firewalls, so do not reveal the existence of a firewall by politely rejecting packets by returning ICMP information; instead, just silently discard probes and attacks. The less information you reveal, the more difficult it is for attackers to gather useful information to penetrate defenses. Also keep in mind that the checksum of several headers has to be recomputed by the NAT gateway.
Lab 15-1: OpenBSD ipfilter
This lab (as detailed in Example 15-1) features a masquerading n:1 mapping scenario commonly found in small office/home office (SOHO) broadband and dial-up scenarios, for which a subscriber gets only one address from the service provider. The external addresses of SOHO devices such as broadband routers usually are deployed via Dynamic Host Configuration Protocol (DHCP). DHCP serves internal segments or VLANs, too.
Therefore, it is recommended that you use interface descriptors or shell variables rather than IP addresses in firewall/NAT configuration files wherever possible. You will also find examples for many-to-many configurations (NAT pools), port relaying, application proxies, and load balancing in this configuration (comments inline).
Example 15-1. OpenBSD ipfilter (ipf) NAT Configuration
[root@ganymed:~#] cat /etc/ipnat.rules
#########################################################################
# NAT/PAT Generic Configuration #
# Gernot Schmied, March 2003 #
# This configuration example assumes that the network is 20.20.20.0/24. #
#########################################################################
# #
# To get information, try "ipnat -lsv" #
# Manually start via "ipnat -CF -f /etc/ipnat.rules" #
# To clear and flush, try "ipnat -CF" #
# #
#########################################################################
#OUTSIDE="ne5"
#INSIDE ="ne3"
#DMZ ="ne4"
#NONAT ="ne2"
################################################################
### application proxies (always place before portmap rules!) ###
################################################################
# active ftp #
map ne5 192.168.1.0/24 -> ne5/32 proxy port ftp ftp/tcp
map ne5 192.168.2.0/24 -> ne5/32 proxy port ftp ftp/tcp
# H.323 proxy support #
map ne5 192.168.1.0/24 -> ne5/32 proxy port 1720 h323/tcp
# RealAudio #
map ne5 192.168.1.0/24 -> ne5/32 proxy port 7070 raudio/tcp
# IPsec Proxy #
map ne5 192.168.1.0/24 -> ne5/32 proxy port 500 ipsec/udp
#######################################
### dynamic NAT (many-to-one = n:1) ###
#######################################
map ne5 192.168.1.0/24 -> ne5/32 portmap tcp/udp 60000:65535
map ne5 192.168.1.0/24 -> ne5/32 # for ICMP
map ne5 192.168.2.0/24 -> ne5/32 portmap tcp/udp 60000:65535
map ne5 192.168.2.0/24 -> ne5/32 # for ICMP
map ne5 192.168.14.0/24 -> ne5/32 portmap tcp/udp 60000:65535
map ne5 192.168.14.0/24 -> ne5/32 # for ICMP
# alternative #
#map ne5 192.168.1.0/24 -> ne5/32 portmap tcp/udp auto
#map ne5 192.168.1.0/24 -> ne5/32 # for ICMP
###################################################
### working with NAT pools (many-to-many = n:m) ###
###################################################
#map ne5 192.168.7.0/24 -> 20.20.20.0/24 portmap tcp/udp 60000:65535
#map ne5 192.168.7.0/24 -> 20.20.20.0/24
# exclude from NAT pool #
#map-block ne5 192.168.2.18/32 -> 20.20.20.0/24 ports 64
###############################################
### static NAT entries (one-to-one = bimap) ###
###############################################
# Do not forget to set static routes when necessary
# e.g. "route add 211.11.117.65 192.168.2.65"
# There is no need to manually establish corresponding static ARP entries;
# however, in combination with some ill-behaving access devices,
# this is always a nice workaround.
# e.g. "arp -s 211.11.117.65 00:d0:ba:4c:a5:c0"
#bimap ne5 211.11.117.65/32 -> 192.168.2.65/32
# or alternatively #
# bimap ne5 211.11.117.64/27 -> 192.168.2.64/27
#######################################
### NAT Load Balancer (round-robin) ###
#######################################
#rdr ne5 211.111.111.2/32 port 80 -> 192.168.2.3 port 8000 tcp round-robin
#rdr ne5 211.111.111.2/32 port 80 -> 192.168.2.4 port 8000 tcp round-robin
#rdr ne5 211.111.111.2/32 port 80 -> 192.168.2.5 port 8000 tcp round-robin
Example 15-2 presents status information of the NAT configuration of Example 15-1 in action.
Example 15-2. OpenBSD NAT Operation Output
[root@ganymed:~#] ipnat -l
List of active MAP/Redirect filters:
map ne5 192.168.1.0/24 -> 0.0.0.0/32 portmap tcp/udp 60000:65535
map ne5 192.168.1.0/24 -> 0.0.0.0/32
map ne5 192.168.2.0/24 -> 0.0.0.0/32 portmap tcp/udp 60000:65535
map ne5 192.168.2.0/24 -> 0.0.0.0/32
map ne5 192.168.14.0/24 -> 0.0.0.0/32 portmap tcp/udp 60000:65535
map ne5 192.168.14.0/24 -> 0.0.0.0/32
List of active sessions:
MAP 192.168.1.1 34240 <- -> 211.111.111.2 61761 [195.34.133.149 80]
MAP 192.168.1.1 34239 <- -> 211.111.111.2 61760 [213.229.60.9 80]
MAP 192.168.1.1 34238 <- -> 211.111.111.2 61759 [138.22.167.21 80]
MAP 192.168.1.1 34237 <- -> 211.111.111.2 61758 [205.156.51.200 80]
MAP 192.168.1.1 34236 <- -> 211.111.111.2 61757 [213.229.60.100 110]
MAP 192.168.1.1 34235 <- -> 211.111.111.2 61756 [213.229.60.100 110]
MAP 192.168.1.1 34234 <- -> 211.111.111.2 61755 [213.229.60.100 110]
MAP 192.168.1.1 34233 <- -> 211.111.111.2 61754 [213.229.60.100 110]
MAP 192.168.1.1 34232 <- -> 211.111.111.2 61753 [213.46.255.2 110]
MAP 192.168.1.1 32895 <- -> 211.111.111.2 61752 [195.34.133.10 53]
MAP 192.168.1.1 32894 <- -> 211.111.111.2 61751 [195.34.133.10 53]
MAP 192.168.1.1 32893 <- -> 211.111.111.2 61745 [195.34.133.10 53]
MAP 192.168.1.1 32892 <- -> 211.111.111.2 61744 [195.34.133.10 53]
MAP 192.168.1.1 32890 <- -> 211.111.111.2 61738 [195.34.133.10 53]
MAP 192.168.1.1 32889 <- -> 211.111.111.2 61737 [195.34.133.10 53]
MAP 192.168.1.1 32888 <- -> 211.111.111.2 61731 [195.34.133.10 53]
[root@ganymed:~#] ipnat -lv
List of active MAP/Redirect filters:
map ne5 192.168.1.0/24 -> 0.0.0.0/32 portmap tcp/udp 60000:65535
map ne5 192.168.1.0/24 -> 0.0.0.0/32
map ne5 192.168.2.0/24 -> 0.0.0.0/32 portmap tcp/udp 60000:65535
map ne5 192.168.2.0/24 -> 0.0.0.0/32
map ne5 192.168.14.0/24 -> 0.0.0.0/32 portmap tcp/udp 60000:65535
map ne5 192.168.14.0/24 -> 0.0.0.0/32
List of active sessions:
MAP 192.168.1.1 34240 <- -> 211.111.111.2 61761 [195.34.133.149 80]
age 299 use 0 sumd 0xc586/0xc586 pr 6 bkt 0/60 flags 1
ifp ne5 bytes 5157 pkts 19
MAP 192.168.1.1 34239 <- -> 211.111.111.2 61760 [213.229.60.9 80]
age 299 use 0 sumd 0xc586/0xc586 pr 6 bkt 89/38 flags 1
ifp ne5 bytes 12208 pkts 27
MAP 192.168.1.1 34238 <- -> 211.111.111.2 61759 [138.22.167.21 80]
age 254 use 0 sumd 0xc586/0xc586 pr 6 bkt 46/122 flags 1
ifp ne5 bytes 2129 pkts 11
MAP 192.168.1.1 34237 <- -> 211.111.111.2 61758 [205.156.51.200 80]
age 255 use 0 sumd 0xc586/0xc586 pr 6 bkt 20/80 flags 1
ifp ne5 bytes 8635 pkts 33
MAP 192.168.1.1 34236 <- -> 211.111.111.2 61757 [213.229.60.100 110]
age 227 use 0 sumd 0xc586/0xc586 pr 6 bkt 100/49 flags 1
ifp ne5 bytes 1515 pkts 24
MAP 192.168.1.1 34235 <- -> 211.111.111.2 61756 [213.229.60.100 110]
age 226 use 0 sumd 0xc586/0xc586 pr 6 bkt 98/47 flags 1
ifp ne5 bytes 1264 pkts 20
MAP 192.168.1.1 34234 <- -> 211.111.111.2 61755 [213.229.60.100 110]
age 226 use 0 sumd 0xc586/0xc586 pr 6 bkt 96/45 flags 1
ifp ne5 bytes 2481 pkts 30
MAP 192.168.1.1 34233 <- -> 211.111.111.2 61754 [213.229.60.100 110]
age 226 use 0 sumd 0xc586/0xc586 pr 6 bkt 94/43 flags 1
ifp ne5 bytes 1280 pkts 20
MAP 192.168.1.1 34232 <- -> 211.111.111.2 61753 [213.46.255.2 110]
age 220 use 0 sumd 0xc586/0xc586 pr 6 bkt 75/24 flags 1
ifp ne5 bytes 1539 pkts 22
MAP 192.168.1.1 32895 <- -> 211.111.111.2 61752 [195.34.133.10 53]
age 992 use 0 sumd 0xcabe/0xcabe pr 17 bkt 93/32 flags 2
ifp ne5 bytes 1150 pkts 10
MAP 192.168.1.1 32894 <- -> 211.111.111.2 61751 [195.34.133.10 53]
age 940 use 0 sumd 0xcabe/0xcabe pr 17 bkt 91/30 flags 2
ifp ne5 bytes 198 pkts 2
MAP 192.168.1.1 32893 <- -> 211.111.111.2 61745 [195.34.133.10 53]
age 940 use 0 sumd 0xcab9/0xcab9 pr 17 bkt 89/18 flags 2
ifp ne5 bytes 480 pkts 4
MAP 192.168.1.1 32892 <- -> 211.111.111.2 61744 [195.34.133.10 53]
age 580 use 0 sumd 0xcab9/0xcab9 pr 17 bkt 87/16 flags 2
ifp ne5 bytes 198 pkts 2
MAP 192.168.1.1 32890 <- -> 211.111.111.2 61738 [195.34.133.10 53]
age 580 use 0 sumd 0xcab5/0xcab5 pr 17 bkt 83/4 flags 2
ifp ne5 bytes 464 pkts 4
MAP 192.168.1.1 32889 <- -> 211.111.111.2 61737 [195.34.133.10 53]
age 220 use 0 sumd 0xcab5/0xcab5 pr 17 bkt 81/2 flags 2
ifp ne5 bytes 182 pkts 2
MAP 192.168.1.1 32888 <- -> 211.111.111.2 61731 [195.34.133.10 53]
age 220 use 0 sumd 0xcab0/0xcab0 pr 17 bkt 79/117 flags 2
ifp ne5 bytes 464 pkts 4
List of active host mappings:
192.168.1.1 -> 0.0.0.0 (use = 16 hv = 32)
[root@ganymed:~#] ipnat -s
mapped in 34077 out 34425
added 1763 expired 1746
no memory 0 bad nat 0
inuse 17
rules 6
wilds 0
Lab 15-2: FreeBSD ipfw+natd
The user-space FreeBSD application natd(8) requires both the ipfw and the ipdivert sockets in the kernel configuration (options IPFIREWALL, options IPDIVERT). In addition, the following settings must be in /etc/rc.conf, as shown in Example 15-3).
Example 15-3. FreeBSD natd Requirements
gateway_enable="YES"
firewall_enable="YES"
firewall_type="OPEN"
natd_enable="YES"
natd_interface="en5" # Indicates which interface to forward packets through
# (the interface connected to the Internet).
natd_flags=" –l –m –u –f /etc/natd.conf"
The FreeBSD natd supports traditional NAT and port/protocol/address redirection. Consult the man page natd(8) for further operational details. Example 15-4 presents a short example of port relaying.
Example 15-4. FreeBSD natd Example for Redirects
-redirect_port tcp 192.168.1.2:6667 6667
-redirect_port tcp 192.168.1.3:80 80
-redirect_port tcp 192.168.1.4:2000-3000 2000-3000
-redirect_address 192.168.1.2 128.1.1.2
-redirect_address 192.168.1.3 128.1.1.3
-redirect_proto encap 192.168.1.4
Lab 15-3: BSD Packet Filter (pf)
The pf packet filter is OpenBSD's native packet-inspection, stateful firewall, and NAT engine. It recently was ported to other BSD operating systems. Because it was inspired by ipfilter and works similarly, it is not discussed in detail here. For further information, consult the sources (especially the pf FAQ) in the "Recommended Reading" section at the end of this chapter.
Lab 15-4: Linux NAT (iptables)
The firewall/NAT engine for the 2.4 and 2.6 Linux kernels is iptables/netfilter. Because of the large number of features available, only a short example of IP masquerading on PPP links is presented in Example 15-5 (which is quoted from the iptables NAT tutorial).
Example 15-5. Linux iptables Masquerading Example
# Load the NAT module. (This pulls in all the others.)
modprobe iptable_nat
# In the NAT table (-t nat), append a rule (-A) after routing
# (POSTROUTING) for all packets going out ppp0 (-o ppp0), which says to
# masquerade the connection (-j MASQUERADE).
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
# Turn on IP forwarding.
echo 1 > /proc/sys/net/ipv4/ip_forward
NAT-Hostile Protocols
Because of their intrinsic operation, NAT gateways in the communication path of certain protocols might disturb their inner working. Good examples are H.323/SIP, FTP, end-to-end IPSec, and peer-to-peer applications. Unfortunately, these problems often are caused by inconsiderate application development and easily could have been avoided (RFC 3235, "Network Address Translator (NAT)—Friendly Application Design Guidelines"). In the case of H.323, this can be compensated easily by application level gateway (ALG) mappings of modern firewall engines (for example, Cisco PIX Firewall) or the use of H.323 gatekeepers/proxies.
Keep in mind that stateful NAT and stateful inspection firewall issues are related and often intertwined. Special pains are applications that use random ports.
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.
If You Enjoyed This Post Please Take a Second To Share It.
You Might Also Like
Stay Connected With Free Updates
 |
 |
 |
|
Subscribe via Email
|
