apologies for my late reply.
If you don’t mind, I would defer to RFC 3704, sections 3 and 4, for the answer. The rationale and consequences of reverse path filtering are well described in there, I find, and probably provide you with a more holistic view on the situation.
One solution would be to leave RPF enabled in “strict” mode on all interfaces, and only set it to “loose” on interfaces requiring that. More on this idea below.
To be honest, I would like to know that myself. One reason why we abstained from RPF for so long is that it happens before any packet filtering layers, which means that there are no logs of dropped packets available. Implementing RPF on the packet filter level was considered, but dismissed quickly, as the variety of scenarios, particularly when it comes to VPN usage, was too complicated to cover (and test).
You can configure RPF on a per-interface basis through
sysctl's such as:
This allows you to disable RPF on internal interfaces (or at least set it to “loose”, though the effect of that setting is minimal), while leaving it in “strict” mode on RED, to prevent external spoofing attempts of internal networks. That would probably be the best compromise in your case.
Do both IPFire machines have the same routing table as well? In this case, strict RPF should not cause any issues.
I am with you, and would not assume strict RPF disrupting anything either.
Thanks, and best regards,