0

NAT in consumer routers makes the router translate a request from an internal device on a private IP (say dev0) and a specific source port X to a request from it's own public IP at a different source port Y. It then keeps a table listing the translation, so it knows that a packet arriving at the public interface on port Y has to be sent to dev0 on port X. This is also called Port Address Translation.

Now, as far as I know, port Y will be a random, unused port on the router. Say you have DMZ running on the consumer router, pointing to a different device, dev1. Say dev1 runs an application on port Z.

What happens when the NAT in the router translates a request from dev0 into a request from public IP on port Z? I would assume incoming requests from the public network on port Z would be routed to dev0, effectively disabling the effect of the DMZ? How can this be avoided?

0

("1-NAT") When the incoming traffic is received, the NAT will only forward the traffic when the incoming traffic comes from an IP address that is part of what the NAT table provides. So the local public interface's IP address W on port Y has to be sent to dev0 on port X, but only if the traffic comes from remote public interface IP T port U. IP T port U were placed in the NAPT (Network Address Port Translation, a.k.a. PAT or NAT) table when the first outgoing TCP connection was made.

That piece of my answer is largely just hijacking what Daniel said in his answer, with (I hope) slightly more specifics for clarity. However, this explanation still leaves the possibility of a port conflict, as there doesn't seem to be a way for traffic from IP address T to public interface W port Y to make it to the DMZ.

Well, in addition to that approach ("1-NAT"), I hereby add two other methods, ("2-LSTN") and ("3-EPH"), that can help to prevent this problem you speak of.

As a quick summary of what you'll find, by my last paragraph here, is that statistically few people are likely to ever be affected by this potential issue. (Most routers sold for homes will be to people who don't run their own servers.) Those who run important servers will often not just forward all TCP ports, and so they will also not encounter an issue. Out of the smaller number of people who do have the potential to be affected, there are option that are technically available to those who really care enough to adjust configuration options.

("2-LSTN") First of all, if the router is set up with a port forwarding rule with public IP address W port Y, then that address is in use by TCP. There might not be an "ESTABLISHED" connection, but it will be "LISTENING" on the port. For comparison, try running "netstat -na" on Unix or Microsoft Windows, and you can see that traffic is "LISTENING" on *.*.*.*:# (e.g., *.*.*.*:443 if an HTTPS port is being listened to). So a router probably would avoid sending traffic out port Y if it had that port forwarding rule for the DMZ.

This answer is kind of assuming that you're only sending select ports to a section of the network that is treated like a DMZ, and doing this via port forwarding. If you're just forwarding all TCP ports to the DMZ, which is the technique used by the "DMZ" option in some router configuration screens, then this obviously doesn't work because the router doesn't know about specific services that may be provided by the DMZ server. Fortunately, we have one more potential trick up our sleeve.

("3-EPH") The other thing is that helps with this is that outgoing port Y is typically selected from the list of possible ephemeral ports (perhaps also known as "dynamic ports"). Outgoing traffic typically uses a random number from the range of ephemeral port numbers. The range of ephemeral ports can vary: IANA suggests TCP port 49152 or higher (up through TCP's maximum of 65535), and this is used by Microsoft Windows Vista and newer, and FreeBSD 4.6 and newer. XP uses and BSD systems may use 1025 to 5000 according to Wikipedia's page on Ephemeral ports, or 1024 to 4999 according to NcFTP's page on Ephemeral ports (Microsoft Windows section). Linux may use 32768 to 61000. These values are customizable, as described in more detail on that NcFTP page that I hyperlinked to.

As long as a device is selecting an ephemeral port range that doesn't conflict with the services provided by the DMZ, then you won't have a port conflict.

Now, since most people don't tinker with the ephemeral port range of their router, then what is absolutely preventing the potential for a conflict?

As I see it, the answer is "nothing". However, the risk seems rather acceptable from a business standpoint (like the business that manufactured your router). Let's review this quickly. Your most critical services (like HTTP(S) and SSH) likely have port numbers in the "well-known" port range (0-1023), and so the router's ephemeral ports probably won't conflict ("1-NAT"). For other services, yes, there is the potential issue that outgoing traffic from the DMZ could result in NAT using up a port that you wanted the DMZ to be able to listen to. It would only affect the system that the outgoing traffic connected to (via NAT), and your chances are about 1 in 16,384 if the router is using the IANA-recommended range of Ephemeral ports ("3-EPH"). That's probably just viewed as an acceptable gamble for the statistically small number of people who use a DMZ for ports outside of the well-known (0-1023) port range, many of whom probably use it for an individual gaming session (which probably does not have major financial consequences worth suing over). If a gamer was affected, then voodoo magic (trying random things, like rebooting equipment) may very well result in the 1/16384 chance not occurring. For professional connections where this stuff matters, they have options like tinkering with (a.k.a. customizing) the values used for the ephemeral port range or, more commonly, using stricter firewall rules that only forward specific ports needed, which would likely cause the router to know to not use that port number ("2-LSTN").

1

Your description of the scenario is almost without reproach. However you have overlooked a crucial bit.

When the router receives a packet via the public facing port (WAN), it does not only translate based on the source port, but the source IP/port combo, this is a socket.

To be fair, there are numerous various of NAT, I suggest a thorough reading NAT'ing for you.

  • The exception to this is when you use port forwarding in addition to the DMZ feature, and someone outside wanted to use the DMZ hosts on the same port the forward rule indicates. The implementation would be model/brand-speicific, but I'm pretty sure most manufacturers would process it as a forward rather than sending it to the DMZ. Also, note that NAT passes responses inbound if they are part of the same TCP Connection, with expected SYN/ACK values, to prevent injection and hijacking. UDP just uses source and timing characteristics, making UDP port forwarding somewhat dangerous. – Frank Thomas Mar 3 '15 at 17:45
  • 1
    More than that – it uses the source address+port and destination (address+)port. – grawity Mar 3 '15 at 18:08
  • @Frank Thomas: Nice thought of SYN/ACK bits, but I'm not fully agreeing. Having 2 simultaneous TCP connections with the same port numbers, but different current SYN/ACK values, seems like potential danger of conflict if they ever matched throughout the connection, which might happen if one connection transmitted more packets than the other. Actually, the reality is even worse: the packets from the 2nd conversation might be treated like out-of-order/lost packets from the 1st conversation, causing certain conflict. So, that detail wouldn't really do much to alleviate the potential for confusion. – TOOGAM Mar 3 '15 at 18:56
  • SYN values are seeded psudo-random numbers, so the likelihood of the situation you describe is essentially null (1 connection in approx 2.14 billion since SYN is a 32bit number). Modern TCP\IP stacks are designed to make the initial SYN value almost impossible to predict, to thwart connection hijacking attacks. NAT DOES in fact use SYN values to identify packets in a connection, just the way your PC does, when you have two Superuser pages open in tabs. NAT implementations use several tables to handle the back and forth of the TCP handshake during connection establishment, – Frank Thomas Mar 3 '15 at 19:24
  • @FrankThomas So basically, it is I suspected and as TOOGAM answered: there is always a possibility of port clashes, although a small one(?) – Simon Mar 3 '15 at 23:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.