BRUME : VPN client does not survive a reboot

I have a BRUME with a WireGuard client defined (that works perfectly) connected to VPN.AC.
The software is the latest 3.104.

The problem is that it cannot reconnect after a reboot and displays :
VPN client failed to connect. This may be because of wrong configuration, unsupported parameters or terminated by the server.

Then I have to press Abort, then Connect and it works in a few seconds, every time.

I also have AdGuardHome running.

I guess there is some timing problem and that the VPN client starts too soon before something necessary is available. But I don’t see something related in the System Log that ends with

Wed Sep 23 13:40:52 2020 daemon.notice procd: /etc/rc.d/S99wireguard: * Populating IPv6 mangle table
Wed Sep 23 13:40:52 2020 daemon.notice procd: /etc/rc.d/S99wireguard: * Zone ‘lan’
Wed Sep 23 13:40:52 2020 daemon.notice procd: /etc/rc.d/S99wireguard: * Zone ‘wan’
Wed Sep 23 13:40:52 2020 daemon.notice procd: /etc/rc.d/S99wireguard: * Zone ‘wireguard’
Wed Sep 23 13:40:52 2020 daemon.notice procd: /etc/rc.d/S99wireguard: * Set tcp_ecn to off
Wed Sep 23 13:40:52 2020 daemon.notice procd: /etc/rc.d/S99wireguard: * Set tcp_syncookies to on
Wed Sep 23 13:40:52 2020 daemon.notice procd: /etc/rc.d/S99wireguard: * Set tcp_window_scaling to on
Wed Sep 23 13:40:52 2020 daemon.notice procd: /etc/rc.d/S99wireguard: * Running script ‘/etc/firewall.user’
Wed Sep 23 13:40:52 2020 daemon.notice procd: /etc/rc.d/S99wireguard: iptables: No chain/target/match by that name.
Wed Sep 23 13:40:52 2020 daemon.notice procd: /etc/rc.d/S99wireguard: iptables: No chain/target/match by that name.
Wed Sep 23 13:40:52 2020 daemon.notice procd: /etc/rc.d/S99wireguard: * Running script ‘/usr/bin/glfw.sh’
Wed Sep 23 13:40:53 2020 daemon.notice procd: /etc/rc.d/S99wireguard: * Running script ‘/var/etc/gls2s.include’
Wed Sep 23 13:40:53 2020 daemon.notice procd: /etc/rc.d/S99wireguard: ! Skipping due to path error: No such file or directory
Wed Sep 23 13:40:53 2020 daemon.notice procd: /etc/rc.d/S99wireguard: * Running script ‘/usr/sbin/glqos.sh’
Wed Sep 23 13:40:54 2020 daemon.notice procd: /etc/rc.d/S99wireguard: * Running script ‘/var/etc/mwan3.include’
Wed Sep 23 13:40:59 2020 daemon.notice procd: /etc/rc.d/S99wireguard: Terminated

What can I do ?

I tried using the OpenVPN client instead of the Wireguard client with the same provider (vpn.ac) and it works (the client reestablishes its VPN connection automatically after a reboot).

But I’d rather use Wireguard as it’s the main reason I bought this router. Now, with AdGuardHome, it’s another good reason to use it. Too bad I had to reboot so many times today : I had 11 days of uptime and that was a good sign of a stable router.

Just to confirm, you are using only cable, no wireless.

It is just a common DHCP connection in the WAN?

Sure, no WiFi on BRUME. And I have defined a static IP on the WAN side (192.168.1.32).
Again, both VPN client work perfectly (one at a time) but when the Wireguard client is active and the router is rebooted, the Wireguard VPN client cannot reconnect automatically.

Seems it is a script racing problem. The wireguard scripts should already have some check for interfaces but does not work as expected. We will have a check for vpn.ac

Maybe now you can add in /etc/rc.local

(sleep 30; /etc/init.d/wireguard restart) &

Thank you for your analysis. I will try as soon as I can. Where in the rc.local file should I add what you typed ?

(sleep 30; /etc/init.d/wireguard restart) &

You can just add to the end.

Thank you. I did and it works but I think there could be a side effect. While AdGuardHome starts, it cannot connect to update the block list (it will do it later but now it fails).

Mon Sep 28 16:54:14 2020 user.notice AdGuardHome[3368]: 2020/09/28 14:54:14 [info] Starting the DNS proxy server
Mon Sep 28 16:54:14 2020 user.notice AdGuardHome[3368]: 2020/09/28 14:54:14 [info] Ratelimit is enabled and set to 20 rps
Mon Sep 28 16:54:14 2020 user.notice AdGuardHome[3368]: 2020/09/28 14:54:14 [info] The server is configured to refuse ANY requests
Mon Sep 28 16:54:14 2020 user.notice AdGuardHome[3368]: 2020/09/28 14:54:14 [info] DNS cache is enabled
Mon Sep 28 16:54:14 2020 user.notice AdGuardHome[3368]: 2020/09/28 14:54:14 [info] Creating the UDP server socket
Mon Sep 28 16:54:14 2020 user.notice AdGuardHome[3368]: 2020/09/28 14:54:14 [info] Listening to udp://[::]:3053
Mon Sep 28 16:54:14 2020 user.notice AdGuardHome[3368]: 2020/09/28 14:54:14 [info] Creating the TCP server socket
Mon Sep 28 16:54:14 2020 user.notice AdGuardHome[3368]: 2020/09/28 14:54:14 [info] Listening to tcp://[::]:3053
Mon Sep 28 16:54:14 2020 user.notice AdGuardHome[3368]: 2020/09/28 14:54:14 [info] Entering the UDP listener loop on [::]:3053
Mon Sep 28 16:54:14 2020 user.notice AdGuardHome[3368]: 2020/09/28 14:54:14 [info] Entering the tcp listener loop on [::]:3053
Mon Sep 28 16:54:14 2020 user.notice AdGuardHome[3368]: 2020/09/28 14:54:14 [info] Couldn’t request filter from URL https://adguardteam.github.io/AdGuardSDNSFilter/Filters/filter.txt, skipping: Get “https://adguardteam.github.io/AdGuardSDNSFilter/Filters/filter.txt”: synthetic.wrap: all upstreams failed to exchange request, cause: Failed to get a connection from TLSPool to tls://1.1.1.1:853, cause: Failed to connect to 1.1.1.1, cause: all dialers failed to initialize connection: , cause: dial tcp 1.1.1.1:853: connect: network is unreachable (hidden: Failed to get a connection from TLSPool to tls://dns.quad9.net:853, cause: failed to lookup dns.quad9.net, cause: synthetic.wrap: all resolvers failed to lookup, cause: dial udp 149.112.112.112:53: connect: network is unreachable (hidden: dial udp 9.9.9.9:53: connect: network is unreachable), Failed to get a connection from TLSPool to tls://dns.adguard.com:853, cause: failed to lookup dns.adguard.com, cause: synthetic.wrap: all resolvers failed to lookup, cause: dial udp 149.112.

I think that this problem was there before but I did not noticed it back then. All the processes or programs that try to connect while the VPN is trying to open its tunnel certainly fail.

I have just installed “openwrt-mv1000-emmc-3.105.img” Compile Time 2020-12-07 15:33:22. I had to reset the router (I was warned).

But the problem persists : Wireguard client does not connect to vpn.ac after a reboot. It works when I click on Connect manually.

Can you add this for now

I’m now using openwrt-mv1000-emmc-3.201-0402.img (beta 6 probably) and the problem still exists when I disable AGH (that now eats all RAM after a few days). Would someone from GL look at this and find a real fix ? This is not a new problem.

Hi DeepAnger:
I am very sorry for the problems you have encountered.

I have test ‘openwrt-mv1000-emmc-3.201-0402.img’.But ‘Wireguard’ and ‘AGH’ are all ok after reboot.

1,Does this happen with every reboot?
2,Could you provide configuration of Wiregurad if it is convenient for you?

Hi,

Before I disabled AdguardHome (because it used all RAM) the starting of the VPN after reboot was working. But I restarted the router only a few times. I have restarted less than 10 times since AGH has been disabled but the VPN has never been able to connect automatically. I must go to GL GUI and cancel then manually restart the VPN connection then it works everytime.

I use vpn.ac provider with WireGuard. The connection is selected in france because it is one of the fastest but the same append with germany or netherland. There is Killswitch Enabled and Policy to exclude one local MAC address.


Could you confirm that the policy can only exclude local MAC and not local IP ?

Here is the DNS configuration.

Please note that having a USB wifi adapter seemed to impact if the VPN auto starts (it should NOT). I was something I noticed before : the WG VPN did not start after a reboot then it worked after I added the wifi USB adapter.
https://forum.gl-inet.com/t/brume-mv1000-with-usb-wifi-adapter-observations-and-questions/14083
Now it could be the opposite but I don’t intend to remove it as a “solution”.

Hi,

I have been able to reboot (from the GUI, no power off) and the WG VPN has properly restarted all the 3 times. I don’t know why it did not work the previous days. I’ll report here if that occurs again and keep the syslog next time.

1 Like

Hi DeepAnger:
“Please note that having a USB wifi adapter seemed to impact if the VPN auto starts (it should NOT).”
The network is reinitialized when the VPN is restart.The purpose of this is to avoid data leak.

And next time this happens,you could check first check if “Custom DNS server” is ok.