GL-MT3000 drops client connectivity when WireGuard is enabled on 4.8 r3 (IPv6 transport, IPv4 routing); works on 4.7.4 r6

Hello community and support team,

after upgrading my GL.iNet GL-MT3000 (Beryl AX) from firmware 4.7.4 release6 to 4.8 release3 via the web UI, enabling my existing WireGuard profile immediately breaks client connectivity on the router. Rolling back to 4.7.4 r6 restores normal operation.

Environment
• Device: GL-MT3000 (hardware rev unknown)
• Firmware: 4.7.4 r6 → 4.8 r3 (rollback to 4.7.4 r6 confirms resolution)
• Mode: Router
• Uplinks tested: Wi-Fi Repeater and USB tethering — issue occurs with each individually and in combination
• Clients: Wi-Fi only during tests (no wired clients)
• Home endpoint: AVM FRITZ!Box 6591 (WireGuard server, reachable over IPv6)
• Timezone: Europe/Berlin

WireGuard profile (sanitized)

ini

KopierenBearbeiten

[Interface]
PrivateKey = [masked]
Address = 192.168.201.1/24
DNS = 192.168.200.1
DNS = fritz.box

[Peer]
PublicKey = [masked]
PresharedKey = [masked]
AllowedIPs = 192.168.200.0/24, 0.0.0.0/0, ::/0
Endpoint = vpnendpoint-masked.net:51463
PersistentKeepalive = 25

Mode: Global / route all traffic • LAN-to-LAN routing: enabled
Transport to home: IPv6, while most traffic inside the tunnel is IPv4 (plus ::/0 allowed).

Issue Summary
On 4.7.4 r6, clients have Internet, local LAN access, and can reach home resources over WG.
On 4.8 r3, as soon as I enable the same WG profile, Wi-Fi clients briefly disconnect/reconnect and then have no connectivity (no Internet, no access to home, no local reachability).
Meanwhile, the FRITZ!Box shows the WG tunnel as established/healthy, and from my home network I can ping the GL-MT3000 and open its web UI via the tunnel. This suggests the tunnel itself is up but client forwarding/NAT/routing on the GL-MT3000 breaks once WG is active.

Reproduction

  1. Upgrade GL-MT3000 from 4.7.4 r6 to 4.8 r3 via web UI.
  2. Connect Internet via Wi-Fi Repeater (also reproduced via USB tethering).
  3. Connect a client to the GL-MT3000 Wi-Fi.
  4. Enable the WireGuard profile (global mode; AllowedIPs as above).
    Actual (4.8 r3): client Wi-Fi blips, then no connectivity.
    Expected (4.7.4 r6): normal Internet/local access and working WG to home.

What I’ve Tried
• Power-cycle and factory reset on 4.8 r3, then re-apply the WG profile → issue persists.
Policy mode instead of Global → same issue.
USB tethering and Wi-Fi Repeater as uplinks → same issue in all cases.
Rollback to 4.7.4 r6 → everything works again.

Regression Snapshot
• 4.7.4 r6 + WG (IPv6 transport, IPv4 routing, Global, LAN-to-LAN) → OK
• 4.8 r3 + same WG profile → Wi-Fi clients lose all connectivity upon activation

Suspected Area (for triage)
Possibly a firewall/fw4/nftables or routing/policy change in 4.8 affecting forwarding/NAT between LAN ↔ WG with IPv6 transport + IPv4 inside (0.0.0.0/0 and ::/0 AllowedIPs). Client traffic appears to be dropped/blackholed once WG is up, while the router itself remains reachable from the home side.

Hi,

I tested this in my router, and the configuration is very similar to yours (only server is AXT1800, but not FRITZ!Box).
After the WG client of MT3000 was enabled, there was no problem with the wireless client connection, have not reproduced, probably this issue is related to the VPN server or VPN profile.

MT3000 v4.8.0, r3


Repeater connects to WiFi for WAN

Clients are wireless, including the test PC:

WG client enabled:

The test PC, ping to WG server router LAN

Hi @bruce,

thanks for the quick reply. I think the key difference between our setups is IPv6 on the WAN/repeater side. In my case, the FRITZ!Box 6591 (WireGuard server) is publicly reachable only via IPv6, so my GL-MT3000 establishes the WG tunnel over IPv6. Inside that tunnel I primarily route IPv4 (AllowedIPs include 0.0.0.0/0 and ::/0).

On 4.7.4 r6 this works perfectly. On 4.8 r3, enabling the same WG profile brings the tunnel up (FRITZ!Box shows it as established and I can reach the router UI from the home side), but clients behind the GL-MT3000 lose all connectivity right after the tunnel comes up.

