F42 Change Proposal: Firewalld IPv6_rpfilter default to loose on Workstations (self-contained)

Project Discussion Change Proposals
,
1

Firewalld IPv6_rpfilter default to loose on Workstations

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

Default firewalld to using IPv6_rpfilter=loose for new Workstation installs.

:link: Owner

:link: Detailed Description

Fedora Workstation variants use connectivity checks by default. These checks can fail for multi-homed hosts where firewalld uses IPv6_rpfilter=strict. As such, for these variants we should instead default to IPv6_rpfilter=loose to allow connectivity checks to function as intended.

Bug: 2324434 – IPv6_rpfilter=strict causes non-functional wired connectivity with NetworkManager

For IPv4 the rpfilter setting is already set to loose by default on all editions starting with Fedora 30. See: sysctl.d: switch net.ipv4.conf.all.rp_filter from 1 to 2 ¡ systemd/systemd@230450d ¡ GitHub

:link: Feedback

:link: Benefit to Fedora

The benefit is that connectivity checks will work properly on multi-homed, e.g. wifi + LAN, workstations. This helps avoid certain scenarios that can degrade user experience when switching between modes of connectivity.

:link: Scope

  • Proposal owners: The change is a small patch in the RPM spec file. The only affected file will be /etc/firewalld/firewalld.conf.

  • Other developers: N/A

  • Release engineering: N/A #Releng issue number

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy:

:link: Upgrade/compatibility impact

For systems upgrading to f42, the new value of IPv6_rpfilter depends on whether the user has customized /etc/firewalld/firewalld.conf. If no, then the RPM upgrade process will update the configuration to IPv6_rpfilter=loose. If yes, then the user configuration will be retained.

It’s important to note that this change is a deviation from firewalld upstream. Firewalld upstream will still default to IPv6_rpfilter=strict.

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? N

:link: How To Test

No special hardware is required. A default Workstation should be sufficient.

Testing requires multiple network interfaces with internet access. Connectivity checks must be enabled (default). Tester must verify that the connectivity checks pass for both links.

:link: User Experience

Connectivity checks work properly for multiple interfaces.

There is one specific scenario in which a non-functioning connectivity check can lead to a degraded user experience: A user with a laptop that is connected to their home WiFi connects said laptop to their home network using Ethernet, for example to transfer a larger file to a network drive. The user’s home network provides internet access using both IPv4 and IPv6 addressing. The user expects the Ethernet connection to take precedence over the already established WiFi connection. However, due to the IPv6_rpfilter=strict setting the IPv6 connectivity check fails and the Ethernet connection is deemed not connected to the internet. NetworkManager thus adds a penalty to the Ethernet interface’s routing metric resulting in traffic to the local network and the internet preferring the WiFi interface over the Ethernet interface. If the WiFi connection is slower than the Ethernet connection this will lead to a degraded performance when transferring that large file.

:link: Dependencies

No dependencies.

:link: Contingency Plan

  • Contingency mechanism: Keep existing default of IPv6_rpfilter=strict.
  • Contingency deadline: beta freeze
  • Blocks release? No

:link: Documentation

https://bugzilla.redhat.com/show_bug.cgi?id=2324434

:link: Release Notes

Connectivity checks now work properly for multi-homed Workstations.

Last edited by @amoloney 2024-12-03T17:38:15Z

Last edited by @amoloney 2024-12-03T17:38:15Z

1 Like
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

4

A few questions:

  • How are you determining if something is a ‘workstation’ or not? Or is
    this applying to everything, just the cause is a workstation one?

  • I don’t think the bug is really documentation. Thats supposed to be
    for docs folks to pull for release notes or the like… so a quick user
    focused summary there would be good, IMHO.

5

Tree - rpms/firewalld - src.fedoraproject.org

6

Great! Might add a link to that in the change? or discussion of how that check works?

7

I tried adding more context to the change proposal wiki page initially, but it got kinda long to be honest.
The user impact does require some preconditions be met, but I felt they are probably common enough to warrant this change.

So the tl;dr from a user’s perspective generally is:

If you:

  • are running Fedora Workstation
  • have a network that has both IPv4 and IPv6 routes to the internet
  • expect your Ethernet connection to have precedence over your wireless connection when you plug in your Ethernet while also connected to WiFi

This will now work as expected and there no longer is a difference in behaviour between networks that do and do not have IPv6 connectivity.

The reason this is a change proposal is because it objectively weakens security for the Workstation product. However, it also removes a UX and system configuration inconsistency between Dual Stack and non-Dual Stack networks.
For IPv4 it was decided (in systemd, see commit linked in proposal above) that the compromise in security can be made for an improved user experience. I personally tend to agree with this, given that attack scenarios are reasonably unlikely and users requiring hardened security would have needed to revert this setting for IPv4 already.
If the security argument becomes a factor in whether or not to approve this change request it would, in my eyes, automatically require a discussion around whether the systemd commit needs to be reverted in Fedora as well, effectively breaking the NetworkManager connectivity check on both IPv4-only and Dual Stack networks for multi-homed devices.

8

Will the connectivity check now work on networks where the border router has IPv6_rpfilter=strict set?

9

If I’m not mistaken, the rpfilter setting on the router shouldn’t affect the working of the connectivity check feature from the workstation’s perspective. If the connectivity check doesn’t succeed through that router it’s unlikely that actual connectivity would succeed (unless there are very specific rules in place that would make the connectivity check fail and regular traffic work).

10

This change proposal has now been submitted to FESCo with ticket #3324 for voting.

To find out more, please visit our Changes Policy documentation.