GL-SFT1200 after upgrade to 4.8.3 wireguard client disconnects regulary after a while

[schickel]

Setup

• Router: GL-SFT1200 (Opal)
• Mode: WiFi client (connects to home WiFi) + WireGuard client, tunneling to a GL-MT6000 (Flint 3) at home as WireGuard server
• WireGuard endpoint: static home IP (not hostname, ruled out DNS as a factor)
• This setup worked reliably for months before the update.

Problem

After upgrading from (presumably) 4.3.25 to 4.8.3, the WireGuard client interface (wgclient1) disconnects repeatedly, roughly every 5–15 minutes, and sometimes takes a long time to re-establish the tunnel. The home-side Flint 3 (also on 4.8.3-era firmware with Hardware Acceleration + net.bridge.bridge-nf-call-iptables=0 sysctl fix applied) stays up throughout and is unaffected.

Troubleshooting already done

1. Ruled out WiFi client reconnects as the trigger — wgclient1 drops are not correlated with WiFi association/disassociation events in the logs.
2. Ruled out DNS resolution — switched the WireGuard endpoint from hostname to static IP; drops continued.
3. Applied the known Flint 3 NAT-loopback/HNAT sysctl workaround on the SFT1200:

sysctl -w net.bridge.bridge-nf-call-iptables=0
sysctl -w net.bridge.bridge-nf-call-ip6tables=0

This reduced the frequency of plain link is down events somewhat, but disconnects still occurred, now sometimes showing:

wireguard-debug: ACTION=REKEY-GIVEUP

4. Noted that Hardware/Network Acceleration is enabled, and the UI itself warns "VPN with IPv6 doesn't work properly" when it's on. My WireGuard interface config includes an IPv6 address alongside IPv4 — haven't yet isolated this as the cause since I reverted before testing it in isolation.
5. As a last resort, downgraded back to 4.3.25 (last version I had before 4.8.3) using Local Upgrade with Keep Settings disabled. So far the tunnel (now wgclient, non-numbered interface name) has stayed up without a single disconnect, going through several successful periodic rekeys.

Question

What changed in the WireGuard client / VPN module or the network acceleration (HNAT) handling between 4.3.25 and 4.8.3 that could cause this? Is the IPv6-over-VPN + Hardware Acceleration interaction a known issue for routed (non-bridge) WAN traffic, similar to the bridge NAT loopback issue previously reported for the Flint 3?

Logs (4.8.3, before downgrade)

Thu Jul 30 14:19:41 2026 daemon.notice netifd: Network device 'wgclient1' link is down
Thu Jul 30 14:19:41 2026 user.notice firewall: Reloading firewall due to ifdown of wgclient1 ()
Thu Jul 30 14:19:45 2026 daemon.notice netifd: Interface 'wgclient1' is now down
[... reconnect attempts with exponential backoff over ~2.5 minutes ...]
Thu Jul 30 14:22:19 2026 daemon.notice netifd: wgclient1 (13361): Configuration parsing error



Thu Jul 30 15:19:04 2026 user.notice wireguard-debug: USER=root ifname=wgclient1 ACTION=REKEY-GIVEUP ...
Thu Jul 30 15:19:12 2026 daemon.notice netifd: Interface 'wgclient1' is now down
Thu Jul 30 15:19:12 2026 daemon.notice netifd: Interface 'wgclient1' is setting up now
Thu Jul 30 15:21:00 2026 user.notice wireguard-debug: ... ACTION=REKEY-GIVEUP

Thu Jul 30 15:17:08 2026 daemon.notice netifd: Network device 'wgclient1' link is down

Thu Jul 30 15:17:08 2026 user.notice firewall: Reloading firewall due to ifdown of wgclient1 ()

Thu Jul 30 15:17:12 2026 daemon.notice netifd: Interface 'wgclient1' is now down

Thu Jul 30 15:17:13 2026 daemon.notice netifd: Interface 'wgclient1' is setting up now

Thu Jul 30 15:17:13 2026 user.notice relay: Reloading relay due to ifdown of wgclient1 ()