Given the VPN changes in 4.8, could you please investigate whether there’s a regression affecting IPv6 transport + IPv4 routing (forwarding/NAT/firewall rules between LAN and WG)?

Screenshot attached.

Thanks!

1 Like

Hi @bruce ,

is there any update on your side?

Hi,

Sorry, we did not reproduce this issue in our routers and environment, and test many times to not found exceptions.

X3000 VPN server, only IPv6 is public IP:




PC_A in X3000 LAN clients

bruce@bruce-rpi:~ $ ping 192.168.7.1 -c 2 # ping to BE9300 LAN IP.
PING 192.168.7.1 (192.168.7.1) 56(84) bytes of data.
64 bytes from 192.168.7.1: icmp_seq=1 ttl=63 time=100 ms
64 bytes from 192.168.7.1: icmp_seq=2 ttl=63 time=71.8 ms

--- 192.168.7.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 71.803/85.957/100.112/14.154 ms

bruce@bruce-rpi:~ $ ping 10.1.0.2 -c 2 # ping to BE9300 VPN Tunnel IP.
PING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.
64 bytes from 10.1.0.2: icmp_seq=1 ttl=63 time=133 ms
64 bytes from 10.1.0.2: icmp_seq=2 ttl=63 time=85.9 ms

--- 10.1.0.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 85.909/109.637/133.365/23.728 ms

bruce@bruce-rpi:~ $ ping 192.168.7.236 -c 2  # 192.168.7.236 is a BE9300 LAN client.
PING 192.168.7.236 (192.168.7.236) 56(84) bytes of data.
64 bytes from 192.168.7.236: icmp_seq=1 ttl=126 time=279 ms
64 bytes from 192.168.7.236: icmp_seq=2 ttl=126 time=76.4 ms

--- 192.168.7.236 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 76.389/177.704/279.019/101.315 ms

bruce@bruce-rpi:~ $ traceroute 192.168.7.236   # 192.168.7.236 is a BE9300 LAN client.
traceroute to 192.168.7.236 (192.168.7.236), 30 hops max, 60 byte packets
 1  192.168.8.1 (192.168.8.1)  0.557 ms  0.487 ms  0.472 ms
 2  10.1.0.2 (10.1.0.2)  82.033 ms *  171.530 ms
 3  * 192.168.7.236 (192.168.7.236)  171.458 ms *

BE9300 VPN client, and connect to the X3000 server:


(Connect to X3000 server via IPv6)

PC_B in BE9300 LAN clients

C:\Users\itwuh>ping 192.168.8.1  # ping to X3000 LAN IP

Pinging 192.168.8.1 with 32 bytes of data:
Reply from 192.168.8.1: bytes=32 time=110ms TTL=63
Reply from 192.168.8.1: bytes=32 time=106ms TTL=63
Reply from 192.168.8.1: bytes=32 time=169ms TTL=63
Reply from 192.168.8.1: bytes=32 time=134ms TTL=63

Ping statistics for 192.168.8.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 106ms, Maximum = 169ms, Average = 129ms

C:\Users\itwuh>ping 192.168.8.101  #192.168.8.101 is a X3000 LAN client.

Pinging 192.168.8.101 with 32 bytes of data:
Reply from 192.168.8.101: bytes=32 time=121ms TTL=62
Reply from 192.168.8.101: bytes=32 time=104ms TTL=62
Reply from 192.168.8.101: bytes=32 time=333ms TTL=62
Reply from 192.168.8.101: bytes=32 time=118ms TTL=62

Ping statistics for 192.168.8.101:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 104ms, Maximum = 333ms, Average = 169ms

C:\Users\itwuh>ping 10.1.0.1  # ping to X3000 VPN tunnel IP

Pinging 10.1.0.1 with 32 bytes of data:
Reply from 10.1.0.1: bytes=32 time=140ms TTL=63
Reply from 10.1.0.1: bytes=32 time=198ms TTL=63
Reply from 10.1.0.1: bytes=32 time=106ms TTL=63
Reply from 10.1.0.1: bytes=32 time=141ms TTL=63

Ping statistics for 10.1.0.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 106ms, Maximum = 198ms, Average = 146ms

C:\Users\itwuh>tracert 192.168.8.101  #192.168.8.101 is a X3000 LAN client.

Tracing route to 192.168.8.101 over a maximum of 30 hops

  1     1 ms     1 ms     1 ms  console.gl-inet.com [192.168.7.1]
  2   365 ms    93 ms    89 ms  10.1.0.1
  3   157 ms    91 ms    77 ms  192.168.8.101

Trace complete.

Please check again, if no luck, please share your MT3000 with us via GoodCloud and we will try to check the issue remotely.

Please PM me your router MAC address and Admin Panel login password