Connection to router by ip fails while remote over OpenVPN

[cone]

I've looked through several dozen thread with similar issues, but none appear to provide solutions that have had any effect on my problem.

I have a RT-AC66U B1 running Merlin 386.14
the local network is 192.168.50.0/24
OpenVPN is enabled, TUN/UDP, with a subnet of 192.168.69.0/24. connection type is set to "both" (internet and LAN)

I create a user, and connect successfully using Arne Schwabe's client on Android.
Using StreamSoft's PingTools I am able to ping 192.168.50.1 (the router) 192.168.69.2 (myself), and 192.168.69.1 (the router also)

All internet traffic seems to fail, and browsing to https://192.168.50.1:8443 never connects. I get connection reset and other inconclusive failures.
If I attempt to use 192.168.69.1 instead on any protocol or port I get connection refused.

I have tried with static routes both off and on, neither of which made any difference with routes set to point between the VPN and local subnets.

Clearly the VPN is working to some degree, since connection succeeds, but I can't do anything with it. What am I missing?

 

[eibgrad]

I assume you're using the exported client config file generated from the OpenVPN server GUI on the router.

I also assume you're attempting to access the server from the internet via the Android device (cellular or remote wifi), and NOT using the wifi from within the same LAN as the server itself.

Use ssh to access the router and copy/paste the following (in toto) into the terminal window.

while read cmd; do echo ">>> $cmd"; $cmd; echo; done << EOF &>/tmp/dump.txt
ifconfig
brctl show
ip route show table main
ip rule
iptables -t mangle -vnL
iptables -t nat -vnL
iptables -vnL
cat /tmp/etc/openvpn/server1/config.ovpn
cat /tmp/etc/openvpn/server2/config.ovpn
grep ovpn /tmp/syslog.log
EOF:

It will execute and dump the output from those commands to a file called /tmp/dump.txt.

You can then use scp (Linux) or WinSCP to copy the file to your PC, remove your public IP, and either attach it to a followup post, or perhaps post it to PasteBin.

scp admin@192.168.50.1:/tmp/dump.txt .

Note, do this *after* you've attempted to connect to the OpenVPN server so we can see the state of the router at the point of failure. Of course, you can mask your public IP, just do so in a way that is obvious and consistent. Do NOT mask any private IPs.

 

[cone]

I assume you're using the exported client config file generated from the OpenVPN server GUI on the router.

I also assume you're attempting to access the server from the internet via the Android device (cellular or remote wifi), and NOT using the wifi from within the same LAN as the server itself.

Correct on both counts

Here's the dump.
I can connect to the router admin GUI when connected via the wifi it manages while also being on its VPN, but that's obviously not helpful in the wild.

 

[eibgrad]

From this point forward, do NOT connect to the OpenVPN server from within the same LAN as the OpenVPN server itself. This proves nothing. In fact, it can cause problems since now you have two (2) routes on the client to your local IP network (local and via the VPN). And that can lead to routing confusion by the client and/or server. All that matters is what happens when you are on the *public* side of the WAN, such as on a smartphone using the cellular network.

I'm still reviewing the output.

 

[eibgrad]

Another thing to be cautious about is to add the duplicate-cn directive to custom config if you intend to access the the OpenVPN server from multiple, concurrent clients using the same client certs and keys. If you don't, then access by the next client will kick off the previous client. I'm concerned that between the local and remote access you're testing with, you might be encountering this behavior, which you may be interpreting as an unstable connection.

 

[cone]

Is there anything short of time or reboots that I can do to reset such time/order-sensitive issues before continuing if they are present?

 

[eibgrad]

Is there anything short of time or reboots that I can do to reset such time/order-sensitive issues before continuing if they are present?

I don't understand what you're asking me.

 

[cone]

I feel like I could do something to terminate things like the stored routes you mentioned, or the active session from the wifi-connected client. Was wondering if there was an active way to do that that wasn't reboot or waiting for some TTL

 

[eibgrad]

As far as the routing and firewall, I don't see any problems.

Chain OVPNSI (1 references)
 pkts bytes target     prot opt in     out     source               destination         
   33  1988 ACCEPT     all  --  tun21  *       0.0.0.0/0            0.0.0.0/0           
    2   202 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:1194

The above is recording all packets inbound from the tun21 (OpenVPN server #1) network interface directed at the router.

Chain OVPNSF (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      tun21   0.0.0.0/0            0.0.0.0/0           
   57 17207 ACCEPT     all  --  tun21  *       0.0.0.0/0            0.0.0.0/0

The above is recording all packets inbound from the tun21 (OpenVPN server #1) network interface being forward either to the LAN or the internet.

What is troubling are all these tls-crypt errors (I have no idea why that is).

Sep 22 00:25:35 ovpn-server1[8486]: tls-crypt unwrap error: packet too short
Sep 22 00:25:35 ovpn-server1[8486]: TLS Error: tls-crypt unwrapping failed from [AF_INET]57.151.71.95:49326 (via [AF_INET]PUBLIC_IP%eth0)

What you might do for the time being is disable TLS Control Channel Security (and while you're at it, add the duplicate-cn directive to the custom config field) on the OpenVPN server, restart it, and regenerate the client config for the Android. I just want to see if that makes the errors go away and provides more stability.

 

[cone]

Done, here are results

Core problem remains, however.

 

[eibgrad]

Is it possible your internet issues are DNS related? IOW, can you ping 8.8.8.8, but something like ping google.com doesn't work.

 

[cone]

I don't see how, since I'm trying to access the admin GUI by ip address.

 

[cone]

To test, I did ping. I can reach each of the router (192.168.50.1) as well as 8.8.8.8 and google.com while not on wifi and using the VPN.
However, I can access neither the router nor google.com in a browser.

 

[eibgrad]

Well that doesn't indicate a problem w/ the VPN. If you can access a public IP and use domain names across the VPN, that's all you can expect. If you have problems only w/ a specific client-side application like the browser, I'm not sure there's much I can do since I have to way to diagnose it.

BTW, I did notice you're pushing three (3) DNS servers, two public, one local.

push "dhcp-option DNS 1.1.1.1"
push "dhcp-option DNS 1.0.0.1"
push "dhcp-option DNS 192.168.50.1"

The problem here is that not all clients will necessarily try ALL the provided DNS servers should the first DNS server accessed return NXDOMAIN (i.e., NOT FOUND). That's because NOT FOUND is a *valid* response, NOT an indication of an error, and so the client *may* simply quit at that point.

I'm NOT sure how you configured the router to have all these servers being pushed, but in general, you're better off to either only push public servers (w/ obviously no local name resolution), OR, just the local DNS server, so you get local name resolution + access to any public DNS servers configured w/ the local DNS server. But NOT both.

 

[cone]

the first two servers are the DNS servers configured on the router for the LAN via DHCP. I never explicitly told the third to be, but I assume all of this is because I selected DNS to be advertised to clients.

 

[cone]

This is why there's three entries. This was "yes" until just now

even so, no change in behaviour

 

[eibgrad]

Try another client platform (e.g., laptop) and/or another OpenVPN client (I don't know the first thing about Arne Schwabe's app, I use OpenVPN Connect), just to see if it's something specific to that device and/or OpenVPN app.

 

[elorimer]

I forget exactly why, but Schwabe's app is much more capable than OpenVPN Connect. It would always work for me on a Chromebook when OpenVPN Connect wouldn't.