GL-SFT1200 (Opal) – WAN link drops causing WireGuard REKEY_TIMEOUT and interface down

Routers VPN, DNS, Leaks
1

Hello,

I’m experiencing intermittent WAN drops on a GL.iNet GL-SFT1200 (Opal) router used as a WireGuard client.

Setup

  • Model: GL-SFT1200 (Opal)

  • Firmware: 4.3.28

  • Mode: Router mode

  • WAN connected via Ethernet to ISP router (NOS fiber)

  • LAN connected to PC via Ethernet

  • WireGuard client connected to a pfSense server (remote VPS)

  • PersistentKeepalive = 25

  • MTU = 1280

  • Using UDP (tested both 51820 and 443)

Issue

The user experiences brief internet drops (from a few seconds up to ~2 minutes) during long sessions (gaming/poker + YouTube).

In the system log I consistently see:

  • ACTION=REKEY-TIMEOUT

  • Network device 'wgclient' link is down

  • Interface 'wgclient' is now down

  • udhcpc: sending renew to 192.168.1.1

  • lease obtained

This suggests that the WAN interface briefly loses connectivity, after which DHCP renews and WireGuard reconnects.

Important Observations

  • During the drop, the ISP router WiFi remains functional (mobile phone still has internet).

  • Other users with the same WireGuard server and same router model do NOT experience this issue.

  • This is the only user showing REKEY-TIMEOUT and interface down events.

  • WAN currently negotiates at 100baseT full-duplex (not 1000baseT).

  • LAN ports show 1000baseT full-duplex.

What Has Been Tested

  • Changed WireGuard port from 51820 to 443

  • Disabled Network Acceleration

  • Adjusted MTU

  • Adjusted PersistentKeepalive

  • Changed LAN ports on ISP router

  • Issue still occurs

Questions

  1. Can the GL-SFT1200 WAN port intermittently drop link without fully disconnecting?

  2. Could 100baseT negotiation instead of 1000baseT cause instability?

  3. Is there any known issue with WAN renegotiation or DHCP renew events on firmware 4.3.28?

  4. Are there advanced logs to detect physical link flapping on the WAN interface?

Any guidance would be appreciated.

I will attach the relevant system logs showing the exact timestamps of the drops.

Thank you.

752439ed-af5f-4af0-a9e9-c727f1a0a49f
752439ed-af5f-4af0-a9e9-c727f1a0a49f1288×1554 356 KB

2

any help please?

3

Hi

Sorry for the late reply—we’ve just returned from the Chinese New Year holiday.

Under normal circumstances, a DHCP renew should not affect network stability.

Based on the current logs, it appears that network fluctuations or interference with WireGuard may be causing the repeated disconnections.

Please try updating the SFT1200 to the latest 4.8.3 beta firmware and see if the issue persists.
If the problem continues, kindly export the full device logs and send them to us via private message so we can investigate further.

Download link:

Upgrade guide:

How to export logs:

image
image1430×911 87 KB

How to send private messages:

image
image632×233 19.1 KB

4

According to the logs, the issue is not related to DHCP renewals, but rather to the connection between the SFT1200 and the upstream router or ISP network.

Mon Mar  2 19:29:32 2026 user.info mwan3track[31213]: Lost 5 ping(s) on interface wan (eth0.2)
Mon Mar  2 19:29:48 2026 daemon.notice netifd: sf_eth_event port 1 updown 0 is_wan 0 vlanid 1 ifname eth0
Mon Mar  2 19:30:25 2026 kern.info kernel: [16309.634830] wireguard: wireguard-hotplug IFNAME=wgclient ACTION=KEYPAIR-CREATED
Mon Mar  2 19:30:40 2026 user.info mwan3track[31213]: Lost 4 ping(s) on interface wan (eth0.2)
Mon Mar  2 19:31:41 2026 kern.info kernel: [16385.002623] wireguard: wireguard-hotplug IFNAME=wgclient ACTION=REKEY-TIMEOUT

After mwan3 detects a WAN ping failure, a WireGuard rekey occurs afterward. This suggests the problem is more likely tied to the link between the SFT1200 and the upstream.

We recommend that you:

  1. Check the reliability of the Ethernet cable connecting the SFT1200 to the upstream router. Since you mentioned the negotiated speed is only 100 Mbps, we suspect the cable may be faulty or degraded. Try replacing it with a new one, such as the cable included with the SFT1200 or another known-good cable.
  2. When the issue occurs, verify whether the upstream router’s network is functioning normally. Based on your description, it seems you’ve already checked this, but it would be good to confirm again during the incident.