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