how-to block ads
|
| | | | FAQ Revisions | Editors: Wildcatboy  , gwion , keith2468 , amysheehan , CalamityJane
Last modified on 2008-08-24 11:27:46
| |
|
|
3. NAT Routers·What is NAT?
·What types of NAT are there?
·What are the security related implications of NAPT?
·Is my NAT box a firewall?
·Should I run a software firewall behind my NAT router?
·I see inbound alerts on my software firewall behind NAT - why?
·How do I allow inbound conversations through NAT?
·What is a 'DMZ' or 'default server'?
·Why doesn't my application / protocol work through NAT?
·What's up with MSN Messenger and NAT?
·Can multiple clients play DirectPlay games through NAT?
·I'm having trouble port scanning a stealthed host from behind NAT, why?
·What options are there when implementing NAT?
·Which NAT routers support UPnP NAT Traversal?
| | | Summary
Network Address Translation (NAT) is a technique that allows multiple devices to share one or more IP addresses. It is normally employed at the gateway between a private network and the Internet -- allowing the devices on the private network to share a global ISP assigned address.
This is achieved by modification of the headers of each packet traversing the device. At a minimum, the IP address (and IP header checksum) is replaced (translated). For packets outbound to the Internet, source addresses are translated from private -> public. For packets inbound from the Internet, destination addresses are translated from public -> private.
NAT is an Internet Engineering Task Force (IETF) standard for the sharing of an IP address. It was proposed in the 70s as a solution to the problem of decreasing IPv4 address space. Prior to its inception, everything attached to the Internet had a unique, global IPv4 address. The introduction of NAT (and that of reserved, private address space) allowed multiple privately addressed hosts to share a single global IP address.
The subnets reserved for private use are:
10.x.x.x or 10/8 (Class A) 172.16.x.x - 172.31.x.x or 172.16/12 (Class B) 192.168.x.x or 192.168/16 (Class C) 169.254.x.x or 169.254/16 - 'Auto-configuration'
A host that is set to obtain an IP address via DHCP (Dynamic Host Configuration Protocol) but which fails to do so will attempt to assign itself a random address from the auto-configuration subnet.
The reserved addresses are reusable, not globally unique and therefore not routable on the Internet. Although by far the most common configuration, the use of private addresses is not mandatory, and it is possible to use any address type with NAT. For the purposes of this FAQ, it is assumed that NAT separates a private network and the Internet.
NAT is a type of routing in which the packet headers of each packet are modified by the interchange of (at least) a private address and a public address. The process is probably explained most clearly by following a conversation through NAT:
1. A host in a privately addressed subnet attached to the Internet via a NAT router sends a connection initiation (SYN flagged) TCP packet to www.dslreports.com (which it has previously resolved to an IP address). The ethernet frame containing the packet is addressed to the private interface of the NAT router (the host's default gateway).
Headers contain:
Source IP: 192.168.0.1 (an example private address)
Destination IP: 209.123.109.175
2. The NAT router receives the frame and changes the source IP address from the host's private address to a public (global) address, recalculates the checksum and forwards the packet out onto the Internet.
Headers contain:
Source IP: 1.1.1.1 (an example global address)
Destination IP: 209.123.109.175
3. DSLR replies with a TCP SYN / ACK flagged packet IP addressed to our global address.
Headers contain:
Source IP: 209.123.109.175
Destination IP: 1.1.1.1
4. The NAT router receives this and changes the destination IP address to the host's private address before passing it on to the host.
Headers contain:
Source IP: 209.123.109.175
Destination IP: 192.168.0.1
Note that the process is completely transparent to the end points of the connection. Neither the private host nor DSLR has any idea that the translation has taken place. The process is the same for UDP. For a description of how NAT deals with ICMP error messages, see here.
 feedback form
 feedback form
by Nick edited by JMGullett
last modified: 2007-06-29 15:37:06 | | | Summary
The most common type of NAT is NAPT, or "Many-to-one" NAT, as found in broadband routers and software such as ICS and Winroute. NAPT translates the IP and port addresses (or query ID for ICMP) in each packet that traverses it, allowing multiple computers to participate in multiple concurrent conversations.
Basic NAT also known as 'pooled NAT' or 'dynamic 1-1 NAT'
In early forms of NAT, it was assumed that in a typical private network only a few hosts were communicating with external hosts at any one time. A pool of global addresses was set aside for use with NAT, and private hosts could make as many concurrent connections to external hosts as global addresses available in the pool. Routers needed a small amount of memory to keep track of the private address currently associated with each public address, allowing translation and routing of inbound traffic.
Static 1-1 NAT
This is an even simpler scheme, used where only a few hosts in a private network ever communicate with external hosts. In this scheme, each private host has a direct and fixed mapping to a global address.
Network Address Port Translation (NAPT), also known as 'PAT' and 'many to one' or 'M-1 NAT'
This is what people generally mean when they say "NAT" -- the form of NAT used in broadband routers (NAT boxes), many firewalls, software such as Winroute and ICS, etc. In this scheme, multiple hosts can share a single address and make many concurrent connections. This is achieved by translation of IP addresses and port addresses (or query ID in the case of ICMP). Ports and query IDs are used in the TCP/UDP and ICMP protocols, respectively, for multiplexing of conversations -- i.e. to allow multiple concurrent conversations between hosts via unique identification of each. Again, the process is most easily explained via following a TCP exchange via NAPT (ignoring checksum replacements):
1. Private host sends TCP SYN flagged packet to DSLR with the following TCP header fields:
Source IP: 192.168.0.1 (example private IP address)
Destination IP : 209.123.109.175
Source port: 1024
Destination port: 80
2. The NAT router receives the frame and replaces the source IP address and port (and makes the necessary checksum replacements). It then makes a record of the header details (both untranslated and translated) in the "NAT table" held in memory before forwarding the packet onto the Internet.
Source IP: 1.1.1.1 (example public IP address)
Destination IP: 209.123.109.175
Source port: 20000
Destination port: 80
3. DSLR replies:
Source IP: 209.123.109.175
Destination IP: 1.1.1.1
Source port: 80
Destination port: 20000
4. The NAT router receives the reply and checks the header details against all entries in the NAT table. In this case, it finds the entry made in step 2 and can therefore replace the destination address and port and forward the packet onto the private host.
Source IP: 209.123.109.175
Destination IP: 192.168.0.1
Source port: 80
Destination port: 1024
In the case of ICMP, the addresses and query ID (instead of port address) are translated. Outbound traffic is monitored for TCP SYN flagged packets, and new UDP / ICMP conversations and NAT table entries (comprising the original and translated header details) are made so that each conversation (a TCP connection, a UDP exchange with a certain host and port, etc) has an entry in the table. This allows the device to translate and route inbound packets to their private destinations.
All NAT table entries are removed after a timeout period of inactivity. In the case of TCP, the entry can be removed immediately when the connection closes (a pair of FIN / ACK packets are seen). In the case of some ICMP types, the entry can be removed when a reply is received. The values for timeouts are often user modifiable. Note that the process is, again, entirely transparent to the end points of the connection.
Multi-NAT
Multi-NAT allows several NAT schemes to be used with several public IP addresses. For example, a 1-1 NAT could be used on 3 global addresses for web, mail and DNS servers whilst NAPT is employed on a fourth global address for workstations.
feedback form
feedback form
by Nick edited by JMGullett
last modified: 2007-06-29 15:49:17 | | | Summary
NAPT can be considered a one-way valve for conversations, permitting only those which are initiated by the computers behind it. The only inbound traffic which can traverse NAPT is that which is part of an internally initiated conversation ("solicited traffic"). This is similar to the effect of a stateful firewall.
The most obvious implication of using NAPT is that connections from the Internet to the private network are impossible!* In fact, unlike with simple packet filters, the passing of any unsolicited traffic from an external host to the private network is prevented. Unsolicited packets are those which are not part of a conversation initiated by a private host. Obviously, sending packets to private addresses across the Internet will fail because Internet routers do not have private routes in their tables, and they will, therefore, discard the packets. Sending packets to the global address of the NAT router cannot succeed either -- the packets would not be part of any conversation recorded in the NAT table, the addresses/ports could not be translated and the packet would be discarded.
NAT can be considered a one-way valve for conversations. This is a very similar effect to that of a stateful firewall configured to "block everything," in that packets which are not part of internally initiated conversations are ignored. Indeed, a stateful firewall has the equivalent of a NAT table, called a "state table." This "feature" of NAT means that any traffic from an external host which makes it to a private host is, by definition, "return traffic," i.e. part of a conversation initiated by that host.
You may question how ICMP error messages (TTL exceeded, destination unreachable, etc.) make it to private hosts -- after all, they aren't part of an outbound conversation and would appear to be unsolicited. The answer is that ICMP error messages include the header of the packet that caused their generation as data. When the device receives an ICMP error message, it looks at the packet header in the data portion of the message to determine which conversation (if any) the message is related to and translates and forwards (or drops) it accordingly.
*Well.. not quite, see here.
feedback form
feedback form
by Nick edited by JMGullett
last modified: 2007-06-05 16:22:43 | | | The answer depends on the definition of "firewall" and on the particular device. Almost all NAT boxes have rudimentary packet-filtering capabilities, although the number and complexity of filters is often limited. Also, as previously noted, NAPT itself has "firewall-like" properties. However, modern firewalls offer many more features, including Stateful Packet Inspection (SPI), VPN endpoints, DoS protection and secure remote management.
A home user would hopefully never need DoS protection. He/she probably doesn't host servers on static 1-1 mappings and therefore benefit from stateful inspection, or want to craft an intricate set of filters. NAT is entirely sufficient for such cases. If you have more complicated requirements, host public services, need full VPN functionality or invite DoS attacks with your online demeanor, a firewall type device may be more suitable.
feedback form
feedback form
by Nick edited by JMGullett
last modified: 2007-05-08 12:24:21 | | | Summary
Whilst NAT discards all unsolicited traffic received from the Internet, it does not restrict conversations initiated by the computers behind it. A software firewall (and it's user) would theoretically prevent malicious programs from initiating these 'outbound' conversations. It is worth noting that the most common type of malicious, network-aware program, the Remote Access Trojan (RAT), almost always depends upon an inbound connection from the attacker and is therefore defeated by NAT alone.
Although the threat reduction provided a software firewall employed in this scenario may be relatively small they do provide another layer of defense against certain types of malicious program and may be useful in alerting you to the presence of such.
As detailed previously, NAT discards all unsolicited traffic received from the Internet. Therefore, a software firewall watching inbound traffic would only ever see return traffic - traffic that is part of a conversation initiated by the host computer. Besides the occasional false positive (see here for an example), the software firewall will never produce any 'alerts' on inbound traffic.
So, why do people run them? Well, the advantage that a software firewall holds over hardware devices is that it can associate conversations with the program involved. A standalone NAT or firewall device has no way of determining which program is responsible for the packets it filters - it can only filter on the fields in packet headers such as ports and addresses. If an administrator were to filter all outbound connections except those destined for port 80 (http) they could not assume that the only conversations passing through the device were indeed http. Indeed, some legitimate programs (IM and P2P clients, etc) allow users to set a "firewall mode" whereby they use destination port 80 for all conversations, bypassing "pesky admins and their firewalling" (and often their security policies).
A software firewall can tell you which program is initiating conversations and most ask the user to permit or deny communications for each application, remembering and automatically applying the decision in the future. This can provide protection in the case of the inadvertant running of a malicious program which is programmed to send out your private data or connect out to somebody, offering some degree of control over your 'infected' computer. It is important to note that this protection is dependent on the user, who must decide whether or not to allow the new program to communicate. This is often the weak link, especially considering that the same user just 'chose' to run the malicious program. Making effective use of a software firewall requires some knowledge - they generate a low signal-to-noise ratio and identification of 'the signal' requires a basic familiarity with TCP/IP and the software installed on your system. As with many tools, a software firewall is only as good as it's user.
The most common type of malicious, network-aware program is the Remote Access Trojan (RAT), which typically has two components - a server which is run on the victim's computer (usually by the victim!), and a client that's used to connect to it. This type of program will be foiled by NAT alone since the client -> server connection is impossible. The only type of network-aware program NAT will not protect against is one that does not rely on an inbound connection. These are relatively rare.
A malicious program that does not depend upon an inbound connection (i.e. that connects out) would have to have the connection parameters hard-coded. This is not ideal for the attacker since the remote address (their own if they're particularly dumb) can be easily discovered. If the trojan is designed to send out private data, the location of the data would need to be hard-coded (or searched for). Therefore this type of trojan does not lend itself well to mass use - the address(es) to which it connects would eventually be found and presumably brought offline / cleaned up. Perhaps it is fair to say that this type of program would typically be used in directed, personal attacks.
Of course, there are exceptions, the most obvious being a program which connects to an Internet Relay Chat (IRC) server. This offers a degree of anonymity to the attacker but a limited interface for interacting with the programs running on 'infected' computers. An example of this type of program is some types of DDoS zombie agent. Whilst perhaps not malicious, so-called 'adware' and 'spyware' programs make outbound connections to deliver you adverts or transmit browsing statistics.
Unsurprisingly, malicious programs do not just magically appear on your hard drive and start running. In almost all cases, the victim is personally responsible for the procurement and execution of malicious code. Usually this self-harm is committed via the double-clicking of an email attachment or the download and execution of, for example, a program purporting to be a "fun game" or "cool screen saver". It's important to note that a software firewall will not stop you from acquiring or running such programs. It will only intervene if and when the program initiates a network conversation. This might be after the program has terminated the software firewall or deleted important files. It might never happen at all (perhaps the program simply formats your hard disk).
Clearly, a software firewall employed as a security measure in this scenario should only be considered as a last resort backup against the subset of malicious code that is network-aware. If your existing measures against malicious code in general (common sense included) are up to scratch, a software firewall may well be a waste of both your and your computer's resources. If they are not, you really need to make them so!
As with all security measures, the decision to run a software firewall should be based upon an evaluation of the cost / benefit ratio. A software firewall uses memory and CPU time on the host computer, requires proper configuration, frequent user interaction and often produces false positives in (usually overly dramatic) alerts and logs. However, it may someday aid an aware user in the detection of a malicious program that has evaded their other defenses and attempted to initiate a network conversation. In addition, they can be useful for control over the network activities of legitimate programs and adware / spyware annoyances. The exact value of this ratio in any particular situation is something the reader must decide for themselves.
feedback form
feedback form
by Nick
last modified: 2003-05-19 09:41:41 | | | This is almost always due to the software firewall recognizing the end of a conversation before the NAT device. As described here, the NAT device keeps a table of current conversations to facilitate translation and routing of inbound traffic. Each entry has an associated inactivity timeout. Software firewalls keep a similar table in memory and have the advantage of being able to remove entries when they detect that a program has unbound the port it was using. If a program is killed unexpectedly, this can be before the proper termination of any TCP connections the program had open (at which point the NAT device could clear its entries). The connection may just "hang" and timeout in the OS before the NAT device.
In the case of UDP, there is no "connection," and the NAT device must wait for the preset timeout to elapse before clearing entries. For this reason, the timeout on UDP entries is often much smaller than that on TCP. However, there are often significant differences between the timeout of the NAT device and that of the firewall / OS /program -- the most common inbound traffic alerts behind NAT are delayed DNS responses. Steve described this here. In this case, the reply arrives a period after the sending of the request which is greater than the firewall / OS / program timeout but less than the NAT timeout. NAT translates and routes the packet, but the firewall intercepts it and labels it an "attack" since it's table entry has been cleared.
Similarly, the occasional dribble of non-SYN flagged TCP packets are not the "TCP ACK SCAN" the firewall might insist they are. If you see SYN (just SYN) flagged TCP inbound from the WAN with a software firewall, then you might start to worry (presuming you didn't forward the relevant port and forget about it). 
feedback form
feedback form
by Nick edited by JMGullett
last modified: 2007-06-05 16:34:53 | | | This is usually accomplished via "port mappings" or "port forwards" which instruct the device to pass all unsolicited traffic received on a certain port to a host behind NAT. For example, if you wanted to allow inbound connections to a web server, you would map port 80 to the IP address of the web server.
Some devices allow for "port translated mappings," whereby the mapped port and the target port on the private host may differ. For example, if you wished to host a second web server, accessible via port 81, you could map port 81 to port 80 at the address of the second web server.
If inbound conversations to a variety of ports on a certain host are required (perhaps for a multimedia application which uses multiple conversations for video, audio, text, etc) and defining port mappings is impractical or impossible, you will need to define the address of the host to be the "DMZ" or "default server." See here for further details on this.
feedback form
feedback form
by Nick edited by JMGullett
last modified: 2007-06-05 16:40:20 | | | In the context of simple NAT routers, these terms both refer to a private address to which all unsolicited traffic will be passed. This means that the protection of NAT is removed from that computer, and external hosts can initiate conversations with it (on any port). This definition of "DMZ" conflicts with the more general definition as a section of a network between exterior and interior firewalls where publicly accessible servers are usually placed. A "real" DMZ provides separation of the servers placed within it, and the private network, a "NAT box DMZ," does not.
This feature is present in almost all NAT devices and is used where inbound connections to a range of ports are required and it is impractical or impossible to accommodate them via port mappings. Note that address translation still takes place, so this feature is not a solution to NAT incompatibilities.
feedback form
feedback form
by Nick edited by JMGullett
last modified: 2007-06-05 16:43:07 | | | Summary
Traffic encryption and integrity checking schemes such as those in the IPSec protocol suite are generally incompatible with NAT. Certain protocols, such as IPSec ESP in tunnel mode, can be accommodated via special support (IPSec pass-through).
Applications that use dynamic session initiations, such as Netmeeting and MSN Messenger, require either special support in the firmware of the NAT device or the use of UPnP and a UPnP aware NAT device.
Other NAT incompatible techniques, such as the passing of IP addresses as data or use of non-standard protocols, will also require special support.
IPSec
Sticking with security for a second, during the early days of NAT many were concerned that it would have a negative impact on security since it would not allow for end-to-end encryption. If packets are encrypted or integrity checked either translation is not possible or the translated packets are rejected. Today this is still a problem for certain traffic encryption / integrity checking schemes such as IPSec Encapsulating Security Payload (ESP) in transport mode or IPSec Authentication Header (AH). IPSec ESP in tunnel mode encrypts TCP/UDP headers but is able to traverse NAT via the following 'trick' (often referred to as IPSec pass-through):
Since the establishment of IPSec tunnels begin with IKE conversations (via UDP), when the router sees an IKE exchange it automatically forwards all ESP traffic to the private host involved. In this basic form, found in typical broadband routers, multiple concurrent tunnels are not permitted.
Some routers permit multiple IPSec connections through NAT by uniquely identifying tunnels via the pair of SPI numbers snagged from an IKE exchange. These identifying numbers are stored in IPSec NAT table entries to allow correct routing of inbound ESP traffic.
Often a better option if you have to mix NAT and IPSec is to terminate the VPN in the router. Most firewall type NAT devices can do this, which allows the entire private network access to the remote network and saves your hosts the CPU time associated with en/decapsulation, en/decryption and key management. Also, these devices are able to use the full range of IPSec features and protocols.
Dynamic Session Initiations
Dynamic session initiations are conversations, often carried out over a dedicated protocol (such as Session Initiation Protocol or SIP), which arrange the parameters (addresses, ports, etc.) for other conversations. They are roughly analogous to FTP control connections (active mode transfers are similarly broken by NAT) and are commonly used in multimedia software such as MSN Messenger and Netmeeting. Two problems arise when used over NAT:
•IP addresses are often passed as data in the session initiation. The software will pass the address of a private host to the other end and the following connection will fail.
•Ports are negotiated dynamically. You can't create port mappings to allow inbound connections to the program since you don't know what ports will be used.
The problem can be solved in one of three ways:
•Write special code to properly translate the information passed in session initiation and / or act upon special events in the conversation. This technique is used so that active FTP connections may take place where port 20 is temporarily mapped to the appropriate private host on detection of a PORT command from that host.
•Write special code to proxy (make on behalf of and intermediate) the required connections, also known as an 'Application Layer Gateway'.
•Allow a remote program to control port mappings on the NAT device and retrieve its global address to pass in session initiations. This has been realised in the form of UPnP enabled NAT devices - see here.
Note that the first two solutions involve specialised code to support each application and are therefore limited by developer inclination and available router memory space.
Note also that if IP addresses are not passed in session initiation or the problem is just that incoming connections to many ports are required, it may be solved by a feature known as 'default server' or 'DMZ'. Defining the default server or DMZ to be a private host causes the router to pass all unsolicited traffic to that host. This removes the protection of NAT from that host although translation still takes place.
feedback form
feedback form
by Nick
last modified: 2002-09-30 17:27:28 | | | File Transfers
You can receive files but not send them. Mapping the appropriate port (6891) will not improve the situation. The reason is that IP addresses are passed as data in the messages exchanged in setting up the direct, user-to-user file transfer connection. If you offer a file for download, the private address of your computer is sent to the receiver in the connection setup messages and the subsequent (inbound) connection attempt therefore fails. When receiving a file, the file transfer connection is outbound and hence, NAT poses no problems.
Other features
The other features (e.g. audio and video) use SIP and will not work through standard NAT, although outbound connections may still succeed (you may be able to hear the other end but not vice versa for example). See here for more information on this.
The fix
Messenger is UPnP aware, so if you have an UPnP aware router, Messenger can retrieve its public IP address to pass in connection setups and can also dynamically map ports on the router to permit the incoming connections. This allows all features to work as intended. See here for more UPnP information.
feedback form
feedback form
by Nick edited by JMGullett
last modified: 2007-06-05 16:45:41 | | | Maybe. See this link.
feedback form
feedback form
by Nick edited by JMGullett
last modified: 2007-06-06 13:40:53 | | | This is because each probe you send out causes the creation of a new NAT table entry, and the number of entries that can be stored in the table is finite. Since your probes are not receiving closed port replies (RST for TCP and ICMP type 3, code 3 for UDP), the entries remain in the table until their prescribed timeout period has elapsed. When the table becomes full, the router is forced to drop subsequent probes.
This means that the results of your scan will be false since probes that are sent when the table is full will not make it to the target host and will result in a "filtered" or "stealth" (or perhaps "open" in the case of UDP) report regardless of the state of the port they were directed at.
To combat this you can set a shorter table timeout for the protocol of interest if your device allows for this and send your probes slower if your scanner allows you to. You could also try asking the administrator of the target host to temporarily "un-stealth" his firewall. You do know the administrator, right?
feedback form
feedback form
by Nick edited by JMGullett
last modified: 2007-06-06 13:43:02 | | | 1. A Dedicated Device
There are many choices here, ranging from simple NAT boxes costing around $50 to full firewall-type devices.
2. Windows
Windows 98SE, ME, 2000 and XP all have connection sharing (NAT) features. These are effective but obviously require the routing PC to be powered for others to have access. XP's connection sharing / firewall is UPnP aware -- allowing UPnP aware applications to operate properly despite the use of NAT incompatible techniques, e.g. Windows Messenger and Netmeeting.
There are also many 3rd party products which offer additional features, e.g. Kerio's Winroute product line.
3. Linux
The Linux kernel has NAT functionality built in in the form of "ipchains" in the 2.2 kernel and "netfilter" in 2.4. Netfilter offers stateful packet inspection, packet matching on a wide range of fields and various modules for additional functionality. To perform NAT, one would typically use the masquerade target, although more complex configurations are possible. A Linux box based upon the 2.4 kernel makes for an extremely versatile and configurable firewall / NAT device. For UPnP support, check out this sourceforge project page.
4. Other OSs
Other Unices, such as the BSD variants and Solaris, generally have features similar to those in Linux.
feedback form
feedback form
by Nick edited by JMGullett
last modified: 2007-06-06 13:47:36 | | | The following NAT routers are known to support UPnP NAT traversal:
feedback form
feedback form
by rdhw edited by JMGullett
last modified: 2007-06-06 13:48:32 |
|
