Common pitfalls when testing NAT
I am not going to tell how to test the NAT Section (Agriculture, Rural Development and Environment) from the European Economic and Social committee. I believe you’re more interested in solutions for problems when testing Network Address Translation (NAT) routers. This post intends to help you in handling issues when testing (devices behind) NAT routers.
We can classify the pitfalls into three groups:
- Transmission Initiation: Problems you may encounter during the setup of the test traffic.
- Run-time: While test traffic is running, some issues may pop-up.
- Performance: Do my NAT configuration and test traffic serve the test purpose?
When the Maximum Transmit Unit (MTU) on an interface is set too large, IP fragmentation occurs along the transmission path. Whether or not this is an issue with your NAT router depends on its implementation regarding IP fragmentation. Our earlier blog post The ugly side of NAT explains this problem (and other issues with NAT). Path MTU Discovery can be used to avoid transmitting packets requiring IP fragmentation. In addition the IP don’t fragment (DF) bit should be set.
Suppose I configure my home gateway to forward incoming traffic from the internet on port 1234 to my home server with IP 192.168.1.123 on port 456. Using my traffic generator, I just sent some raw data frames to my NAT router port 1234, but my local server doesn’t receive anything. Now, why did my NAT router block the packets?
The root cause of the problem can be found at different network layers:
The most common reason for dropping frames based on the IPv4 header is a bad checksum. If the checksum is incorrect, a network device must drop the packet. This is not a NAT specific problem.
For both TCP and UDP frames the checksum must be correct.
When using UDP over IPv4, you can set the UDP checksum to zero to disable UDP checksum verification at the NAT router and/or destination.
Another common mistake is that you send TCP packets without proper TCP connection establishment. Because TCP requires that one port can only be used for one communication at a time, many NAT routers block TCP packets for malicious connections.
ICMP packets typically relate to an existing connection and need to be mapped using the same IP address and port mappings as that connection.
For ICMP query/reply type messages like Echoes (pings), NAPT uses the ICMP Query ID the same way it would use a TCP or UDP port number.
For ICMP error messages such as Destination Unreachable, it uses the ICMP packet’s internal copy of the headers of the frame that caused the error to figure out which mapping in the NAT table to use to translate it.
For more information, see also “Traditional NAT” in RFC3022, section 4.1.
Binding Timer Timeout
Hey, I am testing downstream on my NAT box and I lost bytes after some time. What happened here?
re you transmitting connection-less data? The binding timer in the NAT box may have tricked you!
Let me explain with an example using UDP frames.
- During the initial setup of a UDP session upstream (private to public network) packets are sent from a client to a server.
- The NAT router (using dynamic mapping) will add an entry to the translation table. An expiration timer will be started.
- Downstream (public to private network) traffic is sent.
- As time passes the expiration timer will time out as the NAT router no longer sees upstream traffic.
- Since the NAT router does not have any binding anymore for the incoming traffic at the public network, the packets will be dropped and the rest of the session will show packet loss.
This NAT router uses an outbound binding timer refresh. It resets the expiration timer only when packets pass from the private host to the public host within the context of the binding.
In order to keep the translation table intact, you must maintain some keep-alive traffic from the private host to the public host.
- Usually it needs to be identical or similar to the transmission initiation traffic. For example UDP frames using the same IPv4/IPv6 source and destination address and UDP source and destination port.
- Some application traffic may require both data traffic and control traffic to keep the bindings alive. See application-level gateway later in this post.
Another workaround for testing such a device is static NAT: enable port forwarding or configuring the client as DMZ host.
NAT VS. DMZ Host
There are two behaviors for NAT routers:
- Dynamic NAT (often referred to when talking about NAT) using dynamic static address (and port) mapping.
- Static NAT using a static address (and port) mapping.
RFC 2663 uses the term network address and port translation (NAPT) when both IP address and UDP/TCP port numbers are mapped.
- Dynamic translation table entries.
- Mostly used for connection from the internal (masqueraded) network to the external network.
- The combination of IP address and port information on the returned packet (inbound) can be unambiguously mapped to the corresponding private address and port information.
- Static translation table entries for connections from the external network to the internal (masqueraded) network.
- Often used for inbound connections.
- Incoming packets from the external address and port are redirected to a predefined internal address (and port in case of NAPT).
- Two flavors:
- Port forwarding: Forwards traffic from a specific external port to an internal host on a specified port.
- “DMZ-host“: Forwards traffic received on the external interface on any port number to an internal IP address, preserving the destination port.
Static NAT may have less run-time overhead for the router than dynamic NAT since it does not have to maintain any dynamic mapping. Consequently it may influence the performance in some conditions.
When the NAT router also implements firewall or Stateful Packet Inspection (SPI) functions, enabling/disabling static NAT may influence the performance.
When performing TCP tests for example, the traffic classification on the NAT box may also influence the NAT router performance.
The application-level gateway (ALG) functions in a NAT box are triggered for specific TCP/IP traffic. For example FTP and VoIP data require special handling of the packets because they use separate connections for control and data traffic.
During test initiation and the test run itself you should take measures to prevent the NAT box dropping your test traffic. The state of the entries in NAT translation table influences external inbound traffic. Internal outbound (initiating and keep-alive) traffic may be required to keep your binding entries alive.
Also, you should always keep the purpose of the test in mind to make sure you don’t see differences in performance. The NAT router’s static vs. dynamic NAT configuration are operationally different. Application-level gateway functions may be triggered also causing operational differences.
Excentis’ ByteBlower traffic generator/analyzer has full support for NAT testing.
We have a tutorial movie that shows how to use the automatic NAT discovery feature of the ByteBlower graphical user interface.