New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IPv6_rpfilter=yes breaks WireGuard VPN over IPv6 #1203
Comments
Hrm. The filter has not changed since #603. Can you share some details about your topology? Any chance of asymmetric routing? |
Pretty standard and uncomplicated, just my laptop connected over WiFi (dual-stacked), with a single WireGuard VPN-connection (dual-stacked WG server) that claims all IPv4/IPv6 traffic ( |
Here's the output from the routing tables and so on (anonymised by doing global search&replace of the IPv6 prefixes):
|
Here's the output from
The following is the diff from the above, when I disable
|
I'm on Fedora 39, and I'm positive I'm affected by this bug. Using Cloudflare's WARP service, it's impossible to establish connection so long as IPv6 is active on the primary interface. Disabling v6 forces v4 connection which goes through as expected. After finding this GitHub issue, I disabled Please let me know any information I can provide to debug this further. |
Can someone show |
What command exactly do you want the output of? I got output of the tables
|
Hrm. Nothing there. Are there nftables rules installed by wireguard? Check Is firewalld started before or after wireguard? |
I'm connecting to WireGaurd manually after logging into my DE. Also, do note that I'm using NetworkManager to initiate the connection. I'm not sure if OP used NM or the suite of EDIT More context: this output is with the
|
Just ran into this issue. You're close, @erig0, they're not iptables rules but rather a routing policy database rule. I hope I can provide some more useful information on this. Background: Wireguard interfaces can be set to apply a fwmark to the encrypted tunnel packets it sends. I guess this is so those packets can be identified in the routing database or iptables rules. The wg-quick script uses this feature when tunneling all traffic (when setting allowed ips to This is described more in the section "Improved Rule-based Routing" on https://www.wireguard.com/netns/ Here's the commands wg-quick executes to bring up my vpn:
Here's the ipv6 routing policy:
And the ipv6 routing table number 51820:
The main routing table is unchanged from the routes installed by other network management software. The effect of this is that outgoing packets will hit the routing policy rule 32765 and thus hit the alternate routing table with the single default route to the interface wg0. Wireguard will then generate an encrypted outgoing packet with the fwmark on it. That skips the routing policy rule 32765 and thus goes to the normal routing table and gets routed normally. I'm not sure I completely understand what the rpfilter does or why it interferes, but after I found this bug and turned it off, my tunnel started working over ipv6. Happy to help debug further. |
So on the return path, i.e. packets coming into the node running firewalld, there will not be a fwmark. Firewalld will do a rpfilter (fib lookup) on this packet (no fwmark present) and this yields I bet if you add an iptables or nftables rule that adds Can anyone test that? |
I can try, but you need to teach me how to add the |
With a wireguard tunnel set up, the command I haven't had a chance to try out the suggested test, since I'm no longer traveling and thus not using my vpn. I'll still try to test this if I can find the time though. |
Creating a new nftables table with this rule should do the trick. It'll apply the mark for both IPv4 and IPv6. Apply it with this:
|
Sorry for the extremely late response. I was not in a position to test things out, and come next month, it'll probably the same again. Anyhow, the I also don't know if it's related to the RP filter issue, but the WG connection sometimes temporarily stops working for a few minutes (never timed, but I'd hazard guess around 10 min or so), before simply working as expected. Stopping and reconnecting always fixes the issue, and sometimes suspending and resuming after a few minutes fixes it quickly than it automatically recovering. I mention this because this behavior I've never seen on Android or Windows with the same service and WG profile. During the WG downtime, I'm sure it's not network or Internet issue because I can still continue to access LAN resources (router web console, Android scrcpy, Windows Sunshine remote desktop, etc) without a hitch. |
What happened
When using a WireGuard VPN that tunnels all traffic towards an IPv6 VPN server, nothing works if firewalld is enabled with
IPv6_rpfilter=yes
. The WireGuard traffic from the VPN server is being dropped:This impacts both IPv4 and IPv6 traffic that is routed through the tunnel.
Setting
IPv6_rpfilter=no
and restartingfirewalld.service
makes things work.What you expected to happen
The VPN tunnel should have worked fine with
IPv6_rpfilter=yes
(or this setting should have been disabled by default).How to reproduce it (as minimally and precisely as possible)
AllowedIPs = ::/0
)I used NetworkManager for the first two steps, for what it is worth.
Anything else we need to know?
This appears to be a regression, see #603.
Firewalld Version
firewalld-1.3.1-1.fc38.noarch
Firewalld Backend
nftables
Linux distribution
Fedora Linux 38 (Workstation Edition)
Linux kernel version
6.4.12-200.fc38.x86_64
Other information
No response
The text was updated successfully, but these errors were encountered: