Trouble Reaching Wireguard "Server"-Peer After Boot/Reboot on AXT1800

Hey everyone,

I’ve been encountering a rather perplexing issue with my AXT1800 router and its Wireguard setup. I’m hoping some of you might be able to provide some guidance or insights into resolving this problem.

After boot, the router connects automatically to my Wireguard “server”-peer and everything else works absolutely fine.

The Issue: After performing a clean boot or a reboot on my AXT1800 router, I’m unable to ping or reach the Wireguard “server”-peer using the public IP address.

It doesn’t matter how long i wait. I will always get request timeouts.

However, here’s where it gets interesting: if I disable and then re-enable the Wireguard connection inside of the VPN Dashboard from my AXT1800, I suddenly can ping and reach the public “server”-peer IP just normally again.

I’m a bit lost on where to start with debugging this issue. It’s clear that there’s some sort of hiccup happening during the boot, but I’m not sure what steps to take next.

The device is configured as Router in repeater mode. Apart from that one issue, only affects the connection to the Wireguard Server-IP after reboot, everything works absolutely perfect for me.

  • Openwrt Version: OpenWrt 21.02-SNAPSHOT r16399+159-c67509efd7
  • Kernel Version 4.4.60

Best regards,

Hi jkatnight:

Are you using the official firmware for glinet? What is the version?

Hello, yes i am using the newest official firmware on version 4.2.3.

This is a known bug and will be fixed in the next release.

Hello! :slight_smile:

I’ve updated to the next release, version 4.4.5, and the issue is still persistent.

Could you kindly confirm whether this specific issue is documented as a known bug?

Sorry, this issue is not addressed in version 4.4.5 due to severity.

This happens because accessing the Wireguard Server’s public address is via non-VPN interface if there is a following route:

x.x.x.x via x.x.x.x dev eth0 proto static

The original purpose of that route is to avoid route loop when VPN is on, but non-VPN interface traffic is blocked by the firewall.
That route is not needed anymore while wireguard traffic is marked with fwmark 0x80000.

Deleting that route will make the traffic go via VPN.

ip route del x.x.x.x via x.x.x.x dev eth0 proto static

Thank you for providing the information. I have located the particular rule you referenced.

Given this, is it indeed advisable to automate the deletion of this rule once the connection to the Wireguard Server is established? What would be a simple workaround way to do this? Inside the Wireguard config file? like this for example:

PostUp = ip route del x.x.x.x via x.x.x.x dev eth0 proto static


You can patch the code manually at router SSH terminal, by command:

sed -i '/proto_add_host_dependency/d' /etc/hotplug.d/wireguard/

PostUp is not supported, it’s the wg-tool way.