Date: Fri, 27 Jan 2023 13:16:24 +0000 From: bugzilla-noreply@freebsd.org To: pf@FreeBSD.org Subject: [Bug 268717] [pf] rdr rules don't work for traffic originating at localhost Message-ID: <bug-268717-16861-p6FTZwRV3L@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-268717-16861@https.bugs.freebsd.org/bugzilla/> References: <bug-268717-16861@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
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<optimized out>, 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<optimized out>, inp=3D0x5000) at ../../../netpfil/pf/pf_ioctl.c:6463 #4 0xffffffff80d506e5 in pfil_mbuf_common (pch=3D<optimized out>, 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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-268717-16861-p6FTZwRV3L>