According to a related post it is not possible for port forwarding to concurrently serve multiple client hosts that are using the same internet service/application/protocol(eg. FTP, HTTP, etc) as each internet service has a dedicated port set by IANA. In other words, with port forwarding alone it is not possible for multiple clients hosts within the same internal network to use the SAME internet services concurrently OR even for multiple instances of the same internet application running on a single host machine. However, observation would suggest that concurrent support for multiple instances of an internet service within the same internal network is possible.

How is this explained in practice?

  • 1
    Are you talking about a web server? You can have multiple websites using one port (on one machine). But let's assume you have 2 web servers on port 80, then you can forward one as 81. If a different external port is not what you want, you need multiple external IPs.
    – Furty
    Apr 25, 2020 at 5:58
  • @Furty, or a Reverse Proxy.
    – StarCat
    Apr 25, 2020 at 6:07
  • @StarCat in contrast to port forwarding, a reverse proxy would need to understand the protocol. So it's not an universal solution and there was no answer yet, which services the question was about.
    – Furty
    Apr 25, 2020 at 6:37
  • @Furty, you mentioned a web server on port 80 for which a reverse proxy is a possible solution. I did not imply it’s a universal solution. Multiple external IP’s are.
    – StarCat
    Apr 25, 2020 at 6:51

2 Answers 2


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.

  • Thank you, I improved the question phrasing, is the unique ID field similar to what I suggested in another comment? i.e. a field in either the TCP/IP headers which enables the router to track the intended target machine(within its internal network), where the field value is assigned by the router to outgoing traffic, and associated with a client in its network, and then the field in incoming traffic is matched to its "field table", in order to determine the intended target machine?
    – MShakeG
    Apr 25, 2020 at 9:19
  • I'm not sure I have the right answer to that, because it feels like you skipped the entirety of the main post and focussed just on a single footnote? The "unique ID" field is specific to ICMP, it's not present in ordinary TCP or UDP connections. Apr 25, 2020 at 9:28
  • But I want to say that none of those fields were originally meant to be used by routers to track the intended target machine. Originally, NAT did not exist and routers were able to simply use the IP address fields to determine the target, because each machine had a unique IP address on the Internet. (The concept of sharing an external IP address through NAT was a much later addition, and it had to repurpose fields which already existed – there is no field in either TCP nor IP that exists specifically for NAT.) Apr 25, 2020 at 9:29
  • I read through it again, and I understand what you're getting at, though there's still the possibility of collisions if any 2 clients behind the NAT coincidentally choose the same port, though that's probably unlikely anyways.
    – MShakeG
    Apr 25, 2020 at 10:03
  • 1
    Yes, that can happen, but the NAT will deal with this by rewriting the source port if necessary – it'll ensure the port pair is unique on the WAN side, even if it's duplicate on the LAN side. Apr 25, 2020 at 10:08

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.

  • If I understand you correctly your solution would work on the server end, whereas my question pertained to the client end(should have probably stated explicitly). Regardless there is symmetry so it should work on either end, noting that after looking into proxy servers the terminology used on the client end is Forward Proxy.
    – MShakeG
    Apr 25, 2020 at 7:39
  • I can imagine a rather simple work around, that is having a field in either the TCP/IP headers which enables the router to directly track the intended target machine within its internal network. Does such a field exist?
    – MShakeG
    Apr 25, 2020 at 7:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .