Cannot connect more than one client from behind a NAT firewall

[connectedway]

I have triaged an issue I was having connecting from two openvpn clients (one on MacOS, the other on my Android device) to an OpenVPN server hosted on an AlmaLinux9 Server. I could connect either client separately, but never simultaneously. This is even though both clients have their own keys an their own certificate CN. This also occurs whether the client/servers were configured for TCP or UDP.

The issue is that both the MacOS client, and the Android client were connected to the internet through the same wifi router. Once I've opened a VPN from one client, the other client was unable to connect.

On a hunch, I disconnected the wifi on my Android device and attempted to connect again. With the wifi disconnected, so that I was using the cellular network instead of the same wifi connection, I could bring up the second VPN connection.

I can understand that when the VPN server is configured using the UDP protocol, it may appear that the both VPNs are originating at the same location (the NAT router) and become confused but when establishing VPNs using TCP, I don't think this should be an issue.

It appears to me that the OpenVPN server refuses to accept a new tunnel connection if it is originating at the same IP address. I view this as a deficiency because there may well be multiple clients behind a NAT gateway wishing to establish a VPN to the same server.

[schwabe]

Please provide the server side log. I have no seen that behaviour before and I think I even used the same scenario.

[ordex]

May also be bad NAT implementation on the LAN router where the clients are..server log should shed some lights.

[connectedway]

Here's the full log. The log captures the issue, as well as after I disconnected the Android device from wifi and was able to establish simultaneous tunnels.

The log is quite big. The way to locate the point in the log where the issue is, I suggest searching for the IP address 174.246.197.208. This is the IP address of the Android device on the cellular network. Prior to the first time that IP address appears, both clients will appear as coming from the WIFI router at 192.168.1.254. I had cranked the verbosity up to 9 so there's alot there. Unfortunately for me, I couldn't make much sense of it other than seeing that the server was concluding that both streams were coming from "openfiles" even though only the first VPN established had that as it's CN.
openvpn.log

[ordex]

@connectedway can you please describe better what your setup looks like?
It seems server and both clients are in the same LAN?

Also, the server at boot claims that its default gateway is 192.168.1.254.
Is this an access point doing NAT inside the LAN?

In any case all connections from 192.168.1.254 appear to be using the same source port (1194), therefore the server will definitely think that packets are coming from the same client and mess things up.

But why is the WiFi AP NATting inside the LAN itself?

Let me guess:

• the VPN server is inside the LAN
• you have port forwarding configured on the router so that the VPN server can be reached from outside
• 192.168.1.254 is the WiFi router as well as the main gateway of your LAN
• clients are using the public IP to connect to the server, even though they are within the LAN

Any of the above is true? :)

[schwabe]

verb 9 is way too much here. it is hard too read. But grepping through the log it appears that there is only 92.168.1.254:1194 as IP/Port combination, e.g. only one client or two clients using the same ports. And the for the 192.168.1.254 address. Normally NAT devices will use a different port for one of the natted devices if there is a port collision, so this really seems to be messed up NAT.

[connectedway]

All of the above is true. Just as background, this is a home AT&T Wifi Router. The OpenVPN server is hosted on an AlmaLinux 9 server on the subnet inside the Wifi/NAT gateway. I have port forwarding of port 1194 from the wifi router to the OpenVPN server port 1194.

I have a CloudDNS account that is pinged by a cronjob on the OpenVPN server that registers the public IP address of the router with a DNS name dynamically. In this way, the openvpn server has an internet presence with a DNS name.

The two clients (for testing purposes) are both also on the subnet inside the Wifi/NAT gateway. The connect to the OpenVPN server using the DNS Name. So, the connection will come from within the local subnet, NAT'ed through the wifi gateway out into the internet, back to the public IP of the wifi gateway and port-forwarded to the OpenVPN server.

I'll get you a log of TCP tunnels in a bit.

[ordex]

I agree with all said by @schwabe . There is some bogus NAT at play here.

@connectedway in this case the packet is not going out to the Internet and back. When the router realizes that the destination is "itself" (public IP), it will then get the packet to go through port forwarding and then apply the NAT, which results in NATting to its own LAN IP. This is totally messed up if you ask me.

My conclusion would be that this router NAT implementation is unable to handle this special corner case and things gets messy.

And yes, this issue will likely happen regardless of TCP or UDP, because it happens at the IP layer.

[ordex]

One way to solve the issue is to run some local DNS (of any type) and have the VPN hostname be resolved to the local IP when the client is inside the LAN.

[connectedway]

Interesting. What you all said makes sense. Someday I'll try it from two devices inside a NAT gateway external to the subnet that the openvpn server is at. I'll close this issue.

I want to thank your responsiveness.

[schwabe]

You could try adding lport to your client configs and see if you can workaround that way around your broken Nat router.

[cron2]

On Fri, May 17, 2024 at 06:46:31AM -0700, Arne Schwabe wrote: `verb 9` is way too much here. it is hard too read. But grepping through the log it appears that there is only `92.168.1.254:1194` as IP/Port combination, e.g. only one client or two clients using the same ports. And the for the 192.168.1.254 address. Normally NAT devices will use a different port for one of the natted devices if there is a port collision, so this really seems to be messed up NAT.

Looks like the clients are binding to source port 1194, which clients should not do. Add "nobind" to the client configs. gert

…

-- Gert Doering - Munich, Germany ***@***.***

[ordex]

Looks like the clients are binding to source port 1194, which clients should not do. Add "nobind" to the client configs.

when Android is on wifi it comes in from an ephemeral port, so it seems they are not truly using 1194 as source but 🤷🏼