From owner-freebsd-pf@freebsd.org Wed Oct 14 17:59:17 2020 Return-Path: Delivered-To: freebsd-pf@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E84E743F842 for ; Wed, 14 Oct 2020 17:59:17 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CBKtF5nKBz4JZ2; Wed, 14 Oct 2020 17:59:17 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 9118D237E8; Wed, 14 Oct 2020 17:59:17 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 0A81C3B66A; Wed, 14 Oct 2020 19:59:16 +0200 (CEST) From: "Kristof Provost" To: "J David" Cc: "Andreas Longwitz" , freebsd-pf@freebsd.org Subject: Re: Packets passed by pf don't make it out? Date: Wed, 14 Oct 2020 19:59:15 +0200 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: References: <5F8336C7.5020709@incore.de> <5F84CF18.1040905@incore.de> <0072D8A9-6ACE-47D0-AE94-124C4F955735@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 17:59:18 -0000 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 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? > “It’s complicated”. In essence, pf tracks both the pre- and post-translation tuple, so what we’re seeing here is one of those conflicting with an existing session and that’s causing the failure. 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). Best regards, Kristof