Packets passed by pf don't make it out?

[J David]

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 <kp at 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!