WireGuard connection drops intermittently on GL.iNet routers in repeater mode, despite showing as connected.
Issue Description:
When my GL.iNet router (models tested: MT3000 and MX1800) operates in Wi-Fi repeater mode, the WireGuard VPN connection regularly drops, even though the WireGuard interface continues to show as “connected” (green status).
To restore the VPN connection, I must repeatedly randomize the router’s MAC address. Sometimes this process works after one attempt; other times, it requires several tries. This is disruptive and happens consistently only in repeater mode.
When the same router is connected via WAN (not repeater mode), the issue rarely occurs—if it does, randomizing the MAC address once typically resolves it.
Suspected Cause:
This appears to be a routing or persistence issue specific to repeater mode, possibly related to how the router manages MAC addresses, ARP, or route tables when connected wirelessly to the upstream network.
Note:
The problem occurs across different GL.iNet firmware versions and models (MT3000 and MX1800), suggesting a possible systemic bug in repeater mode behavior with WireGuard.
Do you think this is a routing problemm or DHCP issue? Maybe i need to change something in LuCi?
When the WireGuard VPN is interrupted, if you disable it at that time, can LAN devices access the internet normally?
-to answer this questions, when wireguard vpn is interrupted, then i disable it and set "All Other Traffic"=True, then YES, the internet is established again but without wireguard. Now at this moment, when i re-turn wireguard on, wireguard turns green and the handshake is successful, but no internet at all (no vpn and of course regular internet because kill switch is enabled). At this point, i then need to randomize the MAC setting several times to finally, hopefully, get a VPN connection. On average, I need to randomize a few times when router is connected via WAN, but when router is connected via REPEATER, it take many more tries (10 times or so).
Are the networks connected via wired WAN and wireless Repeater the same (the Home network)?
-this issue occurs at my office which has both WAN and WIFI (simple password to access it); and this issue also happens at my home where i have both WAN and WIFI. I recall this issue also happening at many other locations too, so it is not localized to my office or home.
Is the Home Wi-Fi a regular network without any restrictions?
-WI-fi is a regular network, simply select the network and enter password (e.g. 12345678). It is not a hotel captive port
Please try going to Admin Panel → VPN → VPN Dashboard and adjusting the MTU to a smaller value, such as 1280 or 1420, to see if it helps.
-i will try that the next time it happens and it will happen again soon. It happens on average 3-5 times a week, and I read other post and it seems others have REPEATER problems too. (i will also send you the log files shortly)
We need to obtain the logs after the issue occurred, or further access the device via GoodCloud to check the situation before we can analyze the problem in more depth.
At present, it appears that the WireGuard VPN may disconnect under certain circumstances.
Are you using a commercial WireGuard VPN provider, or is it self-hosted?
When the issue occurs, if you import the same configuration file into a phone or another device connected to the same network, is it able to connect normally?
i am self-hosted, and my config file on my phone works fine when the issue occurs on the router, it connect normally on my phone.
i will send you the log files right now
From the logs, the router is unable to connect to the WireGuard server.
After the issue occurs again, please try connecting the router to another internet source, such as a mobile hotspot on your phone, and then see whether it can connect normally.
If the problem persists, please follow the tutorial below to share the device with us via GoodCloud, and after the issue occurs again, keep the environment as is and notify us to remote access so we can perform further inspection.
Please note to send the device’s MAC address and Admin Panel password via private message so that we can access the device.
After performing remote packet captures and traceroute tests, along with wget tests on several links, we found that there are certain restrictions on the current network. It allows the first few packets to pass when a connection is initially established, and then blocks the traffic shortly afterward.
As a result, the following behavior occurs:
The router interface shows a green indicator and a Connected status for WireGuard, because communication with the WireGuard server works normally at the very beginning. However, the ISP then blocks the connection, causing WireGuard to stop functioning properly.
After multiple MAC address randomizations, it’s possible that WireGuard, through repeated retries, manages to take advantage of the brief initial window when the connection is allowed. This allows the handshake to complete, after which subsequent traffic can be transmitted normally over the encrypted tunnel.
Since these restrictions are enforced on the ISP side, there isn’t much we can do to resolve this directly.
You may consider using Amnezia WG with obfuscation enabled, which might help bypass these restrictions.
