<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - systemd-networkd: net.ipv4.conf.default.forwarding is ignored in 219" href="https://bugs.freedesktop.org/show_bug.cgi?id=89509#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - systemd-networkd: net.ipv4.conf.default.forwarding is ignored in 219" href="https://bugs.freedesktop.org/show_bug.cgi?id=89509">bug 89509</a> from <a class="email" href="mailto:mike@marineau.org" title="mike@marineau.org <mike@marineau.org>"> mike@marineau.org</a> <pre>(In reply to Lennart Poettering from <a href="show_bug.cgi?id=89509#c1">comment #1</a>) > Yeah this was an underdocumented change in 219: we manage the IP forwarding > setting per interfac now. You have to set IPForward=yes in the .network > files explicitly now, otherwise you will not get IP forwarding on that > interface. Intentional or not from your perspective, from our perspective it is a regression because networkd is now overriding sysctl which up until 219 was the only mechanism for providing those settings. Although distros can update any .network files we ship to update this appropriately there isn't a practical way migrate user provided configs to the new semantics safely. The interaction between net.ipv4.conf.all.* net.ipv4.conf.default.* and net.ipv4.conf.<if>.* can depend on the timing of systemd-sysctl.service, any scripts or other services that may alter those settings, and the discovery of network devices by the kernel. We could probably some up with some script to make an educated guess and run that before the new networkd starts but it is going to be prone to error. Without a safe migration path we simply cannot ship a networkd with this behavior without breaking some subset of our user's systems. I'm open to other ideas but the best scheme I can think of is to turn `IPForwarding` into a trinary value where the default "unset" or "kernel" or whatnot value leaves the setting untouched.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>