AC5300 - GUI turns sluggish with OpenVPN connection issues

[vtol]

RT-AC5300
CPU Model ARMv7 Processor rev 0 (v7l) (Cores: 2)
Firmware Version 384.4_beta1

If not mistaken the issue started to appear around 380.68(_2) and still happens with 384.4_beta1 (done the factory reset and manual reconfiguration)

Whenever the OpenVPN client on the router is facing connection issues with the remote OpenVPN server and keeps on reestablishing the connection the router GUI turns sluggish to a point where it becomes almost unresponsive. Not certain but it seems that the CPU is spiking during such occurrence.

The GUI does not recover until the router is rebooted, even if the OpenVPN connection been successfully reestablished. Like something stuck in the CPU cycle or memory.

The OpenVPN connection issue

ovpn-client1 Inactivity timeout (--ping-restart), restarting
ovpn-client1 SIGUSR1[soft,ping-restart] received, process restarting
ovpn-client1 Restart pause, 5 second(s)

OpenVPN Client Settings

daemon ovpn-client1
client
dev tun11
proto udp
remote vpn.domain.com 443
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo adaptive
ncp-ciphers AES-256-GCM:AES-256-CBC
auth RSA-SHA256
script-security 2
route-delay 2
route-up vpnrouting.sh
route-pre-down vpnrouting.sh
verb 3
ca ca.crt
verify-x509-name "vpn.domain.com" name
auth-user-pass up
status-version 2
status status 5

# Custom Configuration
persist-remote-ip
keepalive 10 60
tls-version-min 1.2
ecdh-curve secp384r1
fast-io
dhcp-option DNS ip1.ip2
tls-cipher HIGH:!EXP:!LOW:!MEDIUM:!SRP:!kRSA

 

[daviworld]

RT-AC5300
CPU Model ARMv7 Processor rev 0 (v7l) (Cores: 2)
Firmware Version 384.4_beta1

If not mistaken the issue started to appear around 380.68(_2) and still happens with 384.4_beta1 (done the factory reset and manual reconfiguration)

Whenever the OpenVPN client on the router is facing connection issues with the remote OpenVPN server and keeps on reestablishing the connection the router GUI turns sluggish to a point where it becomes almost unresponsive. Not certain but it seems that the CPU is spiking during such occurrence.

The GUI does not recover until the router is rebooted, even if the OpenVPN connection been successfully reestablished. Like something stuck in the CPU cycle or memory.

The OpenVPN connection issue

ovpn-client1 Inactivity timeout (--ping-restart), restarting
ovpn-client1 SIGUSR1[soft,ping-restart] received, process restarting
ovpn-client1 Restart pause, 5 second(s)

OpenVPN Client Settings

daemon ovpn-client1
client
dev tun11
proto udp
remote vpn.domain.com 443
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo adaptive
ncp-ciphers AES-256-GCM:AES-256-CBC
auth RSA-SHA256
script-security 2
route-delay 2
route-up vpnrouting.sh
route-pre-down vpnrouting.sh
verb 3
ca ca.crt
verify-x509-name "vpn.domain.com" name
auth-user-pass up
status-version 2
status status 5

# Custom Configuration
persist-remote-ip
keepalive 10 60
tls-version-min 1.2
ecdh-curve secp384r1
fast-io
dhcp-option DNS ip1.ip2
tls-cipher HIGH:!EXP:!LOW:!MEDIUM:!SRP:!kRSA

hi vtol,

I get log's such as

ovpn-client1 Inactivity timeout (--ping-restart), restarting
ovpn-client1 SIGUSR1[soft,ping-restart] received, process restarting
ovpn-client1 Restart pause, 5 second(s)

from Torguard all the time, and it doe's sometime lock the GUI for me, such as loading halfway, or loading nonfunctional. However, I have never had to do a manual reboot to fix it. Usually clicking another tab to load me into fixes the GUI to where it is functional again.

However, I did report a problem in the 384.4 beta thread about a possible performance issue, when logging into the webUI over WIFI, so not sure if the two are related.

So far I have been unable to reproduce your issue completely, to where I require a manual reboot, but all the other symptoms I was able to experience. So, maybe somebody else with a rt-5300 can confirm the reboot part.

Have you also checked in with your VPN provider to see if they have done any recent backend changes? That happened to me a few time's over the year's which required downloading new config's from them to fix connection issue's I was having after being told they changed this or that on a server I was using.

 

[vtol]

With 384.4_beta1 everything was done from scratch and with the latest OpenVPN settings from the VPN provider. Latter got a nice applet for tomato fw but not for wrt.

Anyway, those timeouts are rather infrequent and reckon not an uncommon occurrence in connectivity in general, considering that no provider has a 100% up time, notwithstanding all/any nodes in between.

Those interruption are mostly only noticed when Block routed clients if tunnel goes down is set to yes, which it is in this case. And maybe that is related to the issue.
So one would investigate a VPN connection interruption by logging into the router GUI and then facing the sluggishness.

The point is rather that any such OpenVPN connection issue should not impede the GUI in any way.

Commonly I log into the router over Wifi, since you mentioned it, and perhaps is related thus.

 

[daviworld]

With 384.4_beta1 everything was done from scratch and with the latest OpenVPN settings from the VPN provider. Latter got a nice applet for tomato fw but not for wrt.

Anyway, those timeouts are rather infrequent and reckon not an uncommon occurrence in connectivity in general, considering that no provider has a 100% up time, notwithstanding all/any nodes in between.

Those interruption are mostly only noticed when Block routed clients if tunnel goes down is set to yes, which it is in this case. And maybe that is related to the issue.
So one would investigate a VPN connection interruption by logging into the router GUI and then facing the sluggishness.

The point is rather that any such OpenVPN connection issue should not impede the GUI in any way, never mind whether a reboot is needed or not to restore to proper working conditions.

Commonly I log into the router over Wifi, since you mentioned it, and perhaps is related thus.

Agreed, and I also block my routed client's. Do you have https, http, or both for wan logon?

I have mines set to https, and Rmerlin suggested http. Said https is quirky and causes frequent stalls.

I won't be able to test it myself for a couple hour's, but might help solve the GUI issue

Sent from my LG-H830 using Tapatalk

 

[vtol]

do not see a point of https login in a local environment, the connection is already encrypted with wpa2 and if that cannot be trusted than better go wire or stay offline entirely. Just my 2 cent and thus login only through http.

 

[daviworld]

do not see a point of https login in a local environment, the connection is already encrypted with wpa2 and if that cannot be trusted than better go wire or stay offline entirely. Just my 2 cent and thus login only through http.

It was during the entire KRACK fiasco, when I set it to that, which was patched by RMerlin, then ASUS shortly after. I do a bit a penetrative testing for client's sometimes, so my perception towards security is a bit more paranoid than most

Sent from my LG-H830 using Tapatalk

 

[Twohothardware]

I have a similar issue on the RT-AC86U. Any time a setting is not perfect on the VPN client and I turn it on if it has any connection trouble it completely freezes up the router page and I have to either manually reboot the router or wait 1-2 minutes for the page to finally load again so I can disable the VPN. It does it on both 384.3 and the latest 384.4 beta firmware.