Hello, Okay. Let’s give it a try. I will refer anyone running into problems to you :) -Michael > On 18 Jan 2022, at 21:18, Peter Müller wrote: > > Hello Michael, > > thanks for your reply. > > Well, besides amending the patch for Core Update 164 (or beyond), mention it in the changelog, > and encourage people running special setups to test this update, I have no idea. > > Since the vast majority of IPFire installations will have a default route set, Loose Reverse > Path Filtering cannot break anything for them. Therefore, I am willing to risk the procedure > mentioned above. > > Thanks, and best regards, > Peter Müller > > >> Hello, >> >> How are we going to test this with a wider audience? >> >> I do not expect this to break anything, but I would like to make sure that this assumption holds true. >> >> -Michael >> >>> On 16 Jan 2022, at 14:47, Peter Müller wrote: >>> >>> For historical reasons, we were always reluctant to reverse path >>> filtering, since configuration changes were tricky to evaluate for a >>> larger userbase, IPFire permits a number of complex scenarios, and due >>> to limited resources. >>> >>> As a compromise, this patch suggests to enable Loose Reverse Path >>> Filtering, as specified in RFC 3704 (section 2.4), to gain at least some >>> security achievement on this end. >>> >>> To quote from that: >>> >>> Loose Reverse Path Forwarding (Loose RPF) is algorithmically similar >>> to strict RPF, but differs in that it checks only for the existence >>> of a route (even a default route, if applicable), not where the route >>> points to. Practically, this could be considered as a "route >>> presence check" ("loose RPF is a misnomer in a sense because there is >>> no "reverse path" check in the first place). >>> >>> The questionable benefit of Loose RPF is found in asymmetric routing >>> situations: a packet is dropped if there is no route at all, such as >>> to "Martian addresses" or addresses that are not currently routed, >>> but is not dropped if a route exists. >>> >>> There is no legitimate reason why we cannot enable this: If IPFire >>> receives a packet on some interface it cannot route on _any_ interface >>> at all, there is no sense in processing it. >>> >>> While testing this change, I was unable to produce a situation where it >>> actually causes any harm. In theory, it shouldn't do so anyways. >>> >>> In the future, we will hopefully be able to set these sysctl's to "1", >>> using Strict Reverse Path Filtering, as specified in RFC 3704 (section >>> 2.2). Doing so was found to work fine in my testing environment as well, >>> but there is no asymmetric routing in place there. >>> >>> Signed-off-by: Peter Müller >>> --- >>> config/etc/sysctl.conf | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/config/etc/sysctl.conf b/config/etc/sysctl.conf >>> index bc2d21c93..c8c775d13 100644 >>> --- a/config/etc/sysctl.conf >>> +++ b/config/etc/sysctl.conf >>> @@ -12,13 +12,13 @@ net.ipv4.tcp_syn_retries = 3 >>> net.ipv4.tcp_synack_retries = 3 >>> >>> net.ipv4.conf.default.arp_filter = 1 >>> -net.ipv4.conf.default.rp_filter = 0 >>> +net.ipv4.conf.default.rp_filter = 2 >>> net.ipv4.conf.default.accept_redirects = 0 >>> net.ipv4.conf.default.accept_source_route = 0 >>> net.ipv4.conf.default.log_martians = 1 >>> >>> net.ipv4.conf.all.arp_filter = 1 >>> -net.ipv4.conf.all.rp_filter = 0 >>> +net.ipv4.conf.all.rp_filter = 2 >>> net.ipv4.conf.all.accept_redirects = 0 >>> net.ipv4.conf.all.accept_source_route = 0 >>> net.ipv4.conf.all.log_martians = 1 >>> -- >>> 2.31.1 >>