Network Address Translator (NAT) Theory and Troubleshooting
Articles and Tips: article
Worldwide Support Engineer
Novell BorderManager
01 Mar 1998
Delve into the inner workings of NAT, a feature of Novell BorderManager that permits an almost unlimited number of network users to access the Internet using only one class C IP address.
- Introduction
- Theory of Operations
- NAT Table Contents
- Troubleshooting Dynamic Problems
- Troubleshooting Static Problems
- Summary
Introduction
One problem with the attachment of existing IP Networks to the Internet (public network) is that local hosts must have globally unique addresses in order to be identified by the backbone routers of the Internet. These Internet backbone routers will not route IP packets if the IP addresses processed in the incoming packet are not registered and unique. End-users connected to hosts with duplicate addresses cannot be reached and cannot establish application sessions.
The Network Address Translator (NAT - RFC1631) solves this problem by reassigning IP addresses and port numbers. It contains a pool of available ports so that one public IP address may be constantly reused. Note that the private IP Network addresses are allocated according to "internal" considerations of the Network, and RFC1918 provides a number of guidelines on how to select and allocate these IP addresses.
The overall result is that NAT permits an almost unlimited number of users of one class C Network address because global addresses are required only when a user is connected to the Internet.
NAT also enhances the level of security within the network by hiding its internal structure. Public hosts have no way of determining the private addresses or topologies as they only see the public IP addresses in the IP header.
Finally, when an existing IP Network with its own addressing scheme needs to be attached to a public IP network, there is no need to replace the IP address of each and every host on the internal net the task is accomplished by the NAT.
Theory of Operations
The two principle NAT modes of operation are:
Dynamic NAT Mode—When a host on the "private" network sends an IP packet to the public network via the NAT, the NAT keeps track of the actual "private" address of that host, but substitutes the assigned "public" address into the IP packet before it is sent into the public network. When a reply comes back from the public network, the NAT restores the actual address before sending the reply to the host. Nothing originating from the "public" network can get through to the "private" network in this mode.
Static NAT Mode—The NAT can provide support for servers in the "private" network that need to be "seen" from the "public" network. Using this feature one could have a Web or FTP server located on the private network, using an illegal IP address, and still allow public clients access these services.
Dynamic NAT Mode
The following is a sample environment which describes how NAT handles a TELNET request from a private host (10.0.0.1) to a TELNET server on the public network. The private hosts lie on the 10.0.0.0 network and the TELNET server is running on public host 130.57.52.13. The NAT router should have two interfaces with IP addresses assigned to them. The private interface has an IP address (10.0.0.2), and the public interface has an IP address (130.57.199.8) assigned. NAT is configured on that public interface in dynamic mode only.
Operational steps (refer to Figure 1 for corresponding steps):
Figure 1: A Sample Dynamic NAT Mode environment
The Private Host 10.0.0.1 opens a connection to a server on the public network (130.57.52.13). This public server may be any UDP/TCP based server—in our example, a TELNET (TCP based) connection to the public server was established.
The first packet that the NAT-enabled router receives from the private host (10.0.0.1) that needs to be forwarded out the NAT interface causes the router to check its NAT table. Note that the private interface in the NAT-enabled router must be configured as the default router for all private hosts trying to access the public network. In other words, all packets from the private network destined for the public network must go through this NAT-enabled router.
NAT looks at the source IP address of this incoming packet to check if an entry exists for that specific IP address in the NAT table. If no entry is found in the table, a new entry will be added. Once done, NAT routines will do the port mapping and modifying of source IP address.
With our specific example above, the router, seeing that the "next hop" to the destination is the NAT-enabled interface, determines that the private IP address must be translated. Since we are in dynamic mode, NAT will translate the private IP address to a legal configured public address, for example, the IP address bound to the NAT-enabled interface (IP address 130.57.199.8 in our case).
The router replaces the private source IP address of 10.0.0.1 with the NAT-enabled public IP address (130.57.199.8) and forwards the packet to its destination, 130.57.52.13. More important, the source TCP port is also replaced from 1024 to 55002—this port translation will be used later to route the responding packet back to the correct originator (10.0.0.1).
130.57.52.13 receives the packet and replies to the private host 10.0.0.1 by using the NAT-enabled public address as its destination address (130.57.199.8).
When the NAT router receives the reply destined to its publicly configured IP address (130.57.199.8), it performs a NAT table lookup. NAT takes the destination IP address of the incoming packet and checks its table to see if an entry exists. Once an entry is found it uses the destination port of the incoming packet to remap the port and destination IP address. In our specific example above, the NAT router translates the destination IP address back to the corresponding private IP address of 10.0.0.1 based on the PORT number, and forwards the packet to the private host 10.0.0.1.
The private host 10.0.0.1 receives the packet and continues the conversation. The router performs Steps 2 through 5 for each packet.
Static NAT Mode
This sample environment described below, shows how NAT translates virtual public addresses (on 130.57.196.0 network) to private IP addresses (on the 10.0.0.0 network). Note that no PORT translation takes place in static mode. The NAT router should have two interfaces with IP addresses assigned to them. The private interface has an IP address (10.0.0.2), and the public interface has an IP address (130.57.199.8) assigned. NAT is configured on the public interface in static and dynamic mode. Two secondary addresses are also added to the public interface (130.57.199.13, 130.57.199.14) to use with NAT.
Static mode is required when a host on the private network needs to be accessed by hosts on the public networks.
Operational steps (refer to Figure 2 for corresponding steps):
Figure 2: A Sample Static Mode environment.
The router takes the following steps when communicating in static mode:
The user on Host B (130.57.52.13) opens a connection to virtual host at 130.57.199.13. This IP address (130.57.199.13) is a secondary IP address bound to the public NAT-enabled interface and is statically mapped to the private host (10.0.0.1) we will open the session to (see "Static Mode Setup" section later on for configuration details).
The NAT router receives the connection request and checks the contents of its translation table to see if an entry for that destination address exists. If it does, the NAT routine determines that destination address (130.57.199.13) must be translated; it then sets up a translation of virtual public IP address (130.57.199.13) to a private IP address of the internal host needing to be accessed (10.0.0.1).
The router replaces the virtual destination address (130.57.199.13) with the translated private host IP address (10.0.0.1) and forwards the packet to that node on the private network.
The private host (10.0.0.1) receives the packet and responds; the destination IP address in the response being the public IP address (130.57.52.13) that initiated the original connection request.
The router receives the packet, performs a NAT table lookup using the private IP address. The router then translates the source address (10.0.0.1) to the address of the virtual host (130.57.199.13) and forwards the packet.
NAT Table Contents
Each time an incoming or outgoing packet travels through the NAT interface, a call is made to read the NAT table entries. Every entry in the Network Address Translation table contains the following attributes:
The Public IP address, which is the IP address of the IP host on the public network.
The Private IP address, which is the IP address of the IP host on the private network.
The Type of Association entry (Dynamic or Static), which describes whether the entry in the NAT table is a static entry or whether it has been dynamically learned by NAT, when configured to run in dynamic mode.
Pointer to a link list of ICMP sessions. The ICMP Session table contains the ID mappings necessary for the dynamic addressing of ICMP packets. This ID field will provide the differential factor in deciding which private host will receive the incoming packet from the public network, since all incoming packets will have the same destination IP address. The TCP/IP module will reserve 5000 IDs starting at ICMP ID 55000.
Pointer to a link list of UDP sessions. The UDP Session table contains the port-mapping information necessary for the dynamic addressing of UDP packets (as NAT in dynamic mode is a "many to one" address mapping, the port number is used to distinguish the destinations of private host packets coming from the public network). The TCP/IP module will reserve 5000 ports starting at UDP port 55000. Each entry in this table is associated with one of the 5000 ports (for example, the first entry is for port 55000, the second 55001, and so on).
Pointer to a link list of TCP connections. The TCP Connection table contains the port mapping information necessary for the dynamic addressing of TCP packets and for the static address processing of FTP TCP packets associated with connections initiated from the private network. As with UDP and ICMP, the TCP/IP stack will also reserve 5000 TCP ports starting at 55000.
The TCP table has the same information as the UDP table, plus some additional fields:
The state flag will be used for the processing of TCP state, i.e., FIN seen from private network, FIN seen from public network, etc.
A time stamp will contain the time of last access. This will be used to determine if a connection is alive. It will only be used if the TCP table is full and a new entry is required. A routine will search for a connection that has not been accessed for 24 hours. If it finds one, this entry will be used as the new entry and all of the old associations will be cleaned up in the Host table.
Configuration
All configuration is carried out by INETCFGon the NAT router. The only option for NAT is found under the TCP/IP|BINDINGS section where we must specify the NAT mode of operation for the IP interface: dynamic, static, both, or neither (see Figure 3).
Figure 3: Using INETCFG to modify the NAT Table.
Dynamic Mode Setup. All relevant information is written to the NETINFO.CFGand TCPIP.CFGfiles found in the SYS:\ETC directory.
NETINFO.CFGspecifies that TCP/IP must be loaded with the "FORWARD=Yes" option-enabled, and that the BINDING of IP to LAN/WAN cards are enabled. The relevant IP/NAT information in NETINFO.CFGis shown as follows:
#!BEGINPROTO PROTO=TCPIP STATUS=ENABLED LOAD Tcpip RIP=Yes Static=Yes LoadSharing=No Forward=Yes # #!BEGINBIND STATUS=ENABLED BIND IP NE2000_2_EII ARP=Yes Bcast=ff.ff.ff.ff Mask=ff.ff.ff.c0 Address=10.0.0.2 #10.0.0.2 #!END #!BEGINBIND STATUS=ENABLED BIND IP NE2000_EII ARP=Yes Mask=ff.ff.fc.0 Address=130.57.199.8 #130.57.199.8
TCPIP.CFGspecifies the NAT mode of operation. All relevant NAT information found in TCPIP.CFG is shown as follows:
Interface {
Address 130.57.199.8
Port NE2000_EII
Type lan
RouterDiscovery no
SolicitationAddress multicast
NATStatus Dynamic
}
When IP users are trying to access any services running on the NAT-enabled router (for example, VPN, Proxy, FTPSERV, HTTP), on a NAT server running in dynamic mode, the following SET command must be enabled at the server console:
SET NAT DYNAMIC MODE TO PASS THRU = ON
When this SET command is enabled, NAT goes through the same logic of processing data. However, instead of NAT discarding the data it cannot process (for local packets in Dynamic mode, for example) NAT makes additional checks to see if the destination (upon receiving a packet) or source (upon sending a packet) IP address is one of the local IP addresses. If it is one of the local IP addresses, NAT simply lets the packet pass through and does not discard it.
If using NAT on a WAN multi-access interface (with the NIAS component of Border Manager) make sure that a static route is defined in the WAN call for each of the remote networks. This is because only one default route is active at a time in the IP routing table. With multi-access setups, and the possibility of having multiple calls to different destinations at the same time, only one of the interfaces can be the default route. If other calls exist on different interfaces, a static route for the remote networks must be defined.
The NAT-enabled interface should be configured with RIP receive only, so the router will not be advertising private routes to the public network. This option is available by loading the INETCFG module and selecting "BINDINGS" for the public IP interface -> "RIP Bind Options" -> "RIP Mode".
Static Mode Setup. All relevant information is also written to the NETINFO.CFGand TCPIP.CFGfiles found in the SYS:\ETCdirectory.
NETINFO.CFGspecifies that TCP/IP must be loaded with the /FORWARD=Yes option-enabled, and that the binding of IP addresses to LAN/WAN cards are enabled (exactly as with dynamic NAT mode described above).
TCPIP.CFGspecifies the NAT mode of operation. Here is the relevant NAT information in TCPIP.CFG:
Interface {
Address 130.57.199.8
Port NE2000_EII
Type lan
RouterDiscovery no
SolicitationAddress multicast
NATStatus Static
PubAddress 130.57.199.13
PrvAddress 10.0.0.1
PrvMask 255.255.0.0
}
}
We need a valid public IP address for each private/public IP address pair defined in the static NAT address mapping table. Since we only have one IP address bound to the public interface by default, we need to use the following console command to add more IP addresses to that interface:
ADD SECONDARY IPADDRESS X.X.X.X
where X.X.X.Xis a secondary public IP address that needs to be on the same IP network as the primary IP address bound. To display the secondary IP addresses associated with an interface, type:
Display secondary ipaddress
There is no hardcoded limit to the number of secondary IP addresses that one can configure. The only limit is related to memory every newly assigned address uses up 8 Bytes of memory. Note that this console SET command is for LAN interfaces only, and not WAN interfaces WAN interfaces do not support the ARP protocol.
NAT may have problems handling fragmented IP packets in cases where the first fragment is not processed first. The problem is in dynamic mode when fragments arrive in random order (for example, frag2, frag1, frag0). If frag0 of a packet arrives first, followed by other random ordered fragments, then NAT will handle it properly. Basically, NAT remembers the first fragment of a packet because it contains transport header info that NAT looks for all other fragments do NOT contain a transport header, but are processed based on the IP flag and fragmentation off-set field entries. Fragments other than frag0 will be searched by NAT for a matched frag0. If one can be found, translation continues; otherwise that fragment is discarded. Applications however should detect missing information and retransmit any "lost" packets.
In cases where we may be encountering such issues, there are certain steps one can perform to overcome possible fragmentation. If working with TCP based applications, try to force the maximum segment size to a value where the TCP packets being sent out the LAN/WAN interface correspond to the minimum MTU size of your network topology. With TCPIP.NLM, this may be achieved by setting the following command:
SET use specified MTU = ON SET maximum interface MTU =<minimum Network MTU size<
For example, if your network contains token ring and ethernet segments, make sure that the "SET maximum interface MTU" command is set to 1500.
For UDP-based applications, verify whether an application level parameter exists to modify the size of the application data sent to UDP.
The static NAT interface should be configured with RIP receive only, so the router will not be advertising private routes to the public network. This option is available by loading the INETCFG module and selecting "BINDINGS" for the public IP interface -> "RIP Bind Options" -> "RIP Mode".
Troubleshooting Dynamic Problems
Verify that you can PING the local/private interface in the NAT router (using standard IP troubleshooting techniques) from a private client. If this fails:
Check local hardware/cabling.
Verify that the TCPIP stacks (on client and server) are correctly configured and enabled. Make sure that the default route on the clients point towards the NAT router (use "netstat -r" on Windows 95/NT clients to check for 0.0.0.0 entry with a next hop going to the NAT router, or another router with a route to the NAT router), and that the NAT routers IP routing table (using TCPCON) contains an entry for the network where the clients are located. This is pure IP troubleshooting and independent of NAT.
Verify that the IP ARP tables on both the IP client and server contain the correct IP-MAC address mappings for each other or the next hop router when talking to one another. On a Windows 95/NT box, use "arp -a" to view the table contents. On a Netware server, load TCPCON and select "Protocol Information"-> "IP" -> "IP Address Translation" to view table entries.
Verify that you can PING the NAT-enabled (public) interface in the NAT router from a private client. If this fails:
Make sure the NAT router is the default gateway when accessing the Internet/ public network. All packets going from the private network to the public network should go through the Nat router.
Make sure IP routing is enabled. To verify, "load TCPCON" and make sure that the "Protocol Information" -> "IP" -> "IP Packet Forwarding" field is set to "Router".
Verify that IP packet filtering is not enabled to block incoming or outgoing ICMP (PING) packets on the private interface. This can be achieved by doing a "SET TCP IP DEBUG=1" at the server console and making sure that no incoming or outgoing "DISCARD" messages appear at the server console.
Verify that you can PING all remote public servers from the private client. If this fails:
Make sure the IP routing table on the NAT router contains an entry for the remote network you are trying to PING, or a default route entry pointing to a next hop router that contains an entry for the remote network we're trying to access. To verify, "load TCPCON" and make sure that the "IP Routing Table" includes the above mentioned entries.
Use "SET TCP IP DEBUG=1" to verify that the conversion is taking place. The easiest way of capturing the output of the SET command is to load the CONLOG.NLM before a test and then unload it immediately afterwards.
Make sure that NAT is not enabled on more than one interface that can be used to reach the same public host. (Do not create a routing loop for a remote network through NAT.)
Use IPTRACE to verify that the correct path to the destination is taken, using your network layout to verify where the path fails.
Verify that IP packet filtering is not enabled to block incoming or outgoing ICMP (PING) packets on the private interface. This can be achieved by doing a "SET TCP IP DEBUG=1" at the server console and making sure that no incoming or outgoing "DISCARD" messages appear at the server console, or checking that the problem doesn't occur when IPFLT.NLM is unloaded.
Here's a sample CONSOLE.LOG output when private host 10.0.0.1 tries to PING public IP address 130.57.52.13 through the NAT-enabled interface 130.57.199.8 (see Figure 1 for setup):
CONLOG-1.03-10: System console logging started Mon Jun 23 14:31:14 1997. CONLOG-1.03-9: Logging system console to sys:etc\console.log. SJF-TS-MICK:set tcp ip debug=1 Tcp IP Debug is ALREADY set to 1 RECEIVE:pktid:768 10.0.0.1-$gt;130.57.52.13 ttl:60 (ICMP) (ICMP): Echo Request FORWARD:pktid:768 130.57.199.8->130.57.52.13 ttl:59> (ICMP) /* address translation successful */
Get LANalyzer/Sniffer output on both sides of the NAT router (on private and public network) to verify that the translations at the IP and transport layers have taken place correctly.
Example LZFW output on Private network:
No. Source Destination Layer Size Summary === ====== =========== ===== ==== ======= 3 FTPCLNT NAT_PRIV tcp 0064 Port:1027 ---> FTP SYN > 4 NAT_PRIV FTPCLNT tcp 0064 Port:FTP ---> 1027 ACK SYN> 5 FTPCLNT NAT_PRIV tcp 0064 Port:1027 ---> FTP ACK > 6 NAT_PRIV FTPCLNT ftp 0148 Reply:(Service ready for new user) 7 FTPCLNT NAT_PRIV tcp 0064 Port:1027 ---> FTP ACK > 8 FTPCLNT NAT_PRIV ftp 0073 Command=USER(User Name) 9 NAT_PRIV FTPCLNT tcp 0064 Port:FTP ---> 1027 ACK > 10 NAT_PRIV FTPCLNT ftp 0088 Reply:(User logged in, proceed.) 11 FTPCLNT NAT_PRIV tcp 0064 Port:1027 ---> FTP ACK >
The TCP source port for the connection is 1027. Since NAT running in dynamic mode uses the PORT number to map the public IP address to the private IP address, we should see this field change in the trace taken on the public segment.
Example LZFW output on Public network:
No. Source Destination Layer Size Summary === ====== =========== ===== ==== ======= 4 NAT_PUB FTPSRV tcp 0064 Port:55001 ---> FTP SYN 5 FTPSRV NAT_PUB tcp 0064 Port:FTP ---> 55001 ACK SYN 6 NAT_PUB FTPSRV tcp 0064 Port:55001 ---> FTP ACK 7 FTPSRV NAT_PUB ftp 0147 Reply:(Service ready for new user 8 NAT_PUB FTPSRV tcp 0064 Port:55001 ---> FTP ACK 9 NAT_PUB FTPSRV ftp 0073 Command=USER(User Name) 10 FTPSRV NAT_PUB tcp 0064 Port:FTP ---> 55001 ACK 11 FTPSRV NAT_PUB ftp 0088 Reply:(User logged in, proceed.) 12 NAT_PUB FTPSRV tcp 0064 Port:55001 ---> FTP ACK
The source IP address is the IP address of the public interface in the NAT-enabled router, as opposed to the IP address of the FTP client that originated the request.
The connection arrives at the FTP server with a source TCP port number of 55001. The TCP/IP module will reserve 5000 ports starting at TCP port 55000. Each entry in this table is associated with one of the 5000 ports (for example, the first entry is for port 55000, the second 55001, as so on). In our case, the mapping between port 55001 and 1027 will be used to translate the IP address from the NAT-enabled public IP address to the private IP address of the host initiating the connection.
Verify that all applications work correctly.
Make sure the "SET NAT DYNAMIC MODE TO PASS THRU = ON" is set if local applications on NAT server are not accessible. If this is not set, the incoming requests will NOT get forwarded to the local application residing on that host.
+ Check if the problem is specific to one application or all applications.
Do TELNET, FTP, HTTP (TCP based apps) all fail? If HTTP is failing on the host, does an XCONSOLE/TELNET session to the same host also fail?
Is FTP running in active or passive mode?
Do SNMP, DNS, TFTP (UDP based apps) all fail?
Use SNMP to get as much info as possible. (This involves loading TCPCON and verifying IP fragmentation issues, local IP errors, ICMP, TCP or UDP errors in the "Statistics" field.)
+ Check if the problem is specific to one remote host, or all remote hosts.
Check if the issue is timeout related. The overhead required to recalculate new checksums may be such that application layer timeouts need to be increased. To verify timeout issues, load the TCPCON utility, and select "Statistics" -> "TCP" and verify if the "retransmitted segments" field is increasing.
Check that the available cache buffers are high enough to handle all sessions. This can be done by verifying that the "Cache Buffers" field in the MONITOR module under "Resource Utilization" is greater than 40%.
Verify that IP packet filtering is not enabled to block incoming or outgoing ICMP (PING) packets on the private interface. This can be achieved by doing a "SET TCP IP DEBUG=1" at the server console and making sure that no incoming or outgoing "DISCARD" messages appear at the server console, or checking that the problem doesn't occur when IPFLT.NLM is unloaded.
Get LANalyzer/Sniffer output on both sides of the NAT router to verify the state of the TCP/UDP requests and responses during client/server communication.
Troubleshooting Static Problems
If you want the NAT router to be able to access outside and inside, make sure to have its address in the static address pair of the NAT's address mapping. Use the "ADD SECONDARY IPADDRESS X.X.X.X" command to add addresses that may be used in the public address portion of the static NAT address mapping pair. Use "DISPLAY SECONDARY IPADDRESS" to check the IP binding. If you automate this procedure by adding the "ADD SECONDARY IPADDRESS" command to the AUTOEXEC.NCF, make sure that it is executed after the TCPIP.NLM has been loaded, as all required symbols are not exported until TCPIP.NLM is loaded.
Verify that you can PING the NAT-enabled interface in the NAT router:
The secondary IP address has been succesfully added (use "display secondary ipaddress" to verify that the added secondary ip address has been successfully registered).
Make sure the IP routing table entries are correct. Load the TCPCON module and verify that the "IP Routing Table" option contains an entry for the "default route" or the network address of the host that is trying to communicate with us.
Make sure that IP packet filtering is not enabled to block the incoming ICMP request, or outgoing ICMP response. Use "SET TCP IP DEBUG = 1" to verify that no packets are being "discarded" by the TCPIP stack.
Verify that you can PING all private hosts being made accessible to the public:
Make sure IP routing is enabled. To verify, "load TCPCON" and make sure that the "Protocol Information" -> "IP" -> "IP Packet Forwarding" field is set to "Router"
Make sure that IP packet filtering is not enabled to block IP routing information into the IP routing table, or blocking the propagation of ICMP, UDP, or TCP packets through the router. Use the "SET TCP IP DEBUG =1" command on the server console to verify that no "discards" appear.
Make sure the routing table of the NAT has an entry for the internal network or host you're trying to reach. To verify, load the TCPCON module and select "IP Routing Table". Verify that an entry exists for the network the packet is destined for, or a default route exists.
Use "SET TCP IP DEBUG = 1" to verify that the conversion is taking place. The easiest way of capturing the output of the SET command is by loading the CONLOG.NLM before a test and unloading it immediately afterwards.
Here's a sample CONSOLE.LOG output when public host 130.57.52.13 tries to PING private host 10.0.0.1 (statically mapped virtual public host 130.57.199.13). See Figure 2 for details.
SJF-TS-MICK:set tcp ip debug=1 Tcp IP Debug set to 1 RECEIVE:pktid:6025 130.57.52.13->130.57.199.13 ttl:31> (ICMP) (ICMP): Echo Request FORWARD:pktid:6025 130.57.52.13->10.0.0.1 ttl:30> (ICMP) /* Translation was successful */ (ICMP): Echo Request RECEIVE:pktid:1024 10.0.0.1->130.57.52.13 ttl:128> (ICMP) (ICMP): Echo Reply FORWARD:pktid:1024 130.57.199.13->130.57.52.13 ttl:127> (ICMP) /* Translation was successful */ (ICMP): Echo ReplyGet LANalyzer/Sniffer output on both sides of the NAT router to verify that the translation at the IP layer has taken place correctly.
Below is an example of LANalyzer for Windows output when TELNET client (TELCLNT) on public network (130.57.52.13) tries to establish a TELNET session with TELNET server (TELSRVR - 10.0.0.1) running on the private network. The NAT-enabled router has a static mapping between 130.57.199.13 (NATPUB - public interface on NAT router) and 10.0.0.1, the TELNET server we are making accessible to public clients.
Example LZFW output on Private network:
No. Source Destination Layer Size Summary === ====== =========== ===== ==== ======= 65 TELCLNT TELSRVR tcp 0064 Port:1797 -> TELNET SYN> 66 TELSRVR TELCLNT tcp 0064 Port:TELNET ->1797 ACK SYN > 67 TELCLNT TELSRVR tcp 0064 Port:1797 >TELNET ACK >
TELSRVR is the TELNET servers private IP address (10.0.0.1). Although the Client specifies the IP address of a public interface (130.57.199.13) when executing the TELNET client, the NAT configuration has a direct mapping between this public address and the private address, resulting in a forwarding of the packets by the NAT router to the TELNET server on the private network.
The TCP PORT number on the private and public network is the same no PORT translation occurs in Static mode.
Example LZFW output on Public network:
No. Source Destination Layer Size Summary === ====== =========== ===== ==== ======= 5 TELCLNT NATPUB tcp 0064 Port:1797 ---> TELNET SYN > 6 NATPUB TELCLNT tcp 0064 Port:TELNET ---> 1797 ACK SYN> 7 TELCLNT NATPUB tcp 0064 Port:1797 ---> TELNET ACK> 8 NATPUB TELCLNT telnt 0067 Cmd=Do;Code=Suppress Go Ahead;C 9 NATPUB TELCLNT telnt 0094 Data=1) Multinational (VT100/VT22 10 NATPUB TELCLNT telnt 0064 Data=.. 11 TELCLNT NATPUB tcp 0064 Port:1797 -> TELNET ACK> 12 TELCLNT NATPUB telnt 0064 Cmd=Will; Code=Suppress Go Ahead; 13 NATPUB TELCLNT tcp 0064 Port:TELNET ---> 1797 ACK>
The source IP address of the originating request is the TELNET client (TELCLNT) on the public network (130.57.52.13). The client is TELNETing to the IP address of the NAT public interface (130.57.199.13) the TELNET server is NOT running at this IP address! When an IP packet is received on this public interface, the NAT_RECV routine kicks in and forwards the request to the private IP address (10.0.0.1) - mapped to this public IP address in the NAT configuration field - where the TELNET server is running.
No PORT changes occur in Static mode.
Verify that all applications work correctly:
Make sure that a static mapping from the public IP address to the same private address exists if trying to access local services running on the NAT host. This ensures that packets are passed to the TCP/IP stack without processing by the NAT.
Check if the problem is specific to one application or all applications, and one or all hosts.
- Do TELNET, FTP, HTTP (all TCP based apps) all fail? If HTTP fails, will an XCONSOLE/TELNET session from the same client also fail?
- Is FTP running in active or passive mode?
- Do SNMP, DNS, TFTP (all UDP based apps) all fail?
- Use SNMP to get as much info as possible. (This involves loading TCPCON and verifying IP fragmentation issues, local IP errors, ICMP, TCP, or UDP errors in the "Statistics" field.)
Does the application embed IP addresses in the data portion of the TCP/UDP packet? Several TCP or UDP based applications as well as the Internet Control Message Protocol (ICMP) data carry "IP Addresses" in the message data (not in the IP packet header). If NAT is to work with these applications that embed IP addresses in the data portion of the packet, it must:
+ identify the application (DNS, for example)
+ find the embedded IP Address in the DATA field
+ translate that IP address to a public address understood by all public clients
The current version of NAT does not do this for any application.
Check if the issue is timeout related. Timeouts may occur due to the overhead required to:
+ recalculate new checksums due to IP address changes - may be such that application layer timeouts need to be increased (done via the applications, and not the TCPIP stack).
+ rebuild IP packets that have fragmented due to hosts communication over different network topologies of different MTU sizes. May be that application layer timeouts need to be increased, or use the workaround given in the "static mode setup" NAT configuration section earlier in the document.
Check that the available cache buffers are high enough to handle all sessions. This can be done by verifying that the "Cache Buffers" field in the MONITOR module under "Resource Utilization" is greater than 40%.
Verify that IP packet filtering is not enabled to block incoming or outgoing TCP/UDP packets on the private interface. This can be achieved by doing a "SET TCP IP DEBUG=1" at the server console and making sure that no incoming or outgoing "DISCARD" messages appear at the server console, or checking that the problem doesn't occur when IPFLT.NLM is unloaded.
Get LANalyzer/Sniffer output on both sides of the NAT router to verify the state of the TCP/UDP requests and responses during client/server communication.
Summary
The Network Address Translator solves the problem encountered when trying to route packets between private networks containing unregistered IP addresses, and public networks requiring registered IP addresses. NAT does this in two modes, dynamic and static. In static mode, NAT reassigns IP addresses and port numbers from a pool of available ports, allowing one public IP address to be reused over and over again. In static mode, an association between a public and private IP address is created so that any packets destined for the public IP address configured is routed to the IP address it is mapped to.
NAT also enhances the level of security with the network by hiding the network's internal structure. There is never any advertising of the private networks address out onto the public network.
Finally, NAT can overcome issues without having to redesign IP addressing schemes when communicating with public networks. There is no longer the need to go to each and every workstation and reconfigure its IP information when access to the public network is first obtained NAT can be enabled at the boundary router to the public network so that all packets originating from the private network have the same, publically registered IP address.
More information on the NAT component of Novell Border Manager, including a FAQ and documents of known issues, check out:
Refer to TID #2928309 for the FAQ. TID #2933795 summarizes a large number of known NAT issues and their solutions.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.