This chapter is from the book
This chapter is from the book
This chapter is from the book
NAT Issues
Although the general applications of NAT presented so far are straightforward, the underlying functions of NAT can be less so, because of the following two factors:
The general processing of IP and TCP headers
The nature of some specific protocols and applications
Changing the content of an IP address or TCP port can change the meaning of some of the other fields, especially the checksum. And many protocols and applications carry the IP address or information based on the IP address within their data fields. Changing an IP address in the header could change the meaning of the encapsulated data, possibly breaking the application. This section examines the most common issues surrounding the operation of NAT.
Header Checksums
The checksum of an IP packet is calculated over the entire header. Therefore, if the source or destination IP address or both change, the checksum must be recalculated. The same is true of the checksum in the TCP header. This number is calculated over the TCP header and data, and also over a pseudo-header that includes the source and destination IP addresses. Therefore, if an IP address or a port number changes, the TCP checksum must also change. Cisco's NAT performs these checksum recalculations.
Fragmentation
Recall from the section "NAT and Virtual Servers" that you can use NAT to translate to different local addresses based on the destination port. A packet with a destination port of 25 can be translated to a particular IL address, for example, whereas a packet with some other destination port numbers can be translated to other addresses. However, what if the packet destined for port 25 becomes fragmented at some point in the network before it reaches the NAT? The TCP or UDP header, containing the source and destination port numbers, is in the first fragment only. If that fragment is merely translated and forwarded, the NAT has no way to tell whether the subsequent fragments must be translated.
IP makes no guarantees that packets are delivered in order. So it's quite possible that the first fragment might not even arrive at the NAT before later fragments. You must design NAT to handle such eventualities.
Cisco's NAT keeps stateful information about fragments. If a first fragment is translated, information is kept so that subsequent fragments are translated the same way. If a fragment arrives before the first fragment, the NAT has no choice but to hold the fragment until the first fragment arrives and can be examined.
Encryption
Cisco's NAT can change the IP address information carried within the data fields of many applications, as you will see shortly. If the data fields are encrypted, however, NAT has no way of reading the data. Therefore, for NAT to function, neither the IP addresses nor any information derived from them (such as the TCP header checksum) can be encrypted.
Another concern is virtual private networks (VPNs) using, for example, IPSec. With certain modes of IPSec, if an IP address is changed in an IPSec packet, the IPSec becomes meaningless and the VPN is broken. When any sort of encryption is used, you must place the NAT on the secure side rather than in the encrypted path.
Security
Some view NAT as a part of a security plan, because it hides the details of the inside network. A translated host may appear on the Internet one day with one address and on another day with a different address. But this should be considered very weak security at best. Although NAT might slow an attacker who wants to hit a particular host, forcing him to play a sort of shell game with IP addresses, it will not stop any determined and knowledgeable aggressor. And worse, NAT does nothing to prevent such common attacks as denial of service or session hijacking.
Protocol-Specific Issues
NAT should be transparent to the end systems that send packets through it. However, many applications—both commercial applications and applications that are part of the TCP/IP protocol suite—use the IP addresses. Information within the data field may be based on an IP address, or an IP address itself may be carried in the data field. If NAT translates an address in the IP header without being aware of the effects on the data, the application breaks.
Table 4-1 lists the applications that Cisco's NAT implementation supports. For the applications listed as carrying IP address information in the application data, NAT is aware of those applications and makes the appropriate corrections to the data. Note that the table is current as of this writing. If you are implementing NAT, you should check the Cisco Web site or TAC for application support that might have been added recently.
Table 4-1 IP Traffic Types/Applications Supported by Cisco NAT2
|
Traffic Types/Applications Supported |
|
Any TCP/UDP traffic that does not carry source and/or destination IP addresses in the application data stream |
|
HTTP |
|
TFTP |
|
Telnet |
|
archie |
|
finger |
|
NTP |
|
NFS |
|
rlogin, rsh, rcp |
|
Traffic Types/Applications Supported with IP Addresses in Their Data Stream |
|
ICMP |
|
FTP (including PORT and PASV) |
|
NetBIOS over TCP/IP (datagram, name, and session services) |
|
Progressive Networks' RealAudio |
|
White Pines' CuSeeMe |
|
Xing Technologies' StreamWorks |
|
DNS A and PTR queries and responses |
|
H.323/NetMeeting [12.0(1)/12.0(1)T and later] |
|
VDOLive [11.3(4)/11.3(4)T and later] |
|
Vxtreme [11.3(4)/11.3(4)T and later] |
|
IP Multicast [12.0(1)T] (source address translation only) |
|
Traffic Types/Applications Not Supported |
|
Routing table updates |
|
DNS zone transfers |
|
BOOTP |
|
talk, ntalk |
|
SNMP |
|
NetShow |
ICMP
Some ICMP messages include the IP header of the packet that caused the message to be generated. Table 4-2 lists these message types. Cisco's NAT checks the listed message types; if IP information in the message matches a translated IP address in the header, the NAT also translates the IP information. Additionally, the checksum in the ICMP header is corrected in the same way it is corrected for TCP and UDP.
Table 4-2 ICMP Message Types That Carry IP Header Information in the Message Body
|
Message |
Type Number |
|
Destination Unreachable |
3 |
|
Source Quench |
4 |
|
Redirect |
5 |
|
Time Exceeded |
11 |
|
Parameter Problem |
12 |
DNS
One of the core functions of any TCP/IP internetwork, and especially of the Internet, is the Domain Name System (DNS). If systems cannot get DNS queries and responses across a NAT, DNS can become complicated. Figure 4-11 shows ways you can implement DNS servers around a NAT that cannot translate DNS packets.
){kind=link}
The NAT in Figure 4-11 translates in both directions—outside hosts are made to appear to the inside as if they are on the 10.0.0.0 network, and inside hosts are made to appear to the outside as if they are on the 204.13.55.0 network. DNS servers reside on both the inside and the outside, and each contains resource records that map names to the addresses appropriate for its side of the NAT.
Figure 4-11 If NAT Does Not Support DNS, Name Servers Must Be Implemented on Both Sides of the NAT, Reflecting the Name-to-Address Mappings Appropriate for That Side of the NAT
A problem with this approach is the difficulty of maintaining inconsistent resource records on the two DNS servers. A more serious problem is that the NAT mappings must be static, to match the mappings in the DNS resource records. Pooled NAT does not work, because the mappings change dynamically. A better approach, and one that is supported by Cisco's implementation of NAT, is to have the NAT support translation of DNS queries.
Although a detailed examination of DNS operations is beyond the scope of this book, a short review of the key concepts will help you understand where DNS can coexist with NAT and where it cannot. You are familiar with the structure of domain names; for example, the name cisco.com describes a second-level domain (cisco) under the top-level domain com. All the IP namespace is organized in a tree structure, with host names connected to increasingly higher-level domains, until all domains meet at the root.
NOTE
An excellent text on DNS is Paul Albitz and Cricket Liu's DNS and BIND (O'Reilly and Associates, 1992).
Name servers store information about some part of the domain namespace. The information in a particular name server may be for an entire domain, some portion of a domain, or even multiple domains. The portion of the namespace for which a server contains information is the server's zone.
DNS servers are either primary or secondary servers. A primary DNS server acquires its zone information from files stored locally in the host on which the server is running and is said to be authoritative for its zone. A secondary DNS server acquires its zone information from a primary DNS server. It does this by downloading the zone files of the primary in a process called a zone transfer.
Because a zone transfer is a file transfer, a NAT cannot parse the address information out of the file. Even if it could, zone files are often very large, which would put a significant performance burden on the NAT device. Therefore, a primary and secondary DNS server for the same zone cannot be located on opposite sides of a NAT, because the information in zone files will not be translated during a zone transfer.
The information within zone files is made up of entries called resource records (RR). There are several types of resource records, such as Start-of-Authority (SOA) records, specifying the authoritative server for the domain; Canonical Name (CNAME) records, for recording aliases; Mail Exchange (MX) records, specifying mail servers for a domain; and Windows Internet Name Server (WINS) records, used in some Windows NT name servers. The two RRs of importance to NAT are Address (A) records, which map host names to IP addresses, and Pointer (PTR) records, which map IP addresses to names. When a host must find an IP address for a particular name, its DNS resolver queries a DNS server's A records. If the host wants to find a name that goes with a particular IP address (a reverse lookup), it queries the server's PTR records.
Figure 4-12 shows the format of a DNS message, which carries both the queries from hosts and the responses from servers. The header, like most headers, is a group of fields carrying information for the management and processing of the message. The header information significant to NAT includes a bit specifying whether the message is a query or a response, and fields specifying the number of RRs contained in each of the other four sections.
){kind=link}
Figure 4-12 The DNS Message Format
The Question section is a group of fields that, as the name clearly indicates, asks a question of the server. Among other things, the question may contain a name to which the server must try to match an address out of its A records, or the question may contain an address to which the server must try to match a name from its PTR records. Every DNS message contains a question, and a message never contains more than one question.
The Answer section contains RRs that, of course, answer the question. The answer may list one or many RRs, or none at all. The Authority and Additional sections contain information that is supplemental to the answer, and may also be empty.
When a DNS packet passes through a Cisco NAT, the Question, Answer, and Additional sections are examined. If the message is a query for an IP address to match a name, no addresses are yet included, and the Answer and Additional sections are empty, so no translation takes place. The response to the query, however, contains one or more A RRs in the Answer section and possibly in the Additional section. NAT searches its table for a match to the address in these records and translates the addresses in the message if it finds a match. If it does not find a match, the message is dropped.
If the DNS message is a query for a name to match a known IP address (a reverse lookup), NAT examines its table for a match to the address in the Question section. Again, either a match is found and the address is translated, or the message is dropped. The response to the query contains one or more PTR RRs in the Answer section and possibly in the Additional section, and the addresses in these records also are either translated or the message is dropped.
In summary, remember the following two facts when working with DNS and NAT:
DNS A and PTR queries can cross a Cisco NAT, so a host on one side of a NAT can query a DNS server on the other side of the NAT.
DNS zone transfers cannot cross a Cisco NAT, so primary and secondary DNS servers for the same zone cannot reside on opposite sides of the NAT.
FTP
The File Transfer Protocol (FTP) is something of an unusual application protocol in that it uses two connections (see Figure 4-13). The control connection is initiated by the host and is used to exchange FTP commands with the server. The data connection is initiated by the server and is used for the actual file transfer.
){kind=link}
Figure 4-13 An FTP Session Consists of Two Separate TCP Connections; the Host Initiates the Control Connection, and the Server Initiates the Data Connection
The sequence of events for setting up an FTP session and transferring a file is as follows:
The FTP server performs a passive open (that is, begins listening for a connection request) on TCP port 21, the control port.
The host selects ephemeral (temporary) ports for the control connection and for the data connection. In Figure 4-13, these are ports 1026 and 1027, respectively.
The host performs a passive open on the data port.
The host performs an active open for the control connection, creating a TCP connection between its control port (1026 in Figure 4-13) and the server's port 21.
To transfer the file, the host sends a PORT command across the control connection, telling the server to open a data connection on the host's data port (1027 in Figure 4-13).
The server performs an active open for the data connection, creating a TCP connection between its port 20 and the host's data port.
The requested file is transferred across the data connection.
This sequence of events presents a problem for some secured networks. Specifically, it is a common security practice to configure a firewall or access list to disallow the initiation of connections from the outside to random ports. This is done by looking for a cleared ACK or RST bit in the TCP header, indicating a connection request. You can see that when the FTP server tries to establish a connection to the host's ephemeral port across such a firewall, the connection is denied.
NOTE
The established keyword tells a Cisco access list to look for a cleared ACK or RST bit in the TCP header.
To overcome this difficulty, the host can issue a PASV command rather than a PORT command to open the data connection. This command asks the server to passively open a data port and to inform the host of the port number. The host then performs the active open of the data connection to the server port. Because the connection request is outgoing through the firewall rather than incoming, the connection is not blocked.
The significance of all this to NAT is that the PORT and PASV commands carry not only the port numbers but also the IP addresses. If the messages cross a NAT, these addresses must be translated. To make matters worse, the IP address is encoded in ASCII in its dotted-decimal form. This means that the IP address in the FTP message is not of a fixed length, as it would be if it were a 32-bit binary representation. For example, the address 10.1.5.4 is eight ASCII characters (including the dots), whereas 204.192.14.237 is 14 ASCII characters. So when the address is translated, the message size can change.
If the size of the translated FTP message remains the same, the Cisco NAT recalculates only the TCP checksum (in addition to any operations performed on the IP header). If the translation results in a smaller message, the NAT pads the message with ACSII zeros to make it the same size as the original message.
The problem becomes more complicated if the translated message is larger than the original message, because the TCP sequence and acknowledgment numbers are based directly on the length of the TCP segments. Cisco's NAT keeps a table to track the changes in SEQ and ACK numbers. When an FTP message is translated, an entry is made into the table containing the source and destination IP addresses and ports, the initial sequence number, the delta for the sequence numbers, and a time stamp. This information is used to correctly adjust the SEQ and ACK numbers in the FTP messages. It can be deleted after the FTP connection is closed.
SMTP
Simple Mail Transfer Protocol (SMTP) messages normally contain domain names, not IP addresses. However, they can use IP addresses rather than names when requesting mail transfers. Therefore, Cisco NAT examines the appropriate fields within SMTP messages and makes translations when IP addresses are found.
Unlike SMTP, which is used for uploading mail and for transferring mail between servers, the Post Office Protocol (POP) and the Internet Message Access Protocol (IMAP) are used only for downloading messages from a mail server to a client. Both protocols use only host names, never IP addresses, within the message bodies. Therefore, these protocols do not require special examination when crossing a NAT.
SNMP
Simple Network Management Protocol (SNMP) uses a rich and widely varying set of Management Information Bases (MIBs) to manage a wide variety of networking devices. In addition to the many Internet-standard MIB groups, a vast number of private MIBs have been created for the management of vendor-specific devices.
You can deduce from this very basic description that many MIBs can contain one or more IP addresses. Because of the many messages, formats, and variables possible with SNMP, NAT cannot easily examine the contents of an SNMP message for IP addresses. Therefore, NAT does not support the translation of IP addresses within SNMP messages.
Routing Protocols
IP routing protocols present something of the same problem presented by SNMP. There are many IP routing protocols, each with its own packet formats and its own operational characteristics. Therefore, NAT cannot translate IP routing protocol packets. A NAT router can run a routing protocol on the inside interfaces and a routing protocol on the outside interfaces, but no routing protocol packets should transit a NAT boundary in which the advertised addresses change, either through a single protocol or by redistribution. This restriction does not present much of a problem, because NAT routers will be located on the edge of a routing domain, and therefore can usually use a default address or a small set of summary addresses.
Traceroute
Route tracing utilities can vary somewhat. Some, such as Cisco's trace command, use ICMP packets. Others, such as tracert under Microsoft Windows 95, use UDP packets. But the basic functionality is the same: Packets are sent to a destination with an incrementally increasing TTL, and the addresses of the intermediate systems sending ICMP Time Exceeded error messages are recorded. You saw in the earlier section on ICMP that Time Exceeded messages are translated by Cisco NAT, so routes can be traced through NAT.
The NAT in Figure 4-14 is translating in both directions. The router jerry.insidenet.com has an IP address of 10.1.16.50 and is translated to an IG address of 204.13.55.6. The device berferd.outsidenet.com has an address of 147.18.34.9 and is translated to an OL address of 10.2.1.3. Therefore, the OL address is the address by which jerry knows berferd.
){kind=link}
Figure 4-14 NAT Is Translating in Both Directions
When jerry performs a trace to berferd, the destination is 10.2.1.3. Example 4-3 shows that the first hop is the NAT router. The NAT then translates the destination address to 147.18.34.9 and the source address to 204.13.55.6 and forwards the packet out its outside interface. When berferd receives the trace packet, which is sent to a bogus port, it responds with an ICMP Port Unreachable error packet. That packet has a destination of 204.13.55.6 and a source of 147.18.34.9. NAT translates these addresses to a destination of 10.1.16.50 and a source of 10.2.1.3, which is what jerry receives. Therefore, the trace is successful, but the inside device sees only the outside local address.
Example 4-3 A Trace from jerry.insidenet.com to berferd.outsidenet.com in Figure 4-14 Shows That the Trace Is Successful, and NAT "Hides" the Outside Global Address from the Inside
Jerry#trace berferd.outsidenet.com Type escape sequence to abort. Tracing the route to berferd.outsidenet.com (10.2.1.3) 1 10.1.255.254 8 msec 8 msec 4 msec 2 berferd.outsidenet.com (10.2.1.3) 12 msec * 8 msec Jerry#