Thu Jul 30 15:19:04 2026 user.notice wireguard-debug: USER=root ifname=wgclient1 ACTION=REKEY-GIVEUP SHLVL=1 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/

Thu Jul 30 15:19:12 2026 daemon.notice netifd: Interface 'wgclient1' is now down

Thu Jul 30 15:19:12 2026 daemon.notice netifd: Interface 'wgclient1' is setting up now

Thu Jul 30 15:20:21 2026 kern.info kernel: [ 1008.674510] hb-fmac 17800000.wifi-hb wlan1: Del key for sta 1 (92:da:31:eb:08:fa)

Thu Jul 30 15:20:21 2026 kern.info kernel: [ 1008.682725] hb-fmac 17800000.wifi-hb wlan1: Del key for sta 1 (92:da:31:eb:08:fa)

Thu Jul 30 15:20:21 2026 kern.info kernel: [ 1008.691495] hb-fmac 17800000.wifi-hb wlan1: Del key for sta 1 (92:da:31:eb:08:fa)

Thu Jul 30 15:20:21 2026 kern.info kernel: [ 1008.699618] hb-fmac 17800000.wifi-hb wlan1: Del sta 1 (92:da:31:eb:08:fa)

Thu Jul 30 15:21:00 2026 user.notice wireguard-debug: USER=root ifname=wgclient1 ACTION=REKEY-GIVEUP SHLVL=1 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/

Thu Jul 30 15:21:08 2026 daemon.notice netifd: Interface 'wgclient1' is now down

Thu Jul 30 15:21:08 2026 daemon.notice netifd: Interface 'wgclient1' is setting up now

Thu Jul 30 15:21:14 2026 daemon.info dnsmasq[18874]: reading /tmp/resolv.conf.d/resolv.conf.wgclient1

Thu Jul 30 15:21:14 2026 daemon.info dnsmasq[18874]: reading /tmp/resolv.conf.d/resolv.conf.wgclient1

Thu Jul 30 15:21:14 2026 kern.info kernel: [ 1061.178984] IPv6: ADDRCONF(NETDEV_UP): wgclient1: link is not ready

Thu Jul 30 15:21:14 2026 daemon.notice netifd: Interface 'wgclient1' is now up

Thu Jul 30 15:21:14 2026 daemon.notice netifd: Network device 'wgclient1' link is up

Thu Jul 30 15:21:15 2026 user.notice firewall: Reloading firewall due to ifup of wgclient1 (wgclient1)

Thu Jul 30 15:21:17 2026 user.notice relay: Reloading relay due to ifup of wgclient1 (wgclient1)






Thu Jul 30 15:26:46 2026 daemon.notice netifd: Network device 'wgclient1' link is down

Thu Jul 30 15:26:47 2026 user.notice firewall: Reloading firewall due to ifdown of wgclient1 ()

Thu Jul 30 15:26:51 2026 user.notice relay: Reloading relay due to ifdown of wgclient1 ()

Thu Jul 30 15:26:51 2026 daemon.notice netifd: Interface 'wgclient1' is now down

Thu Jul 30 15:26:51 2026 daemon.notice netifd: Interface 'wgclient1' is setting up now

Thu Jul 30 15:27:03 2026 daemon.info dnsmasq[18874]: reading /tmp/resolv.conf.d/resolv.conf.wgclient1

Thu Jul 30 15:27:03 2026 daemon.info dnsmasq[18874]: reading /tmp/resolv.conf.d/resolv.conf.wgclient1

Thu Jul 30 15:27:03 2026 kern.info kernel: [ 1410.231287] IPv6: ADDRCONF(NETDEV_UP): wgclient1: link is not ready

Thu Jul 30 15:27:03 2026 daemon.notice netifd: Interface 'wgclient1' is now up

Thu Jul 30 15:27:03 2026 daemon.notice netifd: Network device 'wgclient1' link is up

Thu Jul 30 15:27:04 2026 user.notice firewall: Reloading firewall due to ifup of wgclient1 (wgclient1)

Thu Jul 30 15:27:06 2026 user.notice relay: Reloading relay due to ifup of wgclient1 (wgclient1)

