Description of problem: WireGuard VPN established by NetworkManager doesn't work, if endpoint host is connected via IPv6 and firewalld is turned on. Same configuration works without any problem on the same system with wg-quick (and firewalld on/up/unchanged). Version-Release number of selected component (if applicable): Fedora 38 Workstation How reproducible: Steps to Reproduce: 1. Import a WireGuard configuration with NetworkManager (GUI or nmcli), where endpoint is reachable via IPv6 2. Bring up the WireGuard connection 3. Try to open a website (e.g. ipx.ac) or ping a host Actual results: No connection. Expected results: Traffic is tunnelled through VPN and website is loading, ping is answering Additional info: If you disable firewalld ( systemctl stop firewalld.service), immediately the connections works. But the exact same configuration works with wg-quick, without the need to disable firewalld I didn't changed firewalld configuration. It is a default Fedora Worksation setup. I just imported the WireGuard config.
I had the same problem, and I think I found the solution: The default route in table 51820 has, created by NetworkManager, a lower metric as the normal default route. With wg-quick this is opposite. If a packet comes in from an address without special route, firewalld's reverse path filter will, not knowing about marks, determine that the packet has go out via the wireguard interface. Firewalld's reverse path filter will drop the incoming packet. (firewall-cmd --set-log-denied=all shows it) So NetworkManager should create the default route in routing table 51820 with a metric higher than the standard default route. Could you check this by creating a standard default route with metric <50? Of course, the 51820 is the default and could be different in your setup.
Sorry, please neglect the conclusion in my previous mail. The problem is indeed reverse path, but the solution is different: wg-quick puts a mark on the incoming connections. This is missing in NetworkManager. table ip6 wg-quick-wg1a { chain preraw { type filter hook prerouting priority raw; policy accept; iifname != "wg1a" ip6 daddr fc00:a450:578a:101::3 fib saddr type != local drop } chain premangle { type filter hook prerouting priority mangle; policy accept; meta l4proto udp meta mark set ct mark } chain postmangle { type filter hook postrouting priority mangle; policy accept; meta l4proto udp meta mark 0x0000ca6c ct mark set meta mark } } Starting wireguard from NetworkManager and loading this wg-quick created nft table gives a working connection.
Hi, thank you that you took a look into the problem and found a solution. Can I test this or help out somehow else? Please let me know. I would love to test or help. Best Keywan
For a specific connection, you can extract this nftables fragment created by "wg-quick up wg1a" with "nft list table ip6 wg-quick-wg1a >/somedir/wg1anft". After NetworkManager brings up its connection with the same interface name, you can add this snippet with nft -f /somedir/wg1anft, for example in /etc/NetworkManager/dispatcher.d. In order to do it correctly, the interface address and fwmark have to be evaluated by script, a bit programming I did not do yet.
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
Yes, this problem still exists for Fedora 39 and Fedora 40. There is no movement neither a question, so this bug won't magically disappear ;) I'm ready to help with logs, tests etc., but lacking programming and networking skill unfortunately I can't propose a solution myself. Maybe the nice comments of H.Janssen and the solution could be helpful. I can test it with rawhide as well. Does it help, if I write the maintainer of NM or firewalld directly (or whom it may concern)?
I just encountered this issue for a dual-stack remote, affecting both IPv4 and IPv6. Reducing the case to v4 only with a static v4 address instead of an FQDN did not resolve the issue. However, after further investigation, I also arrived at the conclusion that this is related to no fwmarks being added by NetworkManager. Furthermore, researching this behavior, I encountered several users' posts across different communities suffering from the same issue. However, there, no-one had found this bug ticket or reached the same conclusion regarding the fwmark. I would hence suggest that this is, indeed, an issue, especially not one only affecting IPv6; As such it might also make sense to adjust the title of the issue. I resolved this for me now by setting up a script similar to the suggestion in Comment #4; Shared here for reference. Please note that this contains (commented) debug code and the nft rules contain documentation prefix addresses. The major drawback of this solution is that it is static, while NM explicitly tries to be able to handle changes in the wg endpoint address while the link is up, see: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1157 However, technically, it should be possible to actually write a generic version of this script by listening for the right events and resolving some potentially unknown variables. /etc/wireguard/nft-wg0-wg0-up: --- table ip6 wg-quick-wg0 { chain preraw { type filter hook prerouting priority raw; policy accept; iifname != "wg0" ip6 daddr 2001:db8::2 fib saddr type != local drop } chain premangle { type filter hook prerouting priority mangle; policy accept; meta l4proto udp meta mark set ct mark } chain postmangle { type filter hook postrouting priority mangle; policy accept; meta l4proto udp meta mark 0x0000ca6c ct mark set meta mark } } table ip wg-quick-wg0 { chain preraw { type filter hook prerouting priority raw; policy accept; iifname != "wg0" ip daddr 192.0.2.2 fib saddr type != local drop } chain premangle { type filter hook prerouting priority mangle; policy accept; meta l4proto udp meta mark set ct mark } chain postmangle { type filter hook postrouting priority mangle; policy accept; meta l4proto udp meta mark 0x0000ca6c ct mark set meta mark } } --- And correspondingly in /etc/NetworkManager/dispatcher.d/00-wg-set-nft: --- #!/bin/bash set -u set -e #date --iso-8601=s >> /tmp/up_event #printenv >> /tmp/up_event if [ "$NM_DISPATCHER_ACTION" == "up" ] || [ "$NM_DISPATCHER_ACTION" == "down" ]; then # echo "Found interface '$NM_DISPATCHER_ACTION' for $DEVICE_IFACE connection $CONNECTION_ID" >> /tmp/up_event; if [ -f "/etc/wireguard/nft-$CONNECTION_ID-$DEVICE_IFACE-up" ]; then # echo "NFT ruleset for $CONNECTION_ID ($DEVICE_IFACE) present at /etc/wireguard/nft-$CONNECTION_ID-$DEVICE_IFACE-up!" >> /tmp/up_event; if [ "$NM_DISPATCHER_ACTION" == "up" ]; then # echo "Setting FW rules for $CONNECTION_ID" >> /tmp/up_event; nft -f "/etc/wireguard/nft-$CONNECTION_ID-$DEVICE_IFACE-up"; # nft list ruleset >> /tmp/up_event; else # echo "Deleting FW rules for $CONNECTION_ID" >> /tmp/up_event; nft delete table ip wg-quick-"$DEVICE_IFACE"; nft delete table ip6 wg-quick-"$DEVICE_IFACE"; # nft list ruleset >> /tmp/up_event; fi; # else # echo "NFT ruleset for $CONNECTION_ID ($DEVICE_IFACE) not found at /etc/wireguard/nft-$CONNECTION_ID-$DEVICE_IFACE-up!" >> /tmp/up_event; fi; fi; --- Also, I was not sure where to file this bug; Technically, wireguard-tools is in EPEL; However, the issue is in NetworkManager from base; Then again, I personally encountered this on a third-party-built distribution; Filing at freedesktop.org is somewhat besides the point, given that this issue seems to be specific to NetworkManager under RHEL derivates, given the specific use of firewalld. As this bug already exists in the RH bugtracker, and this is likely the maintainer base of the root distribution, I figured it might make most sense to just add this context here. For further context on third party posts that seemingly document an encounter with the same bug, please see a brief blog post in which I tracked my debug journey with this issue: https://doing-stupid-things.as59645.net/wireguard/networkmanager/gnah/2025/02/02/i-heard-you-like-abstraction.html
This message is a reminder that Fedora Linux 40 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '40'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 40 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
First: According to https://github.com/firewalld/firewalld/issues/603, work has been done upstream to fix the problem. Second: The default value of IPv6_rpfilter in Fedora 42 is "loose" now, which removes the problem. I could not reproduce the problem anymore, even with IP6_rpfilter on strict, so it looks like the problem is gone in Fedora 42 and this issue can be closed.
Correction: the problem is partly still present in Fedora42. The firewalld configuration "IPv6_rpfilter=loose", which is now default on Workstation circumvents the problem. But the "IPv6_rpfilter=strict" still shows the rp_filter block in the logs. So maybe https://github.com/firewalld/firewalld/issues/603 fixed the problem for wg-quick by incorporating a mark in the v6 rpfilter code, but it does not fix the problem with NetworkManager because this changes nothing at all in the firewall.
Fedora Linux 40 entered end-of-life (EOL) status on 2025-05-13. Fedora Linux 40 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
As noted in comment 10, this still affects 42. I would say that that does not really warrant closing then, no?
FEDORA-2025-3319f398e3 (NetworkManager-1.52.1-1.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-3319f398e3
FEDORA-2025-3319f398e3 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-3319f398e3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-3319f398e3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-3319f398e3 (NetworkManager-1.52.1-1.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.