Date: Wed, 14 Oct 2020 12:52:55 -0400 From: J David <j.david.lists@gmail.com> To: Kristof Provost <kp@freebsd.org> Cc: Andreas Longwitz <longwitz@incore.de>, freebsd-pf@freebsd.org Subject: Re: Packets passed by pf don't make it out? Message-ID: <CABXB=RRYSn6eXCnkhjNKuzDPTsefEUVKEQ1vZMxYfLBromW4Nw@mail.gmail.com> In-Reply-To: <0072D8A9-6ACE-47D0-AE94-124C4F955735@FreeBSD.org> References: <CABXB=RSO2UDx2=LWx7W5SigYgJcaZ3vUTR0%2BVTDJUx2QezHK1Q@mail.gmail.com> <CABXB=RQE74yggCj6=Zizb2rQjtCi=hg155J0_u=NRK2Q3QHmqg@mail.gmail.com> <5F8336C7.5020709@incore.de> <CABXB=RRdbDYyKfXUtyc9eW-P8eoX2nUb1A1Tn46MHWv5YNjT0g@mail.gmail.com> <5F84CF18.1040905@incore.de> <0072D8A9-6ACE-47D0-AE94-124C4F955735@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org> wrote: > I see the same =E2=80=98stack key attach failed=E2=80=99 error message. M= y current > thinking is that we=E2=80=99re hitting a state collision, because post-RD= R our > connection information is the same (192.168.14.10:23456 > 192.168.14.100:12345). That means we can=E2=80=99t create a new state, an= d 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=E2=80=99s a little unusual for a client to keep re-using src ports lik= e > that, but it=E2=80=99s 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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABXB=RRYSn6eXCnkhjNKuzDPTsefEUVKEQ1vZMxYfLBromW4Nw>