Happy to provide full logs, wg show output, or test further configurations if that helps narrow this down.

ADDED:
Additional finding: Keep Settings across the 4.8.x VPN module rewrite

I upgraded from 4.3.25 to 4.8.3 with "Keep Settings" enabled. Given that GL.iNet's own 4.8 release announcement states the VPN module was rebuilt from the ground up, I suspect my existing WireGuard client config (in the old module's format) was carried over and misinterpreted by the new parser — consistent with an early log entry I saw:

netifd: wgclient1 (13361): Configuration parsing error

After downgrading back to 4.3.25 with Keep Settings disabled (forcing a fresh config), the tunnel has been rock-solid for 50+ minutes with clean rekeys every 2 minutes — a stark contrast to the frequent drops on 4.8.3.

If that's indeed what happened, this needs to be handled properly on GL.iNet's end: a major internal rewrite like the VPN module should either migrate old configs automatically and correctly, or the upgrade process should clearly warn users that Keep Settings isn't safe across this specific change — not silently produce a config that mostly works but fails intermittently. Users shouldn't have to reverse-engineer config incompatibilities through hours of log analysis to find out their settings weren't actually kept correctly.

[charles2]

Hi,

Thank you for providing the detailed information.

Firmware 4.8 introduced a redesigned VPN function and configuration framework, including changes to VPN policy routing and tunnel management.
Since firmware 4.8.3 was previously installed with Keep Settings enabled, it is possible that retaining and migrating the configuration from 4.3.25 affected the new VPN framework.

Could you please upgrade to firmware 4.8.3 again without selecting Keep Settings , and then manually recreate or re-import the same WireGuard client profile? Please then observe whether the WireGuard connection still disconnects after running for some time.

@schickel

If that's indeed what happened, this needs to be handled properly on GL.iNet's end: a major internal rewrite like the VPN module should either migrate old configs automatically and correctly, or the upgrade process should clearly warn users that Keep Settings isn't safe across this specific change — not silently produce a config that mostly works but fails intermittently. Users shouldn't have to reverse-engineer config incompatibilities through hours of log analysis to find out their settings weren't actually kept correctly.

We have recorded your questions and feedback and submitted them to the relevant team for further evaluation.

Thank you again for your assistance and patience.

[schickel]

Hi @charles2

Thank you for the response and for confirming the root cause.

Update: I already performed exactly this test on my own before receiving your reply — I upgraded to 4.8.3 again with Keep Settings disabled, and manually recreated the WireGuard client profile from scratch (rather than importing/migrating the old one). The connection has now been stable for 5 days with no disconnects, clean periodic rekeys, and no REKEY-GIVEUP events. So this confirms your diagnosis: the issue was specifically the migrated/retained config from 4.3.25 conflicting with the new VPN framework in 4.8.3, not a general 4.8.3 bug.

One piece of feedback I'd like to pass along: the 4.8.3 release notes describe the new VPN framework (multi-instance support, IPv6 support, policy routing) as new features and optimizations, but nothing in the notes indicates that this is a breaking change for existing VPN client configurations carried over via Keep Settings. For a router that's frequently used as a dedicated VPN gateway — which I'd guess is a common use case for the SFT1200 specifically, given its size and purpose — this is a significant gap. Users relying on it for daily connectivity have no way to anticipate that a routine "Keep Settings" upgrade could silently produce an unstable configuration that only manifests as intermittent disconnects over hours, rather than an obvious failure.

I'd suggest that when a firmware version introduces structural changes to a core function like VPN (or similarly critical subsystems), the release notes explicitly flag it as a breaking change and recommend disabling Keep Settings and reconfiguring manually — the way major version bumps in other software ecosystems typically call out breaking changes separately from regular feature additions. That would have saved me (and likely others) a fair amount of diagnostic time.

Thanks again for looking into this.

[charles2]

Hi,

Thank you for the detailed update.

We have recorded your suggestion and forwarded it to the relevant team for further evaluation.
Thank you again for sharing your findings and helping us improve the firmware upgrade experience.