Bug 2324434
Summary: | IPv6_rpfilter=strict causes non-functional wired connectivity with NetworkManager | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Felix Kaechele <felix> |
Component: | firewalld | Assignee: | Eric Garver <egarver> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 41 | CC: | bgalvani, egarver, psutter, rh, thaller |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2025-01-15 16:13:03 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Felix Kaechele
2024-11-07 17:57:44 UTC
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". 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 |