{"id":826,"date":"2015-06-02T11:20:08","date_gmt":"2015-06-02T09:20:08","guid":{"rendered":"https:\/\/excentiscom.webhosting.be\/?p=826"},"modified":"2022-06-24T08:24:06","modified_gmt":"2022-06-24T06:24:06","slug":"common-pitfalls-when-testing-nat","status":"publish","type":"post","link":"https:\/\/www.excentis.com\/blog\/common-pitfalls-when-testing-nat\/","title":{"rendered":"Common pitfalls when testing NAT"},"content":{"rendered":"

I am not going to tell how to test the\u00a0NAT Section (Agriculture, Rural Development and Environment)<\/a>\u00a0from the European Economic and Social committee. I believe you’re more interested in solutions for problems when testing\u00a0Network Address Translation<\/a>\u00a0(NAT) routers. This post intends to help you in handling issues when testing (devices behind) NAT routers.<\/p>\n

\"\"<\/p>\n

Classification<\/h2>\n

We can classify the pitfalls into three groups:<\/p>\n

    \n
  1. Transmission Initiation<\/strong>: Problems you may encounter during the setup of the test traffic.<\/li>\n
  2. Run-time<\/strong>: While test traffic is running, some issues may pop-up.<\/li>\n
  3. Performance<\/strong>: Do my NAT configuration and test traffic serve the test purpose?<\/li>\n<\/ol>\n

    Transmission Initiation<\/h2>\n

    Path MTU<\/h3>\n

    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\u00a0The ugly side of NAT<\/a>\u00a0explains this problem (and other issues with NAT).\u00a0Path MTU Discovery<\/a>\u00a0can be used to avoid transmitting packets requiring IP fragmentation. In addition the IP don’t fragment (DF) bit should be set.<\/p>\n

    Frame Types<\/h3>\n

    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?<\/p><\/blockquote>\n

    The root cause of the problem can be found at different network layers:<\/p>\n

    IPv4<\/h4>\n

    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.<\/p>\n

    UDP\/TCP<\/h4>\n

    For both TCP and UDP frames the checksum must be correct.<\/p>\n

    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.<\/p><\/blockquote>\n

    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.<\/p>\n

    ICMP<\/h4>\n

    ICMP packets typically relate to an existing connection and need to be mapped using the same IP address and port mappings as that connection.<\/p>\n

    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.<\/p>\n

    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.<\/p>\n

    For more information, see also “Traditional NAT” in\u00a0RFC3022<\/a>, section 4.1.<\/p>\n

    Run-Time<\/h2>\n

    Binding Timer Timeout<\/h3>\n

    Hey, I am testing downstream on my NAT box and I lost bytes after some time. What happened here?<\/p><\/blockquote>\n

    re you transmitting connection-less data? The binding timer in the NAT box may have tricked you!<\/p>\n

    Let me explain with an example using UDP frames.<\/p>\n

      \n
    1. During the initial setup of a UDP session upstream (private to public network) packets are sent from a client to a server.<\/li>\n
    2. The NAT router (using\u00a0dynamic mapping<\/em>) will add an entry to the translation table. An expiration timer will be started.<\/li>\n
    3. Downstream (public to private network) traffic is sent.<\/li>\n
    4. As time passes the expiration timer will time out as the NAT router no longer sees upstream traffic.<\/li>\n
    5. 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.<\/li>\n<\/ol>\n

      This NAT router uses an\u00a0outbound binding timer refresh<\/em>. It resets the expiration timer only when packets pass from the private host to the public host within the context of the binding.<\/p>\n

      \"\"<\/p>\n

      In order to keep the translation table intact, you must maintain some keep-alive traffic from the private host to the public host.<\/p>\n