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 <k...@freebsd.org> wrote: > I see the same ‘stack key attach failed’ error message. My current > thinking is that we’re hitting a state collision, because post-RDR our > connection information is the same (192.168.14.10:23456 > 192.168.14.100:12345). That means we can’t create a new state, and the > packet gets dropped. This is probably a dumb question because I know less than nothing about pf internals, but why wouldn't it match the existing state? Yes, the original destination was different before the redirect, but after the redirect they're going from the same host/port to the same host/port. What's the definition of state equality, and does that satisfy it? In order to say that they're not the same state, wouldn't the packets have to bear some property that survived the redirect that would distinguish them as state-unequal? If it did, would/should that property not then be part of the computation of state entry uniqueness? Like I said, probably a dumb question. > It’s a little unusual for a client to keep re-using src ports like > that, but it’s not actually wrong. After further study, I think the DNS validators used by Let's Encrypt to control TLS certificate issuance may also be doing this, which would make it a little more urgent. (But that bears confirmation.) Thanks! _______________________________________________ freebsd-pf@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
