Can someone explain to me, why isn't possible to connect 2 or more clients to a VPN server when the users are behind the same public IP (NAT/PAT).

What I mean is: if there is already a user connected to the VPN, when another user in the same network (same public ip) tries to connect to the same VPN the first connection goes down.

If PAT/NAT-T changes the private IP to the public one, and the source port to another source port but keeps track of it, to associate the original source port to the NATed one, I see no reason for it not to work. After a quick search I've found many people on the internet with the same question and problem, but I never found a good explanation about it.

Thanks!

This depends on the type of VPN used; there are VPN systems working using:

  • TCP
  • UDP
  • Special protocols (such as GRE)

For VPN systems working with TCP and/or UDP there is no technical reason for such a restriction.

"Special protocols" however are often not understood by the NAT router. In this case two things may happen:

  • The NAT router will deny routing the unknown packet type completely

    (Even if there is only one computer...)

  • Because the NAT router does not know the protocol it is not able to find out the (equivalent of the) "port number" of the packet. It does not even know if the protocol used has an equivalent of "port numbers" at all!

    (There are protocols which do not have "port numbers".)

    This means that the only information the NAT can extract from packets sent from the VPN server to the client is the IP address of the server.

    When two different computers behind the NAT connect to the same VPN server the NAT has no possibility to find out which of the two computers is the receiver of this packet.

Isn't there any explanation or real example of what happens to the packets to understand it better?

Let's look on an UDP transfer through a NAT:

  • Two computers behind the NAT send some UDP packets to the same computer in the internet; let's say they use the same source and destination port numbers
  • The NAT receives the packet and checks the packet type: It's UDP. This means that the port numbers are found in the first 4 bytes of the packet
  • The NAT replaces the source addresses of both packets by its own "global" address; it also replaces the source port numbers
  • The NAT also "remembers" (in its RAM) that it replaced the source port number in the first packet by the port number A and the source port number in the second packet by the port number B
  • The packet is now sent to the server in the internet
  • The server answers with a response which is also a UDP packet
  • If the destination port number in the packet is A the packet must be forwarded to the first computer; if it is B it must be forwarded to the second computer

Now suppose the computers do not send UDP packets but "XYZ" packets:

  • UDP and TCP packets have "port numbers"; however other protocols (like the original GRE) need not necessarily know the concept of "port numbers" at all
  • For UDP and TCP packets the port numbers are stored in the first 4 bytes of the packet; other protocols (like the new version of GRE) store the port numbers somewhere else
  • If the NAT does not know the protocol "XYZ" it cannot know ...
    • ... if "XYZ" packets contain port numbers at all and if yes ...
    • ... where in the packet the port number is stored.
  • Therefore the NAT is not able to get any information about the port number of the "XYZ" packet.
  • Therefore the NAT is not able to distinguish between "XYZ" packets sent from the server to the first computer and packets sent to the second computer.

Many (especially older) VPN systems use a combination of UDP and GRE packets; in this case the NAT will have problems with GRE packets.

With ESP ...

Seen from the NAT's perspective ESP is just another protocol like GRE or "XYZ".

... if there is only 1 computer connecting to the VPN and no ports associated to it?

In this case NATs of different manufacturers may behave differently:

Some NATs may simply not allow such a protocol. In this case using ESP, GRE, "XYZ" etc. through a NAT is simply impossible.

Other NATs might "remember" that a computer has been sending packets of a certain protocol (e.g. ESP) to a certain server and assume that all incoming packets of that type (ESP) from that server are intended for that computer.

This will of course no longer work if two computers are sending packets:

... when another user in the same network ... tries to connect to the same VPN the first connection goes down.

By the way: As far as I understand correctly the "SPI" field of the ESP header can be used to distinguish between different VPN connections.

So a NAT which knows the ESP protocol can allow multiple ESP connections at the same time:

It would use the "SPI" field instead of the port number to distinguish between packets intended for different computers.

  • Isn't there any explanation or real example of what happens to the packets to understand it better? I'm still having trouble understanding this situation. – John Aug 14 at 13:33
  • @John I updated my answer – Martin Rosenau Aug 14 at 17:01
  • First of all, many thanks for your nice explanation! Second: I understand your explanation and that was what I interpreted by your first comment, so I'm still having the same question in my head (my bad I didn't explain me well before, I thought a deep explanation would have solved my question, but no...). With normal PAT, the PAT/NAT device keeps track of the internal source ports and NATed ports. With ESP this can't happen. How the device knows the packet he is receiving is associated with the first computer, if there is only 1 computer connecting to the VPN and no ports associated to it? – John Aug 14 at 22:25
  • Because by PAT method of work ("table" with internal ports associated with NATed ports), if ESP protocol used by the IPSec VPN doesn't "support" ports in the ESP header then the first connection shouldn't work too because NAT can't make any port association to the packet coming from the first user connected to the VPN. – John Aug 14 at 22:37
  • @John I updated my answer again – Martin Rosenau Aug 15 at 7:23

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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