From owner-freebsd-pf@freebsd.org Wed Oct 14 16:53:08 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 AF1B443E138 for ; Wed, 14 Oct 2020 16:53:08 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CBJPw2gzvz4Fdl; Wed, 14 Oct 2020 16:53:08 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: by mail-lf1-x141.google.com with SMTP id v6so164307lfa.13; Wed, 14 Oct 2020 09:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+BSzQt6mi4HlpVhj9HaQiyFtMmc9RwGcsY8hcksuqcw=; b=cP7ExcPoy2meoJmRbUvaqVmMpSJepOCgf5ViEmfxqYDVbENVdjDW1iC5WW5C8usOJM /sHhktMDD6mbukXD7fqL6UuzNa93xEE/y5+w3EB4VrUxEYUDVtN2ZXQ0jDqp0aJmvB4x jaZMOmaj7nD703CHTC6z8Pi1iQjGl5AAuEpYotsPGDyzDCtWkpwjH669JeldITGZ0fVu EI/1LKn/P5YIFHwqiTqyODAUl+mh/CICD8Hkb1yBiMl1us/nZwbg08zeeSVrvW9Kx+S1 3+sjObSVjyk1ziIZbAZgaxnITI6kAaPg0vc3MG/dLdg8nOaan4Z9XDRZdczVOdnJd0u7 VMVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+BSzQt6mi4HlpVhj9HaQiyFtMmc9RwGcsY8hcksuqcw=; b=lcW+EPpuM40OeN2DBwGDIQnCiLP3F57T4ljmDFU2Fy9V268TTHbtLMRC+TDvwNzSMo DZSgU8SXWFozRrSu268geXV92bi8oXYx8P/3fFj3YkxOz6dpQGlkSMwmxCmA/rBIqlv6 EqmEfhXkxPKIyF4Mj6rKXs65eywFg/OFAklwTQPL44CVFduIVopH+hk0GYx4jmrYbPr2 SX/tWF3ewgHouzg8Qujd1ZqVg6W69G39sHGMWy7nqRw79/ZP3QOFy6V2h2B3ujjMUkNt mY2w16wVzWxswRE9LvzvEQBXHLfqad5xWtaaE9mc7GC4nK5Zdq7+9QVw6jhL3q06xvbI 4HPw== X-Gm-Message-State: AOAM532Ak/UabcACJB1PKTucJMq2zeAi9mklRwBaBxqh4Gq36rp1ab55 Gwc5ERezJMUFg5coUwBJaoMh+L89Yx9HiaJ+gZryESnM7NI= X-Google-Smtp-Source: ABdhPJxGUl9HpwMbpYgXljbDi8E/JS7zbiY8srjAkg7lmXcZlvqZb+Qw3rdjMAYK5IA6bdSnchtToNtS0kzmwqavKOs= X-Received: by 2002:ac2:5048:: with SMTP id a8mr82417lfm.60.1602694386328; Wed, 14 Oct 2020 09:53:06 -0700 (PDT) MIME-Version: 1.0 References: <5F8336C7.5020709@incore.de> <5F84CF18.1040905@incore.de> <0072D8A9-6ACE-47D0-AE94-124C4F955735@FreeBSD.org> In-Reply-To: <0072D8A9-6ACE-47D0-AE94-124C4F955735@FreeBSD.org> From: J David Date: Wed, 14 Oct 2020 12:52:55 -0400 Message-ID: Subject: Re: Packets passed by pf don't make it out? To: Kristof Provost Cc: Andreas Longwitz , freebsd-pf@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4CBJPw2gzvz4Fdl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; REPLY(-4.00)[] 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 16:53:08 -0000 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 =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!