ASUS Merlin with NordVPN OpenVPN Client latency issues

[matdzi86]

Hello team!

Total noob here so please forgive me if I say something stupid I've been running OpenVPN Klient from NordVPN on my Asus GT-AX11000 router for some time now and keep getting latency issues randomly but regularly - simple pings to google.com dropping, for example, response time going up:

That wouldn't bother me much most likely if it wasn't for the fact that while doing video/audio calls, that little connection drop results in me not understanding what others are saying and vice-versa.

Pretty standard configuration here, NordVPN support folks have no idea what's causing it and they offer no help:

Custom Configuration:

remote-random
resolv-retry infinite
remote-cert-tls server
ping 15
ping-restart 0
ping-timer-rem
persist-key
persist-tun
reneg-sec 0
fast-io
disable-occ
mute-replay-warnings
auth-nocache
sndbuf 524288
rcvbuf 524288
push "sndbuf 524288"
push "rcvbuf 524288"
pull-filter ignore "auth-token"
pull-filter ignore "ifconfig-ipv6"
pull-filter ignore "route-ipv6"
explicit-exit-notify 3
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450

#log /tmp/vpn.log

DNS:

Some additional details:

* firmware is up to date on the router
* I'm using eth cable to connect to the router, not WiFi
* the same happens on TCP as it does on UDP.
* I have to use a specific NordVPN server due to the dedicated IP associated with it;
* when I disable the VPN client, the issue disappears;

Nothing in the System Logs when drops happen that I would think indicates OpenVPN issues:


Apr 23 07:32:20 rc_service: httpd 1530:notify_rc restart_firewall;restart_pppoe_relay
Apr 23 07:34:41 roamast: [EXAP]Deauth old sta in 0 0: 9A1:CD:B3:F1:FF
Apr 23 07:34:41 roamast: eth6: disconnect weak signal strength station [9a:d1:cd:b3:f1:ff]
Apr 23 07:34:41 roamast: eth6: remove client [9a:d1:cd:b3:f1:ff] from monitor list
Apr 23 07:34:43 wlceventd: wlceventd_proc_event(491): eth6: Deauth_ind 9A1:CD:B3:F1:FF, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Apr 23 07:34:43 wlceventd: wlceventd_proc_event(491): eth6: Deauth_ind 9A1:CD:B3:F1:FF, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Apr 23 07:34:43 wlceventd: wlceventd_proc_event(491): eth6: Deauth_ind 9A1:CD:B3:F1:FF, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Apr 23 07:34:44 wlceventd: wlceventd_proc_event(508): eth6: Disassoc 9A1:CD:B3:F1:FF, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Apr 23 07:34:45 wlceventd: wlceventd_proc_event(527): eth7: Auth 9A1:CD:B3:F1:FF, status: Successful (0), rssi:0
Apr 23 07:34:45 wlceventd: wlceventd_proc_event(537): eth7: ReAssoc 9A1:CD:B3:F1:FF, status: Successful (0), rssi:0
Apr 23 07:35:58 roamast: [EXAP]Deauth old sta in 1 0: 9A1:CD:B3:F1:FF
Apr 23 07:35:58 roamast: eth7: disconnect weak signal strength station [9a:d1:cd:b3:f1:ff]
Apr 23 07:35:58 roamast: eth7: remove client [9a:d1:cd:b3:f1:ff] from monitor list
Apr 23 07:36:01 wlceventd: wlceventd_proc_event(491): eth7: Deauth_ind 9A1:CD:B3:F1:FF, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Apr 23 07:36:01 wlceventd: wlceventd_proc_event(491): eth7: Deauth_ind 9A1:CD:B3:F1:FF, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Apr 23 07:36:01 wlceventd: wlceventd_proc_event(491): eth7: Deauth_ind 9A1:CD:B3:F1:FF, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Apr 23 07:36:02 wlceventd: wlceventd_proc_event(508): eth7: Disassoc 9A1:CD:B3:F1:FF, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Apr 23 07:56:42 rc_service: cfg_server 2249:notify_rc email_info
Apr 23 07:59:30 wlceventd: wlceventd_proc_event(491): eth7: Deauth_ind BA:71:94:98:E0:F8, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Apr 23 07:59:30 wlceventd: wlceventd_proc_event(491): eth7: Deauth_ind BA:71:94:98:E0:F8, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Apr 23 07:59:31 wlceventd: wlceventd_proc_event(508): eth7: Disassoc BA:71:94:98:E0:F8, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

If anyone has time, could I ask you to give the above a quick look and possibly recommend some solutions to try or at least to let me know if this is somewhat normal or not?

Thanks in advance,
Mat

 

[Turgut Kalfaoglu]

Especially if you'd like a server in Europe: I recommend our VPN service over others. Far faster since the VPN server is very idle and fast. Not to mention direct connection to the admin via whatsapp/messager
Details here https://kalfaoglu.net/index.php?rp=/store/vpnbulutreklamcilikvs
Sorry this sounds like an ad, but I just wanted to help.

 

