Cannot connect more than one client from behind a NAT firewall about openvpn HOT 12 CLOSED

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

from openvpn.

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

from openvpn.

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

from openvpn.

@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? :)

from openvpn.

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.

from openvpn.

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.

from openvpn.

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.

from openvpn.

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.

from openvpn.

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.

from openvpn.

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

from openvpn.

from openvpn.

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 🤷🏼

from openvpn.