Problem connecting to OpenVPN server on AX86U

[Patrick9876]

I'm pretty sure is a dumb user error rather than anything in ASUS, Merlin, or OpenVPN implementation, but I'm baffled by a OpenVPN connection problem.

I'm running an OpenVPN 2.5.7 client on a Windows laptop and want to connect to my LAN via an OpenVPN server (configured for LAN-only connections) running on my router - AX86U. There is obviously no need for the VPN connection while the laptop is already on the LAN, but I want to be able to test the setup "locally" and am running into a problem. Here are the 4 configurations I've tested.

1. The laptop Ethernet connected to my router.
2. The laptop using a "regular" (as opposed to guest network) connection to my router.
3. The laptop connected to a guest network on the router and directing the OpenVPN connection to my DDNS url.
4. The laptop tethered to my phone (so not on my LAN) and directing the OpenVPN connection to my DDNS url.

#1, 2, and 4 work so I know that the VPN server is set up correctly and my DDNS url is pointing to the right IP address. I don't understand why #3 doesn't work, and I'm pretty sure it used to (although I haven't tried it several years). I understand that the connection (well, a UDP non-connection) has to go through the router twice but I don't understand why that's a problem. Nothing appears in the router's log so I assume the connection - probably on the inbound leg - isn't reaching the OpenVPN server.

 

[elorimer]

#1, #2 and #3 aren't giving you any kind of test. Only #4 is worthwhile. So figuring out #1, #2 or #3 is a waste of your time.

OpenVPN binds on all interfaces by default, so #1 and #2 are never leaving the LAN. I suspect any device on the LAN you might reach is not going through the OpenVPN server. #3 is isolated from the LAN, but I'm guessing it doesn't leave the router and so doesn't have a route to your DDNS.

 

[eibgrad]

I suspect the reason you can't establish the connection w/ #3 is because there is no DNAT rule in the nat table of the firewall to allow routing from the WAN's network interface to the LAN. That would normally be there *if* the OpenVPN server was located elsewhere inside the LAN. You would have had to establish a port forwarding for that purpose, which creates the DNAT rule in the PREROUTING chain of the nat table. Then forwarding is allowed by the "cstate DNAT" rule in the FORWARD chain of the filter table.

I suppose you could add a DNAT rule for these purposes, or (of course) reference the router's LAN ip instead (I believe the server is bound to all network interfaces by default). But as @elorimer suggests, the whole issue is moot anyway. Even if you get connected, you can't route over the VPN to the same IP network on which you're currently running, whether it is or isn't the same physical network. All the traffic will be handled locally. So #3 proves very little. It doesn't even prove you can access the OpenVPN server from the WAN since it's just accessing it from the LAN side. Your ISP could very well be blocking the OpenVPN server port and you'd never know it unless using method #4.

I think ppl get confused by this particular situation because its not obvious that internal references to the WAN only work for NAT loopback purposes when there's a DNAT rule. But that doesn't typically happen for services offered by the router itself unless that service is bound only to the LAN's network interface (usually for security reasons) and a DNAT rule is required for remote access purposes (e.g., the GUI).

 

[Patrick9876]

#1, #2 and #3 aren't giving you any kind of test. Only #4 is worthwhile. So figuring out #1, #2 or #3 is a waste of your time.

I don't agree. #4 is the only valid end-to-end test, but I don't think need an end-to-end test for most of the validation ... and #4 is a pain to set up.

I want a test to validate

1. The VPN server is working.
2. The VPN client is set up with the config parameters to connect to the VPN server.
3. That the client has the correct id and password to activate the VPN connection.
4. The DDNS stuff is set up correctly so that my URL resolves to the routers WAN IP address.
5. The VPN actually gives me access to my LAN.

OpenVPN binds on all interfaces by default, so #1 and #2 are never leaving the LAN. I suspect any device on the LAN you might reach is not going through the OpenVPN server. #3 is isolated from the LAN, but I'm guessing it doesn't leave the router and so doesn't have a route to your DDNS.

Both test configs #1 and #2 validate point 1, 2, and 3. The OpenVPN client gives me access to the subnet defined by the OpenVPN server. But you are right that nothing on my computer actually uses that subnet to access the LAN. Test config #3 would do that (I think).

Validating point 4 can be done with a ping or nslookup, but I would feel better if the OpenVPN client actually got the resolved address during the test. And I guess test config #3 does that. I can see the I{ addr in the OpenVPN client log, but the connection never gets made.

 

[Patrick9876]

... Your ISP could very well be blocking the OpenVPN server port and you'd never know it unless using method #4.

I hadn't thought of that. It's very unlikely that my ISP would block the (non-standard) port I'm using, but your reasoning still stands.