4

I’m beginning to learn about nat and I was wondering why does NAT translate a source port? Doesn’t a port represent an application that’s requesting a service? So why must it be translated? Also what would happen if NAT hypothetically didn’t translate the source port and two separate machines on the same network sent out a message but had the same source port? Would anything bad happen?

  • 1
    Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Apr 1 '18 at 20:13
6

First, I'm assuming you're focused on TCP. UDP has some differences, and I'm not as up-to-speed on that part.

I’m beginning to learn about nat and I was wondering why does NAT translate a source port?

You're right to ask this question, and to be frank, it doesn't always need to. However, sometimes that translation IS required. Given that it is sometimes required, and given that the NAT system therefore needs to track source port for some traffic, and because there are efficiencies in doing something the same way every time, most NAT implementations don't make an effort to re-use the original source-port on the NATted connection.

Many (most?) protocols don't depend on the source port for TCP connections, so that's the simplest approach, and it rarely hurts.

Doesn’t a port represent an application that’s requesting a service?

It does, but generally the source port is not specified by the application. Instead it is assigned (somewhat) randomly. This is actually good, because before that was true it was way too easy to break existing connections by predicting the source port number (the "unreach" attack using ICMP DESTINATION UNREACHABLE packets).

So why must it be translated? Also what would happen if NAT hypothetically didn’t translate the source port and two separate machines on the same network sent out a message but had the same source port?

The answer to your first question is in the answer to the second, so I'll take a stab at the second, and you share if it doesn't answer the first.

First, assume your NAT host only has one IP address (N) to translate to. Second, assume you actually have an extra coincidence where internal hosts A and B both try to communicate with external host X on port 80 with source port 17835.

  • A's packets (when generated, before NAT) look like: src: A:17835, dst: X:80.
  • B's packets (when generated, before NAT) look like: src: B:17835, dst: X:80.

After NAT, assuming no translation of source port:

  • A's packets (after NAT) look like: src: N:17835, dst: X:80.
  • B's packets (after NAT) look like: src: N:17835, dst: X:80.

Oops. They look the same. They particularly look the same to the remote host X. It is most likely to drop the packets associated with the second connection attempt because the sequence numbers are going to be wrong.

You also have a problem on the NAT host, as it can't tell the difference between the two either. It can only maintain one "connection" record with remote host X on port 80 per source port. It has to keep this record so it knows which internal host to translate back to when it receives an inbound packet. If the record corresponds to the first host to connect, then you would have the experience where A (the first host) has no problems, and B cannot connect.

If, more entertainingly, B's record in the NAT overwrites A's after the connection is built for A, then the NAT system will never forward X's responses to A (it only has B's record), and X will never respond to B (wrong sequence numbers / connection state) and nobody wins (communicates).

