IPv6 reverse path filtering can break NetworkManager's connectivity check on IPv6-enabled networks. A manifestation of this issue is a laptop connected to both WiFi and Ethernet where the OS will still prefer the WiFi connection if the Ethernet connection is made after the WiFi connection was already established. Root cause is that the NetworkManager connectivity check fails for an IPv6 destination if firewalld is configured with IPv6_rpfilter=strict. A suggested fix could be to configure IPv6_rpfilter=loose for at least the Fedora Workstation edition, as this edition is predominantly used in scenarios where this issue can regularly manifest. NetworkManager-config-connectivity-fedora is installed by default on Fedora Workstation. Reproducible: Always Steps to Reproduce: Prerequisites: a. Given a device that has two network interfaces that are connected to the same network (e.g. a laptop with a wireless interface and a wired Ethernet interface) b. Given a network that provides IPv6 addressing that can be used to reach the site configured for the NetworkManager connectivity check (for Fedora this is fedoraproject.org) Steps: 1. User plugs in an Ethernet cable on a laptop that is already connected via WiFi. 2. User expects the Ethernet connection to start taking precedence (i.e. lower routing metric) over the WiFi connection (this is the default for NetworkManager, unless specifically configured otherwise) 3. NetworkManager penalizes the default route over the Ethernet interface due to the connectivity check failing via IPv6 as a cause of reverse path filtering. Connections are now stuck going via the WiFi interface, which may be slower and less preferable. Actual Results: Connectivity is stuck going over the WiFi link instead of the faster Ethernet link. Expected Results: Connectivity occurs via the Ethernet link rather than the WiFi link. Relevant NetworkManager bug report: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/116
Alternatively, why is NM doing connectivity checks for non-default routes?
I think bug 1740551 can provide an explanation to that.
If FedoraWorkstation enables connectivity checking by default, then I don't see any option other than IPv6_rpfilter=loose. This is a significant change though. Normally something like that would have to go through the Change process [1]. [1]: https://docs.fedoraproject.org/en-US/program_management/changes_policy/
I agree that this is a significant change (as it changes a security-relevant default) and, if considered, warrants a change proposal. While technically lowering security posture for some edge cases in the Workstation scenario, "loose" is already the default for IPv4 reverse path filtering on any edition of Fedora: https://github.com/systemd/systemd/commit/230450d4e4f1f5fc9fa4295ed9185eea5b6ea16e
Some other commits relevant to this change that can provide more context: https://github.com/NetworkManager/NetworkManager/commit/b1082aa9a711deb96652e5b2fcaefcf399d127b8 drops rp_filter handling from NM. https://github.com/NetworkManager/NetworkManager/commit/983b430075f1da5ca47ee7bdc5863eb0218a9bd1 prints a warning if rp_filter may interfere with connectivity checking.
> Alternatively, why is NM doing connectivity checks for non-default routes? In this case both the Ethernet and the Wifi interfaces have the default route. The connectivity check must be done on both interfaces so that NM can add a metric penalty to interfaces where the check fails. Eric, how can NM retrieve the current IPv6 rp_filter value? I think NM should at least log a warning like for IPv4 when the value is strict and connectivity check is enabled.
> Eric, how can NM retrieve the current IPv6 rp_filter value? I think NM should at least log a warning like for IPv4 when the value is strict and connectivity check is enabled. It can be checked over dbus. Newer firewalld versions support IPv6_rpfilter2, which may be set to "loose". Old versions only support IPv6_rpfilter which may only be "yes" or "no". -- # dbus-send --system --print-reply --dest=org.fedoraproject.FirewallD1 /org/fedoraproject/FirewallD1/config org.freede sktop.DBus.Properties.Get string:"org.fedoraproject.FirewallD1.config" "string:IPv6_rpfilter2" method return time=1731094518.131045 sender=:1.3 -> destination=:1.127 serial=356 reply_serial=2 variant string "strict"
So do we agree that we need a Change to set IPv6_rpfilter=loose for Workstation variants?
(In reply to Eric Garver from comment #8) > So do we agree that we need a Change to set IPv6_rpfilter=loose for Workstation variants? +1, it should be the same as IPv4
(In reply to Beniamino Galvani from comment #9) > (In reply to Eric Garver from comment #8) > > So do we agree that we need a Change to set IPv6_rpfilter=loose for Workstation variants? > > +1, it should be the same as IPv4 I want to highlight that this will be a Fedora only change. Firewalld upstream will still default to "strict".
Change Proposal: https://fedoraproject.org/wiki/Changes/Firewalld_IPv6_rpfilter_Default_Loose
Thanks for putting this together. I took the liberty and added some more details around the specific use case and potential user experience impact so the Release Notes writers can decide how they want to word it. If that's not OK feel free to roll back my changes on the wiki.
This change is not appropriate for a stable release. As discussed above, it requires a Change and thus will be done in F42. f42 Change tracker: https://bugzilla.redhat.com/show_bug.cgi?id=2337587