IPv6 over VPN works on the router but not for LAN clients (NAT6 / VPN Policy Routing issue)

MrFOX · November 3, 2026, 7:32am

Hello GL.iNet team!

I've encountered an issue with IPv6 routing through a VPN tunnel on a GL.iNet Brume MT5000.

Network configuration:

Router: GL.iNet Brume MT5000
VPN: AmneziaWG (WireGuard-compatible)
VPN interface: wgclient4
IPv6 mode: NAT6
Local IPv6 prefix: fde7:fdeb:fd0b::/56
VPN routing table: 1004
VPN routing mark: 0x4000
Upstream ISP: IPv4 only (no native IPv6)

Problem:

IPv6 connectivity works correctly on the router itself through the VPN tunnel. For example:

ping -6 2606:4700:4700::1111

However, devices connected to the router's LAN cannot access the IPv6 internet, even though they receive IPv6 addresses and an IPv6 default gateway.

The router already has IPv6 forwarding enabled and NAT66 (MASQUERADE) configured for wgclient4.

After investigating the routing rules, I found that IPv6 traffic arriving from br-lan is not being marked correctly for VPN routing.

The router has policy routing rules that can blackhole unmarked LAN traffic.

Temporary workaround:

The problem is resolved immediately by manually adding this ip6tables rule:

ip6tables -t mangle -I ROUTE_POLICY 1 \
  -i br-lan \
  -s fde7:fdeb:fd0b::/56 \
  -d 2000::/3 \
  -j MARK --set-xmark 0x4000/0xf000

After applying this rule, LAN clients can successfully access IPv6 websites and ping external IPv6 addresses through the VPN tunnel.

The problem is that this workaround is not persistent. The rule disappears after a router reboot or VPN restart/reconnection, and IPv6 connectivity for LAN clients stops working again.

Expected behavior:

When IPv6 NAT6 mode is enabled and a VPN client is configured to route IPv6 traffic, the router should automatically apply the correct IPv6 policy routing marks to forwarded LAN traffic.

This should work without requiring manually added ip6tables rules.

Questions for GL.iNet developers:

Is this a known issue with IPv6 NAT6 and VPN Policy Routing?
Why is forwarded IPv6 traffic from br-lan not automatically marked for the active VPN tunnel?
Could this behavior be fixed in a future firmware update?
Is there an officially supported way to make this routing rule persistent across VPN reconnections?

Thank you!

will.qiu · November 5, 2026, 7:57am

Hi, thanks for the detailed report.

We tested IPv6 connectivity from a LAN client on an MT5000 running firmware v4.9.0 with IPv6 in NAT6 mode. In our test, the client could reach an IPv6 address through the WireGuard VPN.

VPN Dashboard:

IPv6 mode:

IPv6 Test:

For reference, these are the relevant rules on our test device, where the VPN interface is wgclient1:

# ip6tables -t mangle
-A PREROUTING -j VPN_PREROUTING_HOOK
-A VPN_PREROUTING_HOOK -i br-lan -j ROUTE_POLICY
-A ROUTE_POLICY -m connmark ! --mark 0x0/0xf000 -j CONNMARK --restore-mark --nfmask 0xf000 --ctmask 0xf000
-A ROUTE_POLICY -m addrtype ! --dst-type LOCAL -j TUNNEL2240_ROUTE_POLICY
-A TUNNEL2240_ROUTE_POLICY -m mark --mark 0x0/0xf000 -j MARK --set-xmark 0x1000/0xf000

# ip -6 rule
6000: from all fwmark 0x1000/0xf000 lookup 1001

# ip -6 route show table 1001
default dev wgclient1 proto static metric 1024

# ip6tables -t nat
-A POSTROUTING -o wgclient1 -j zone_wgclient1_postrouting
-A zone_wgclient1_postrouting -j MASQUERADE

In this configuration, LAN traffic passes through ROUTE_POLICY, where an existing connection mark can be restored. Unmarked traffic matching the VPN policy receives 0x1000/0xf000, selecting routing table 1001; traffic leaving through wgclient1 is then masqueraded. The actual chains, marks, and routing table depend on the VPN and policy configuration, so your wgclient4 may use different values.

Could you share screenshots of the following pages?

Admin Panel → Network → IPv6
VPN → VPN Dashboard, including any policies configured for wgclient4

Please also let us know your full firmware version, and redact any private keys or other sensitive information from the screenshots.