From nobody Fri Jan 27 13:16:24 2023 X-Original-To: pf@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P3J4S3w3jz3bw0p for ; Fri, 27 Jan 2023 13:16:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P3J4S1rz2z4KW6 for ; Fri, 27 Jan 2023 13:16:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1674825384; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HWH+zqBmNHeETjNMi5kzoTMspaJG44bSY3IoeC2dzFI=; b=KSMn1JZDiEoohboGAnmeTuCXACL5+Yt4pjLJi8JXg8t19IEf+q1EjdW6UMrzKyBiCiChb6 OMGjNOnnK4UHloeUyduDcq0tofAdqfWvh+exq9eFadmEv0Hz5zH0/CKsFpqYYVHrU5Kdu6 n4GQiiK9a4Krup1+6fKHIGrwUbTFwkhwm0rCFT3wO6uVb1rcp3Anxlr2IrY/xOQ/TX34Xm k3yJyjM1XOy4U5lYcpPpNTCCtndPg2NJNBjEWRWuAAyeV4LrcNaPBX+J7WPPzQM0xVC1B4 0tdllxw68Zeenm6jeiss7fkD9Z9s+K8SVvz+9CQuS/KMSw0to0A38LpC/lnd3w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1674825384; a=rsa-sha256; cv=none; b=RDLlpkAPufH46PpUNhrzoWxYrRrrSVspZQnjuBQZFA56dxNlMOVpMd/HrXtuSkTezqFalG rW/YYLTnklfnuD6laowK/bZLy4sB/7LnEj8mYwRujGkxVbuzxqd2xlQi5XDaLngiMLk/oo +4Pj0rGHhQdfwyuTw9JpdFqHAiBGlN+oPWK40Te2GebAUJG/qWAX5T/CPO9BZvIo38Px3a YHmvGdl/GqTtQz067SViH/pVUTYg17zbRTFJVyqcE3oAVFTQP4MvJMLpQ+sDgplri24Dje jgab9Y37os3FNF0W/bpccDCsZErogGcIBKIAsEOhK+NWQAzNqzqPmsZFxGRZow== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4P3J4S0nk0z19RB for ; Fri, 27 Jan 2023 13:16:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 30RDGOmQ058039 for ; Fri, 27 Jan 2023 13:16:24 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 30RDGOT9058038 for pf@FreeBSD.org; Fri, 27 Jan 2023 13:16:24 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: pf@FreeBSD.org Subject: [Bug 268717] [pf] rdr rules don't work for traffic originating at localhost Date: Fri, 27 Jan 2023 13:16:24 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dfr@rabson.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pf@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Technical discussion and general questions about packet filter (pf) List-Archive: https://lists.freebsd.org/archives/freebsd-pf List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D268717 --- Comment #18 from dfr@rabson.org --- (In reply to Kristof Provost from comment #17) > Sort of. I find it more useful to think about when the packets pass throu= gh which parts of the stack. That does imply a direction (i.e. PF_IN/PF_OUT= ). In the normal case, when we're thinking of rdr, we'd be dealing with incomi= ng packets, arriving through ip_input(), triggering a PF_IN pf_test(). For the failing case described here we're dealing with packets that are generated locally, and the first time they hit the firewall is from ip_outp= ut() (i.e. pf_test(PF_OUT)). I like this description of the situation. In this case though, locally generated packets are seen by the firewall via ip_input, causing PF_IN event and creating the state: (kgdb) bt #0 pf_create_state (r=3D0xfffffe00041c6df8, nr=3D0xfffff80027b0d800, a=3D0= x0, nsn=3D0x0, nk=3D0xfffff80027b03a50, sk=3D0xfffff80027b03aa8, m=3D0xfffff800= 276b0200, off=3D20, sport=3D13975, dport=3D20480, rewrite=3D0xfffffe000378cae8, sm=3D0xfffffe000378cce8, t= ag=3D-1, bproto_sum=3D19927, bip_sum=3D0, hdrlen=3D20, pd=3D, kif=3D<= optimized out>) at ../../../netpfil/pf/pf.c:4533 #1 pf_test_rule (rm=3Drm@entry=3D0xfffffe000378ccd8, sm=3Dsm@entry=3D0xfffffe000378cce8, direction=3Ddirection@entry=3D1, kif=3Dkif@entry=3D0xfffff800039b3200, m=3Dm@entry=3D0xfffff800276b0200, off=3Doff@entry=3D20, pd=3D0xfffffe00= 0378cc00, am=3D0xfffffe000378ccb8, rsm=3D0xfffffe000378cca8, inp=3D0x0) at ../../../netpfil/pf/pf.c:4483 #2 0xffffffff80e6fc82 in pf_test (dir=3Ddir@entry=3D1, pflags=3D65536, ifp=3D0xfffff800038f2800, m0=3Dm0@entry=3D0xfffffe000378cdb0, inp=3D0x0) at ../../../netpfil/pf/pf.c:7217 #3 0xffffffff80e90f15 in pf_check_in (m=3D0xfffffe000378cdb0, ifp=3D0x0, flags=3D41175, ruleset=3D, inp=3D0x5000) at ../../../netpfil/pf/pf_ioctl.c:6463 #4 0xffffffff80d506e5 in pfil_mbuf_common (pch=3D, p=3D..., p@entry=3D..., ifp=3D0xfffff800038f2800, ifp@entry=3D0xfffffe000378cd80, fl= ags=3D65536, inp=3Dinp@entry=3D0x0) at ../../../net/pfil.c:214 #5 pfil_mbuf_in (head=3D0xfffff8000389de00, p=3Dp@entry=3D..., ifp=3Difp@entry=3D0xfffff800038f2800, inp=3Dinp@entry=3D0x0) at ../../../ne= t/pfil.c:226 #6 0xffffffff80dcfbb6 in ip_input (m=3D0xfffff800276b0200) at ../../../netinet/ip_input.c:613 #7 0xffffffff80d4d261 in netisr_process_workstream_proto (nwsp=3D0xffffffff825866c0, proto=3D1) at ../../../net/netisr.c:929 #8 swi_net (arg=3D0xffffffff825866c0) at ../../../net/netisr.c:976 In this case, the interface is lo0 and direction is PF_IN. The problem (at least as I understand it) is that the replies don't generate the correspond= ing PF_OUT and the state isn't matched. The return packets cause a PF_IN from t= he incoming interface (e.g. bridge0) which does nothing and then they are delivered to the local tcp stack without reversing the redirect and are immediately rejected with RST. >> I thought about whether it makes sense for rdr state creation to happen = on PF_OUT but wouldn't that have other problems since the un-redirected des= tination address may direct the packet to the wrong outgoing interface? > > I'm not sure I follow. What I'm trying to say is that for connection attempts to some local address which would match the rdr rule, there will not be a PF_OUT event to trigger= for the same reason as what I'm suggesting above for the current PF_IN triggered rule. The packet won't be re-written but instead will be delivered to the l= ocal tcp and rejected. > To be clear, I'm not making any promises about the time and effort I can = spend on this. Also to be clear, I'm not asking for you to do the work necessarily. I am perfectly happy to do it if someone is prepared to review the change. I do = have the time to work on this and the motivation since this problem is a blocker= for my projects. I am going to spend some time to see if ipfirewall is also affected. I have= a feeling that it might be for similar reasons. --=20 You are receiving this mail because: You are the assignee for the bug.=