Packets passed by pf don't make it out?

Kristof Provost kp at FreeBSD.org
Thu Oct 15 08:51:42 UTC 2020


On 14 Oct 2020, at 21:35, J David wrote:
> On Wed, Oct 14, 2020 at 3:20 PM Kristof Provost <kp at freebsd.org> 
> wrote:
>> I’ve not dug very deep yet, but I wonder if we shouldn’t have to
>> teach pf to change the source port to avoid conflicting states in the
>> first place.
>
> That was my first thought as well, framed mentally as some sort of
> port-only Frankenstein's binat because my level of understanding is
> clearly more cartoonish than yours. ;-)
>
> My second thought was to wonder if my approach is architecturally
> wrong.  Would it make sense for the many-to-many case to use route-to
> instead of rdr, leave the packet unmodified, and expect every machine
> in the server pool to catch all the public IPs?
>
> That might still be tricky.  Using rdr would presumably hit the same
> problem.  Maybe something gross like ifconfig'ing the public pool
> addresses as /32's on lo0, then binding on those, maybe?
>
I honestly don’t know. The pf NAT/RDR/… code is complex, and I 
certainly don’t understand all edge cases.
It may be worth experimenting with such options though, because this is 
unlikely to be fixed short-term.

Best regards,
Kristof


More information about the freebsd-pf mailing list