[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-pf
Subject:    Re: Packets passed by pf don't make it out?
From:       "Kristof Provost" <kp () FreeBSD ! org>
Date:       2020-10-15 8:51:37
Message-ID: A541B35C-D5A3-4910-B7D0-1AFF3A778495 () FreeBSD ! org
[Download RAW message or body]

On 14 Oct 2020, at 21:35, J David wrote:
> On Wed, Oct 14, 2020 at 3:20 PM Kristof Provost <kp@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
_______________________________________________
freebsd-pf@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"

[prev in list] [next in list] [prev in thread] [next in thread]