Hello Michael, please do. It would be interesting to see setups where this breaks anything... Thanks, and best regards, Peter Müller > 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 >>> >