[ColinTaylor]

* when I disable the VPN client, the issue disappears;

Doing video/audio calls over a commercial VPN service (like NordVPN) is a bad idea. Can't you exclude the calls from your VPN. Why are you using a VPN at all?

 

[Viktor Jaep]

Hello team!

Total noob here so please forgive me if I say something stupid I've been running OpenVPN Klient from NordVPN on my Asus GT-AX11000 router for some time now and keep getting latency issues randomly but regularly - simple pings to google.com dropping, for example, response time going up:

Some additional details:

* firmware is up to date on the router
* I'm using eth cable to connect to the router, not WiFi
* the same happens on TCP as it does on UDP.
* I have to use a specific NordVPN server due to the dedicated IP associated with it;
* when I disable the VPN client, the issue disappears;

If anyone has time, could I ask you to give the above a quick look and possibly recommend some solutions to try or at least to let me know if this is somewhat normal or not?

Thanks in advance,
Mat

@matdzi86 As you mentioned, it all looks pretty standard, and matches my NordVPN setup exactly. The only thing I would suggest is perhaps choosing a different NordVPN endpoint server, and see if that makes any difference. I know you said you have to make a connection to a specific one due to a IP issue... but if you have any way to test this, that would be one way to eliminate to see whether or not this NordVPN server you're connecting to has issues, or is experiencing a heavy load. In the tool I wrote (VPNMON-R2), I specifically check to see whether or not the NordVPN server I'm connecting to stays within a 50% load or below, or it just goes out and connects to another one to make sure we've got a good connection going.

 

[SheikhSheikha]

Your problems described the problems that a friend of mine has who is fibred almost directly into the AMSIX in Amsterdam. When we configured his router with my VPN services there was a significant difference in speed, not favouring a positive verdict for NordVPN.
I use ExpressVPN to my full satisfaction but I am sure that there are alternatives (e.g. ProtonVPN) that at least perform way better than NordVPN. I live in a country with a serious governmental firewall and encounter latency too (obviously) but never in the way you demonstrate above. My 5 cents: change your vpn provider.

 

[MeasurementRick]

Keep in mind that OpenVPN is single-threaded (and your router is quad core) so that alone represents a considerable performance bottleneck vs. a protocol like Wireguard.

One thing you could try:

1. Use the split-tunneling capability in the Merlin "VPN Director". Specifically, add your laptop (or desktop) as an exception to your VPN, allowing it to bypass the VPN and connect to the WAN directly.
2. Install the NordVPN client app on your laptop (or desktop).
3. See what the performance is like using OpenVPN via the NordVPN client.
4. (optional) See what the performance is like using Wireguard (what they call "NordLynx") via the NordVPN client.

You may be able to get much better performance that way, or at least reduce the latency you're seeing now.

 

[TrebleTA]

Check out WinMTR, I use it to test connections for dropped packets, it's a very old app

 

[Tech Junky]

Now, I know why I use a VPN on the router and not the client PC device but, why are you using it?

OVPN is notoriously bad for speed. Also, it's not dynamic in selecting the best server to use as it's a static config on the router.

I used Nord w/ Nordlynx i.e. WireGuard and get line speeds w/ very little issue. If the router doesn't support it then use the PC client instead.

The other thing to take into account is there might be a download occurring while running your ping test or patches being applied.

64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=101 ttl=118 time=24.7 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=102 ttl=118 time=27.8 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=103 ttl=118 time=26.3 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=104 ttl=118 time=24.7 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=106 ttl=118 time=26.9 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=107 ttl=118 time=25.8 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=108 ttl=118 time=25.5 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=109 ttl=118 time=125 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=110 ttl=118 time=45.9 ms

Started a soeed test:
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=111 ttl=118 time=145 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=112 ttl=118 time=140 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=113 ttl=118 time=255 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=114 ttl=118 time=232 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=115 ttl=118 time=284 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=116 ttl=118 time=281 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=117 ttl=118 time=185 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=118 ttl=118 time=338 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=119 ttl=118 time=160 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=120 ttl=118 time=27.9 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=121 ttl=118 time=26.8 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=122 ttl=118 time=72.5 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=123 ttl=118 time=62.1 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=124 ttl=118 time=53.2 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=125 ttl=118 time=31.8 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=126 ttl=118 time=43.0 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=127 ttl=118 time=35.0 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=128 ttl=118 time=34.3 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=129 ttl=118 time=38.2 ms
64 bytes from dfw25s42-in-f14.1e100.net (142.251.32.206): icmp_seq=130 ttl=118 time=25.1 ms

--- google.com ping statistics ---
138 packets transmitted, 136 received, 1.44928% packet loss, time 137200ms
rtt min/avg/max/mdev = 23.491/41.807/337.941/52.597 ms

Another ping test w/o the saturation of a speed test

--- google.com ping statistics ---
100 packets transmitted, 98 received, 2% packet loss, time 99141ms
rtt min/avg/max/mdev = 23.343/26.615/40.680/2.856 ms