Openvpn client - pings work, no other traffic routes

Technical Support for Routers VPN, DNS, Leaks
1

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#
2

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

3

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.

4

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

5

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.

6

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

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.

8

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.

9

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.

10

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

11

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”

12

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.

13

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

14

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
15

@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
16

@hansome

Where are the OpenVPN client logs redirected to?

17

Check with command:

logread -e ovpn
1 Like
18

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

1 Like
19

Was there a fix for this? I seemingly have the same issue with my Slate AX.

I’m trying to use the Slate AX to redirect all client traffic thru an OpenVPN running on a remote Asus AC68U. The Slate connects to the OpenVPN server, obtains an IP address, has the route pushed (verified with ‘route -e’), but I’m unable to get any traffic to flow. I cannot ping the OpenVPN server gateway address from the Slate or from the Slate’s clients.

As OP experienced, the same OpenVPN client config works perfectly from Windows, iOS, another Asus router, and from an old router running current FreshTomato. It is only the Slate that is having this issue.

But here’s another twist - When I tether the Slate to my iPhone (using US T-mobile) it works! That said, I’ve checked that I’m not using the same subnet within these paths, so there doesn’t appear to be a routing issue.

My architecture path from client to server:
Client1 (192.168.8.101)
Slate AX (GW 192.168.8.1, LAN client 192.168.5.126, OpenVPN client 192.168.71.2)
AX86U (GW 192.168.5.1)
WAN
Cox (GW 192.168.0.1)
AC68U (GW 192.168.10.1, LAN client 192.168.0.156, OpenVPN server 192.168.71.1)

MTU was mentioned earlier in this thread. I have tested, and the highest success is with ‘ping google.com -f -l 1472’, meaning my MTU should be fine at 1500 (1472 + 28). However, I am seeing this in the connect logs:

Sun Nov 19 14:09:02 2023 daemon.warn ovpnclient[19089]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1372)
Sun Nov 19 14:09:07 2023 daemon.notice ovpnclient[19089]: TCP/UDP: Preserving recently used remote address: [AF_INET]w.x.y.z:1194
Sun Nov 19 14:09:07 2023 daemon.notice ovpnclient[19089]: UDP link local: (not bound)
Sun Nov 19 14:09:07 2023 daemon.notice ovpnclient[19089]: UDP link remote: [AF_INET]w.x.y.z:1194
Sun Nov 19 14:09:07 2023 daemon.warn ovpnclient[19089]: WARNING: ‘link-mtu’ is used inconsistently, local=‘link-mtu 1425’, remote=‘link-mtu 1569’
Sun Nov 19 14:09:07 2023 daemon.warn ovpnclient[19089]: WARNING: ‘tun-mtu’ is used inconsistently, local=‘tun-mtu 1372’, remote=‘tun-mtu 1500’
Sun Nov 19 14:09:07 2023 daemon.notice ovpnclient[19089]: [RT-AC68U] Peer Connection Initiated with [AF_INET]w.x.y.z:1194
Sun Nov 19 14:09:08 2023 daemon.notice ovpnclient[19089]: TUN/TAP device ovpnclient opened
Sun Nov 19 14:09:08 2023 daemon.notice ovpnclient[19089]: net_iface_mtu_set: mtu 1372 for ovpnclient
Sun Nov 19 14:09:08 2023 daemon.notice ovpnclient[19089]: net_iface_up: set ovpnclient up
Sun Nov 19 14:09:08 2023 daemon.notice ovpnclient[19089]: net_addr_v4_add: 192.168.71.2/24 dev ovpnclient
Sun Nov 19 14:09:08 2023 daemon.notice ovpnclient[19089]: /etc/openvpn/scripts/ovpnclient-up ovpnclient 0 ovpnclient 1372 1424 192.168.71.2 255.255.255.0 init
Sun Nov 19 14:09:08 2023 daemon.info avahi-daemon[3946]: Joining mDNS multicast group on interface ovpnclient.IPv4 with address 192.168.71.2.
Sun Nov 19 14:09:08 2023 daemon.info avahi-daemon[3946]: New relevant interface ovpnclient.IPv4 for mDNS.
Sun Nov 19 14:09:08 2023 daemon.info avahi-daemon[3946]: Registering new address record for 192.168.71.2 on ovpnclient.IPv4.
Sun Nov 19 14:09:08 2023 user.notice ovpnclient-up: env value:route_vpn_gateway=192.168.71.1 X509_0_emailAddress=me@asusrouter.lan daemon_log_redirect=0 X509_1_emailAddress=me@asusrouter.lan script_type=up proto_1=udp daemon=0 SHLVL=1 foreign_option_1=dhcp-option DNS 192.168.10.1 dev_type=tun route_network_1=192.168.10.0 remote_1=.asuscomm.com dev=ovpnclient X509_0_CN=RT-AC68U X509_0_C=TW remote_port_1=1194 X509_1_CN=RT-AC68U X509_1_C=TW ifconfig_netmask=255.255.255.0 tls_digest_sha256_0= daemon_start_time=1700431742 script_context=init ifconfig_local=192.168.71.2 common_name=RT-AC68U tls_digest_sha256_1= X509_0_L=Taipei verb=1 X509_1_L=Taipei link_mtu=1424 X509_0_O=ASUS route_gateway_1=192.168.71.1 trusted_ip=w.x.y.z tls_serial_hex_0= X509_1_O=ASUS tun_mtu=1372 route_netmask_1=

In the gl-inet GUI, I’ve tried setting the OpenVPN MTU to 1500, and then trial and error on down, and nothing seems to change.

Anyone have ideas if MTU is even the culprit, or any ideas what I should try next?

Edit: I’m using Slate AX firmware 4.2.3. The OpenVPN server is an Asus AC68U running AsusWRT Merlin 386.7_2. OpenVPN server config is using 2048/SHA256.

20

Do you have compress option enabled? Could you PM me your config for a try?