On Wed, Oct 14, 2020 at 3:20 PM Kristof Provost 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 Frankenstei
On 14 Oct 2020, at 21:16, J David wrote:
On Wed, Oct 14, 2020 at 1:59 PM Kristof Provost
wrote:
There’s good reason to do this, as we have to be able to match
state
on both the pre-translation side (when processing LAN -> WAN traffic)
and post-translation (WAN -> LAN).
So, basically, pf w
On Wed, Oct 14, 2020 at 1:59 PM Kristof Provost wrote:
> There’s good reason to do this, as we have to be able to match state
> on both the pre-translation side (when processing LAN -> WAN traffic)
> and post-translation (WAN -> LAN).
So, basically, pf would need separate states for each pre-redi
On 14 Oct 2020, at 18:52, J David wrote:
On 12 Oct 2020, at 23:48, Andreas Longwitz wrote:
pf gives this messages in debug mode (pfctl -x loud).
Yes, with that setting I'm also seeing those messages.
On Tue, Oct 13, 2020 at 5:35 PM Kristof Provost
wrote:
I see the same ‘stack key attach fai
On 12 Oct 2020, at 23:48, Andreas Longwitz wrote:
> pf gives this messages in debug mode (pfctl -x loud).
Yes, with that setting I'm also seeing those messages.
On Tue, Oct 13, 2020 at 5:35 PM Kristof Provost wrote:
> I see the same ‘stack key attach failed’ error message. My current
> thinking
