Openvpn client - pings work, no other traffic routes

On my AR750S Slate, I utilize two different VPN clients, depending upon which I want to use for the application. I have a Wireguard client and an OpenVPN client configured for use when I’m away from home. I use Wireguard to PrivateVPN for most VPN situations, but also use OpenVPN to my Asus home router for other VPN situations.

The Wireguard client works perfectly. When selected and active, all of the client traffic on my AR750S will pass through the VPN tunnel as expected (Using PrivateVPN service)

But the OpenVPN client isn’t working correctly. When my OpenVPN connection is linked up, I get a successful link. I can PING traffic through the VPN and a traceroute shows the traffic routing through the OpenVPN server (my Asus router at home). But I cannot get any other traffic except pings through the tunnel. DNS queries fail, SSH to linux servers in my home that I can ping fails.

I would suspect something wrong with my Asus home router (the OpenVPN server). But use the same .ovpn to configure the OpenVPN client on both my laptop and my phone successfully. If I use my OpenVPN client on my phone or directly on my laptop computer, I can successfully pass all traffic through that tunnel, so my home Asus router is properly routing traffic. I do not know why the AR750S cannot use the same .ovpn file successfully when my other Windows/Android clients are working fine.

I SSH into my slate, and I get the same behavior from the CLI, I can ping foreign hosts and traceroutes show my traffic routing through my home Asus router. But SSH to foreight hosts all fail (timeout).

I looked at the routing tables on my AR750S after connecting an OpenVPN client compared to the Wireguard client. They do look different.

Any other commands I should run from a terminal on my AR750S to verify what is causing my issue?

Route -e outputs:
Wireguard:

root@GL-AR750S:~# route -e
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         *               128.0.0.0       U         0 0          0 wg0
default         192.168.1.254   0.0.0.0         UG        0 0          0 wlan-sta
10.34.0.0       *               255.255.0.0     U         0 0          0 wg0
89.187.164.97   192.168.1.254   255.255.255.255 UGH       0 0          0 wlan-sta
128.0.0.0       *               128.0.0.0       U         0 0          0 wg0
192.168.1.0     *               255.255.255.0   U         0 0          0 wlan-sta
192.168.8.0     *               255.255.255.0   U         0 0          0 br-lan
root@GL-AR750S:~#

OpenVPN:

root@GL-AR750S:/etc# route -e
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         10.8.0.5        128.0.0.0       UG        0 0          0 tun0
default         192.168.1.254   0.0.0.0         UG        0 0          0 wlan-sta
10.8.0.0        10.8.0.5        255.255.255.0   UG        0 0          0 tun0
10.8.0.5        *               255.255.255.255 UH        0 0          0 tun0
73.36.26.167    192.168.1.254   255.255.255.255 UGH       0 0          0 wlan-sta
128.0.0.0       10.8.0.5        128.0.0.0       UG        0 0          0 tun0
192.168.1.0     *               255.255.255.0   U         0 0          0 wlan-sta
192.168.8.0     *               255.255.255.0   U         0 0          0 br-lan
192.168.86.0    10.8.0.5        255.255.255.0   UG        0 0          0 tun0
192.168.86.1    10.8.0.5        255.255.255.255 UGH       0 0          0 tun0
root@GL-AR750S:/etc#

This could be an MTU issue, FYI.
On the other hand, try to enable “Access Local Network”
image

I have the Access Local Network box selected (have actually tried it both ways).

MTU I would expect partial/erratic communication. A DNS query is a very small packet, shouldn’t have an issue with MTU. But my DNS queries also fail through the AR750 (no matter which DNS server I choose, my own in-home, or google at 8.8.8.8 which I can ping, but DNS queries fail). DNS queries when using the OpenVPN windows client work fine through my Asus home router.

Could you share your OpenVPN config file with keys etc removed?

looks like comp-lzo has an issue, use this option with no instead of adaptive and yes. if No option doesn’t work then you may need to contact your openvpn service provider as they have to disable this option or have adaptive on the server end.

Here is the OVPN file contents:

remote *******.asuscomm.com 1025
float
nobind
proto udp
dev tun
sndbuf 0
rcvbuf 0
keepalive 10 30

# for OpenVPN 2.4 or older
comp-lzo yes
# for OpenVPN 2.4 or newer
;compress lzo

auth-user-pass
client
auth SHA1
cipher AES-128-CBC
remote-cert-tls server
<ca>
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

</ca>

<cert>
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

</cert>

<key>
-----BEGIN PRIVATE KEY-----

-----END PRIVATE KEY-----

</key>

That’s a good idea ahhydri. I’ll give that a try later today and let you know if it works.

My “service provider” is my own Asus router which supports OpenVPN connections. It works well using the OpenVPN Android and Windows client. I’m only having issues when my AR-750 Slate is the client.

