During my vacation, I used my roadwarrior Wireguard VPN (Android smartphone -> Opnsense) again after a long period of inactivity. I noticed that IPv6 network traffic wasn't being routed to the internet via the tunnel. IPv4 network traffic, however, worked without any issues. I hadn't changed the configuration in ages. There were only a few Opnsense updates.
I'm currently using Opnsense version 25.7. I tried to reproduce the problem with older Opnsense and older kernel versions. The problem with IPv6 network traffic also exists in the oldest ZFS snapshot (v. 25.1.9_2). So the error must have crept in with an earlier Opnsense update, since I hadn't changed the configuration, and IPv6 in the tunnel had definitely worked in the past.
Further analysis gave the following results:
- A packet capture of the Wireguard virtual interface showed that the IPv6 network traffic from the smartphone arrived correctly at the Wireguard virtual interface, meaning it passed through the tunnel correctly.
- However, the firewall logs did not indicate that IPv6 packets were arriving. Therefore, the problem appeared to be that the IPv6 packets were not reaching the firewall.
Further analysis on the console provided more insight:
wg2: flags=10080c1<UP,RUNNING,NOARP,MULTICAST,LOWER_UP> metric 0 mtu 1420
description: My_wireguard_interface (opt15)
options=80000<LINKSTATE>
groups: wg wireguard
nd6 options=9<PERFORMNUD,IFDISABLED>
According to "ifconfig", IPv6 was disabled on the Wireguard interface. Consequently, the packets were filtered on the interface before being forwarded to the firewall. Manually removing the "IFDISABLED" flag in the "nd6 options" or manually assigning an IPv6 address to the interface (which automatically removes the flag) re-enables IPv6, and the network traffic is correctly routed to the internet again via the Wireguard tunnel.
This appears to be a bug in Opnsense, causing the interface to be incorrectly configured. If Wireguard is configured with IPv6, the flag must not be set. Accordingly, Opnsense must remove the flag from the interface if at least one of the following conditions is met:
- In the Wireguard instance configuration, the "Tunnel address" field contains at least one IPv6 address.
- The "Allowed IPs" field of at least one associated peer contains at least one IPv6 address.
In case only condition 2 meets (like in my case), the flag is set and IPv6 traffic is filtered. In my eyes this needs to be corrected in future updates.
you might check your configuration as my road warrior wireguard does work with ipv6. many of my local servers are ipv6 only and until recently I ran it as ipv6 only.
my ifconfig for wg does show ip addresses for ipv6 and ipv4 that are assigned by the wireguard instance that dont seem to be in yours.
wg0: flags=10080c1<UP,RUNNING,NOARP,MULTICAST,LOWER_UP> metric 0 mtu 1420
description: WG (opt1)
options=80000<LINKSTATE>
inet 10.XX.XX.1 netmask 0xffffff00
inet6 2603:xxxx:zzzz:yyyy::1 prefixlen 64
groups: wg wireguard
nd6 options=1<PERFORMNUD>
those are the addresses I assigned as the tunnel address so it seems odd that you don't have any.
Im experiencing same problem. Routing IPV6 via Wireguard is not working. To connect to WG is ok and can ping both sides. But to access networks behind those WG peers i doesnt work.
No config change from 25.1.x
During packet capture packets are visible, but even "live logging" in GUI doesnt show them.
Only iPV6 problem, IPV4 is ok including routing
I confirm the source of the problem:
If the WireGuard tunnel has an IPv6 address set (i.e., in the "Tunnel Address" field), the interface is correctly initialized:
- An IPv6 address is assigned.
- The IFDISABLED flag is not set.
- Result: IPv6 communication (e.g., roadwarrior setups) works as expected.
However, if the tunnel itself is IPv4-only, and only the peer's AllowedIPs contain IPv6 networks (e.g., fd00::/64), the interface:
- Does not get an IPv6 address.
- Has the IFDISABLED flag set.
- Result: Incoming IPv6 traffic (which arrives correctly via the tunnel) is silently dropped at the interface level.
This breaks site-to-site or multi-peer IPv6 routing where the tunnel itself doesn't need an IPv6 address but is expected to forward IPv6 to/from peers.
Workaround:Assigning a dummy ULA IPv6 address to the tunnel interface (e.g., fd00:1234::1/128) clears the IFDISABLED flag and restores IPv6 routing functionality.
While this workaround is effective, it is not ideal, as it requires manual and potentially error-prone configuration outside the intended scope of the peer-level AllowedIPs.
Expected Behavior:If any IPv6 network is present in the AllowedIPs of a peer, OPNsense should:
Automatically enable IPv6 on the WireGuard interface.
Either assign a link-local or dummy address, or at minimum, clear the IFDISABLED flag.
I dont know what is best practice and if it is really bug or feature.
Searching internet there are recommendations: "You typically assign ULA or GUA addresses to each end of the WireGuard tunnel Example: fd00:1::1/64 on the server, fd00:1::2/64 on client. You then route specific IPv6 networks over the tunnel via AllowedIPs."
I will probably go that way, because it is clearly more readable for admin and system, that interface is ipv6 capable.
In my eyes it's a bug since wireguard does not need a tunnel endpoint address. My wireguard configuration does not have any configured tunnel endpoint. In the past this worked flawlessly.
Right - https://github.com/opnsense/core/issues/9021
You can add net.inet6.ip6.accept_rtadv=1 tunable back that was removed in 25.1.7, but it's a security risk moving IPv6 traffic across any interface on the system because that enables all the IPv6 connectivity by default.
If you want to consider it a bug you can, but this was never the fix.
Cheers,
Franco