When multiple client hosts are behind a NAT sharing one 'external' IP address, how do multiple clients to connect concurrently to the same address?

Solution 1:

I've interpreted your question as: "When multiple client hosts are behind a NAT and share a single 'external' IP address, how is it possible for multiple clients to connect to the same server on the same port?"

This is made possible by the exact same mechanism which also allows a single host to establish multiple connections to the same service. (For example, your web browser frequently uses 2–3 concurrent HTTP connections to the same web server.)

TCP connections and UDP streams are always identified by a pair of ports. Each TCP or UDP packet carries two fields: the 'source' port and the 'destination' port.

In packets from a client, the 'destination' port holds the IANA-assigned service port (e.g. 80 for HTTP), but the 'source' port is automatically assigned by the OS such that the {source, dest} pair is always unique. For example, the client might use ports {54794, 80} for the first HTTP connection and {48973, 80} for the second. The server responds with source and destination reversed – its packets would have {80, 54794} or {80, 48973}.

When you have multiple client hosts behind a NAT, the process remains the same and the NAT device uses the port combination to recognize which client made which connection. And if multiple client devices happen to select identical ports, the NAT device will translate the source port to ensure the pair is still unique on the WAN side.

Another version of the same answer (less clear, but with examples): How does an internet server respond to a request from a private IP?


Some other IP-based protocols (e.g. SCTP) also have ports which work exactly the same way.

QUIC uses UDP encapsulation for this purpose – QUIC ports are actually UDP ports.

ICMP Echo (aka ping) has a unique ID field, which serves the same purpose as the "source port". (You could say the ICMP type/code fields serve the purpose of the "destination port".)

IPsec ESP has Security Association IDs, but as far as I know they're not usually tracked by NATs – the NAT devices usually treat ESP as if it had nothing like ports and only allow a single client to connect to a given server (or even worse, some NAT devices only allow a single client to use ESP at a time, period). UDP-encapsulation is used to combat this problem.

Solution 2:

Correct. Think about it in reverse why it is not allowed. If I hit a public IP (say 74.32.x.x:5000) that has 2 machines using the same port internally if they were both port forwarded at the router level, how would it know which one to route to? The answer is to have a reverse proxy inside the network or load balancer depending on the use case to delegate incoming traffic. A load balancer would be able to service an application running on the same port and a reverse proxy can read packet headers and send the data to the correct internal server.

Reverse Proxy Example: Say you have 2 websites running blue.com and red.com and both are hosted on internal servers, but share your public IP and both run on port 80. The incoming request would hit the router, get sent to reverse proxy which would then say "the user asked for red.com" and then pass the request to the webserver that is hosting red.com internally.

Load balancer Example: 2 internal servers share the same port hosting the same application. Load balancer takes incoming requests and sends to the server that is either the least busy traffic wise OR can be set to always send to one server, but if it stops responding, reroute to the other server as a failover.