Let's be honest. NAT is a hack. It is an ugly hack, and we are either lucky it works (because we haven't rolled out IPv6 universally yet) or victims of its success (because it works well enough, people don't insist on IPv6 support).

  • 1
    "Many (most?) protocols don't depend on the source port for TCP connections..." I don't quite understand that statement. TCP itself requires both source and destination IP and TCP addresses for a connection, and applications and application-layer protocols that use TCP depend on the TCP connections, which, in turn, depend on the source port. – Ron Maupin Feb 1 '18 at 2:54
  • Sorry, I meant protocols that operate over TCP. Examples would be SMTP, HTTP, RDP. These protocols specify a standard destination TCP port, but they function regardless of the TCP source port used for the connection. Arguably the only reason they even have a standardized destination TCP port is so that you and I don't have to specify one for every connection. – Slartibartfast Feb 1 '18 at 3:14
  • You are right that the source and destination port are both required for a TCP connection to be meaningful at the TCP layer, but many protocols above the TCP layer don't care what either port number is (TCP is just used for transport of bytes) – Slartibartfast Feb 1 '18 at 3:16
  • Yes, and protocols above the transport layer (OSI layer-4) are actually off-topic here. – Ron Maupin Feb 6 '18 at 19:53
2

Probably the easiest answer:

Imagine two LAN clients accessing the same external web server and coincidentally both using the same source port.

If the NAT router now uses the same external source port for both sessions with the external destination IP and port also being the same, how is it supposed to find out which returning data is to go where?

Moreover, the external web server might get deeply confused with two intermixed sessions from a single IP/port combination.

1

I assume you mean the NAPT version of NAT. NAPT translates both the IPv4 address and the transport address (TCP port, UDP port, or ICMP identifier). The reason is that there may be multiple hosts using the NAT which could be using the same protocol with the same transport address (port or identifier).

  • Okay thanks. And if NAT didn’t translate the port and multiple hosts tried to use it then the message would be lost? – Jaffa Jan 31 '18 at 23:02
  • If you happen to have two hosts that use the same transport address, the router would not know to which host the return traffic should be sent. Routing must be deterministic. You should look at the NAT RFCs. NAPT really only works (sometimes) for TCP, UDP, and ICMP. NAPT breaks other transport protocols, as well as many application layer-protocols (even when using TCP or UDP). – Ron Maupin Jan 31 '18 at 23:05
0

There are different types of NAT. It sounds like you're talking about the standard PAT (port address translation, also known as Hide NAT) used by private-addressed clients behind an internet-facing firewall.

There will always be (for TCP anyway) a source port and a destination port. The destination port can identify the service ( such as 21 for FTP, 443 for HTTPS, etc.) The source port does not. It is just a random numbered high port.

Source port and IP address are used by remote systems to uniquely identify the connection. With two computers behind a PAT appliance, there's a small chance that both systems might choose the same source port for two different connections to the same remote IP. For this reason, the device must be able to change the source port while keeping track of its association with the original.

-1

A NAT (Network Address Translation) does not actually translate the port. You are most likely referring to a PAT (Port Address Translation).

Even more specifically, you are likely referring to a Dynamic PAT -- which is a type of translation which allows any number of internal hosts to share one or more public IP addresses:

Dynamic PAT Outbound illustration - pracnet.net/nat

In the illustration above, notice all three hosts initiate connections to a destination on the Internet. All three hosts (A, B, and C) select their own source ports randomly (2222, 3333, and 3333, respectively). When their packets traverse the translation device, the router selects new source ports (7777, 8888, 9999, respectively).

This is crucial, because the re-writing of the source port is what allows the return traffic to be forwarded back to the correct initiating host:

Dynamic PAT Inbound illustration - pracnet.net/nat

The Router made note of the mapping between initial source port and post-translation source port, and uses that to correctly return the response traffic to the correct host.

Had the Router NOT re-written the source ports, both Host B and Host C's return packets would have been to the same destination port:

Dynamic PAT - WITHOUT Re-Randomizing Source Port - pracnet.net/nat

When those packets would make their way back to the Router, there would be no way for the Router to know which packet should have gone to Host B and which packet should have gone to Host C.

Hence, it is crucial for the Dynamic PAT device to also re-write the source port to ensure the return traffic can be successfully returned to the original host.

To learn more about Dynamic PAT's operation, check out the Dynamic PAT Article in the Network Address Translation article Series

  • 1
    -1 for pushing what appears to be ciscoisms as if they were authoritive definitions. – Peter Green Feb 1 '18 at 15:20
  • @PeterGreen Hi Peter. I would encourage you to list where my answer(s) doesn't line up with the industry or reality. If it is merely in semantics then I don't know what to tell you, every vendor calls them something different -- but that doesn't change the fact that there are only four types of translations that exist: Static NAT, Static PAT, Dynamic PAT, Dynamic NAT. – Eddie Feb 1 '18 at 16:09
  • It doesn't make sense to me why this post is being downvoted. Still waiting on objective reasons why this post fails to answer the OP. Or if this post has any inaccuracies. – Eddie Aug 8 '18 at 14:43

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.