My Asus router is an RT-AC5300 using current firmware from Asus. I believe that is a flavor of the merlin fork of open-wrt. I might SSH into the router later and see if there are any messages in the logs when I’m connecting from the GL.inet Slate vs the OpenVPN windows client.

Off top of your head, you know where the Slate’s firewall configuration is kept in /etc ? I could put it in debug mode and see if anything is getting filtered at the Slate.

Tried comp-lzo setting of ‘no’ and did not help. My windows and android clients are still working good. Still can’t make the Slate properly connect and route all traffic. Only pings.

The firewall file for Slate is located at /etc/config/firewall. Please ensure that both the OpenVPN Windows client and Slate’s OpenVPN client are on the same network.

And please ping the tunnel address using the following command:

ping 10.8.0.5 -I tun0

This will confirm that the ping is also going through the tunnel.

I tested this type of conf file, and it works. We need more investigation to debug the issue.

Merlin is adapting Asus official, and anything recent requires OpenVPN 2.4. The current beta version is using OpenVPN 2.6, compress is deprecated.

Also, comp-lzo no means that traffic is framed for compression but compression isn’t used. If the Asus is set up to disable compression, then it expects traffic not to be framed for compression either, so traffic won’t pass even if a connection is made. I would check what the Asus setting is, and change your config accordingly but in truth you should disable compression entirely. I don’t think that is your problem, though, if other devices can successfully pass traffic.

Also, --cipher is deprecated, and I think your client file should start with “client”

Thanks @elorimer . I confirmed my Asus router is using OpenVPN 2.4 (logged in yesterday to the router and pulled that). The client on the Slate is 2.5.2 so we should be fine from a version standpoint except for possibly new options/defaults in 2.5.2.

I also reflashed the Slate’s current firmware along with a factory reset to make sure there was nothing leftover from when I was using a Wireguard VPN that caused an incompatibility.

My Asus router (advanced settings) is set for no compression, and like you said, my devices connect using Windows/Android versions of OpenVPN clients.

The OVPN file I posted is actually directly downloaded from my Asus router (it provides the config file). But I suppose it must deal with a variety of clients old/new so I agree the config file might need a tweak. I’m reading the OpenVPN reference manual (in my spare time) to see what config options I might optimize along the way.

My next task is to observe the system log as I make the connection. The Slate web interface “shows” success while connecting, but my Asus router’s log shows a heartbeat timeout shortly after my “successful” connection. I’m wondering if the Slate’s logs might show a failure/warning/clue that isn’t reflected in the web interface. When connecting with a web interface, I see a couple of information messages flash briefly (including the cipher deprecation message you mention), and then the screen changes to a “connected” status. So there might be a clue there that I’m only going to see in the debug log.

Anyone know the CLI command the router is using to start the OpenVPN service? If I ran from command line, I might get a better handle on what’s going sideways.

@hansome

Thanks for the firewall info.

Both Slate client and windows client are on the same wifi network at my vacation condo. (my windows client works both directly on the condo wifi and also through the Slate acting as a repeater).
I’ll try your ping, though I know my pings must make it through the tunnel as I’m pinging a linux server on my private lan subnet which is inside my home network. There’s no other way I could ping that server from my location without a VPN tunnel.

Thanks for checking the config file. You checked on a Slate? (or at least a linux client?). I might try running OpenVPN on a Linux Live USB stick and see if I can troubleshoot that. The flavor of linux on the Slate is just different enough to make it tricky for me to dabble. (plus I have family in the condo who hate it when I’m messing with the router they’re using, LOL)

Add to your config file verb 4 while you are figuring this out. It will give you more logging, but not a bothersome amount.

1 Like

@hansome

Running from Linux-live disk (Linux Mint 20.3) I am able to connect successfully and route/browse/nslookup to my Asus Router via OpenVPN using the OVNP file I provided earlier. I am able to access all my local servers at my home as well as browse the internet. Traceroutes show my traffic running through the comcast gateway in my home city (Chicago).

My Linux Mint live disk is running Openvpn client v2.4.7

The good news: This means my home router’s OpenVPN connection CAN connect and route traffic from a linux client with the right settings. I just need a bit more digging to figure out what is failing on the Slate.
I’ll try elorimer’s “verb 4” setting and see what I find.

The bad news: troubleshooting means messing with the active Slate router connection everyone in the condo is using (sighhh). I was hoping my openvpn linux connection from my laptop would fail and I’d be able to troubleshoot locally on my laptop.

1 Like

@hansome

Where are the OpenVPN client logs redirected to?

Check with command:

logread -e ovpn
1 Like

Besides tunning MTU, check the MSS option- in OpenVPN it is mssfix