Slate AXT1800 OpenVPNClient error since update 4.4.5

Hi,

Since the last 4.4.5 update I performed today, I have an error when connecting OpenVPN client to NordVPN.
Curiously, after restarting the system, there is no error and it works fine on the first VPN connection. But as soon as I cut the VPN connection, unable to reconnect without error on all other attempts :frowning:

In the logs, the error is as follows:

daemon.err ovpnclient[ā€¦]: write UDP: Operation not permitted (code=1)

Looking on the internet I think the problem could come from the firewall rules: I opened UDP ports 500 and 1194 from the interface but there is still the error :frowning:

So there is something in the update that caused this.

If someone has an idea ?

Robin

1 Like

Just reinstall the previous firmware version that was working.

I do not work for and I am not directly associated with GL.iNet

This bug will be fixed in 4.4.6.

Can I just say that Iā€™ve got this error, still in 4.5 and 4.5.16 on a MT2500

My OVPN connections to PureVPN just stop working with the above firmware, the only way I can fix it is to roll back to 4.4.6 when it was fixed last.

It connects, then multiple write UDP errors, then it disconnects and canā€™t connect any more with ā€œunable to resolve hostā€ errors which continue till the client is stopped and restarted.

Perhaps the devs need to incorporate the fix from 4.4.6 into 4.5 and above?

I tested ā€œDE-ovpn-udp.ovpnā€, it works on firmware 4.5.16.
Whatā€™s the server youā€™re trying to connect to?

I also experienced connection failure due to an unstable network.

Sat Apr 27 23:59:22 2024 daemon.err ovpnclient[19343]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Apr 27 23:59:22 2024 daemon.err ovpnclient[19343]: TLS Error: TLS handshake failed

This error is gone after I change to another access network.

1 Like

Iā€™m using a PureVPN dedicated IP UK server with port forwarding.

Basically with 4.6 I get 20+ lines of:

Sun Apr 28 14:12:11 2024 daemon.err ovpnclient[22782]: write UDP: Operation not permitted (code=1)

Then it looks like it connects, it gets the correct IP address then I get this:

 Sun Apr 28 14:14:13 2024 daemon.notice ovpnclient[22782]: [Secure-Server] Inactivity timeout (--ping-restart), restarting

Then it withdraws the address, tries to restart with:

Sun Apr 28 14:14:13 2024 daemon.notice netifd: Interface 'ovpnclient' has lost the connection
Sun Apr 28 14:14:13 2024 daemon.notice netifd: ovpnclient (22782): sh: 1: unknown operand
Sun Apr 28 14:14:13 2024 user.notice firewall: Reloading firewall due to ifdown of ovpnclient ()
Sun Apr 28 14:14:13 2024 daemon.notice ovpnclient[22782]: SIGHUP[soft,ping-restart] received, process restarting
Sun Apr 28 14:14:13 2024 daemon.notice ovpnclient[22782]: OpenVPN 2.5.3 aarch64-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Sun Apr 28 14:14:13 2024 daemon.notice ovpnclient[22782]: library versions: OpenSSL 1.1.1q  5 Jul 2022, LZO 2.10
Sun Apr 28 14:14:18 2024 daemon.warn ovpnclient[22782]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sun Apr 28 14:14:23 2024 daemon.err ovpnclient[22782]: RESOLVE: Cannot resolve host address:

Which it then repeats with a sighup and tries to restart.

Can you PM me the remote option of your OpenVPN config file? like
image

Do you mean firmware version 4.5.16?

1 Like

Yes sorry. Whenever I upgrade past 4.4.6 it gives the problem I outlined.

So upgrade, reboot, get problem, downgrade firmware, reboot, problem goes away, nothing else changes, keeping settings each time.

Iā€™ll send you that line out of the config file by PM, actually I donā€™t know how to send a PM on this platform.

[edit, worked out you PMā€™ed me first, so I replied]

1 Like

I found the DNS server is not correct when the OpenVPN connection drops under some scenarios for firmware 4.5.x.

Thatā€™s why it prints log like this:

Sun Apr 28 14:14:23 2024 daemon.err ovpnclient[22782]: RESOLVE: Cannot resolve host address:

The temporary workaround is to patch code:

sed -i 's_^\t\[ -f "/tmp/resolv.conf.d_\[ -z "$ACTION" -a -f "/tmp/resolv.conf.d_' /usr/bin/route_policy

Fireware 4.6 will address this issue.

1 Like

So for sake of anyone else with the issue, the fix above didnā€™t fix the issue of the VPN not working, it did stop the DNS error but the VPN doesnā€™t route traffic.

Iā€™m still working with support, hopefully we get to the bottom of it.

Hi,

After analyzing log, I guess it is route loop for this case.
Please try using the command to patch the code.

sed -i '/trusted_ip/a ip route add $(ip route get "$trusted_ip" |head -1)' /etc/openvpn/scripts/ovpnclient-up

This is only needed for PureVPN dedicated IP.

1 Like

Still not working unfortunately

With the new firmware canā€™t even ping or traceroute or resolve from the command line of the router when the VPN is connected.

1 Like

After debugging, we found the workaround for ā€œPureVPN dedicated IPā€ connection failure, by patching the code:
(Only applies to 4.5.x firmware, mt2500/mt3000/mt6000)

# fixed dns not correct when vpn connection drops
sed -i 's_^\t\[ -f "/tmp/resolv.conf.d_\[ -z "$ACTION" -a -f "/tmp/resolv.conf.d_' /usr/bin/route_policy
# fixed route loop(remote server is routed through ovpnclient interface) when the tunnel ip is a public ip address
sed -i '/trusted_ip/a proto_add_host_dependency "${interface}" "${trusted_ip}"' /etc/openvpn/scripts/ovpnclient-up

Thereā€™s patch will be merged into later firmware version 4.6.
Much appreciated for help debug.@Biffa

2 Likes

Can confirm, all seems good now. Glad to help, and glad it was caught, donā€™t like running old firmware on something on the edge of my network like that. :grimacing:

1 Like