[Bug 268717] [pf] rdr rules don't work for traffic originating at localhost

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268717

--- 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 through 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 incoming
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_output()
(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=0xfffffe00041c6df8, nr=0xfffff80027b0d800, a=0x0,
nsn=0x0, nk=0xfffff80027b03a50, sk=0xfffff80027b03aa8, m=0xfffff800276b0200,
off=20, sport=13975,
    dport=20480, rewrite=0xfffffe000378cae8, sm=0xfffffe000378cce8, tag=-1,
bproto_sum=19927, bip_sum=0, hdrlen=20, pd=<optimized out>, kif=<optimized
out>)
    at ../../../netpfil/pf/pf.c:4533
#1  pf_test_rule (rm=rm@entry=0xfffffe000378ccd8,
sm=sm@entry=0xfffffe000378cce8, direction=direction@entry=1,
kif=kif@entry=0xfffff800039b3200,
    m=m@entry=0xfffff800276b0200, off=off@entry=20, pd=0xfffffe000378cc00,
am=0xfffffe000378ccb8, rsm=0xfffffe000378cca8, inp=0x0) at
../../../netpfil/pf/pf.c:4483
#2  0xffffffff80e6fc82 in pf_test (dir=dir@entry=1, pflags=65536,
ifp=0xfffff800038f2800, m0=m0@entry=0xfffffe000378cdb0, inp=0x0) at
../../../netpfil/pf/pf.c:7217
#3  0xffffffff80e90f15 in pf_check_in (m=0xfffffe000378cdb0, ifp=0x0,
flags=41175, ruleset=<optimized out>, inp=0x5000) at
../../../netpfil/pf/pf_ioctl.c:6463
#4  0xffffffff80d506e5 in pfil_mbuf_common (pch=<optimized out>, p=...,
p@entry=..., ifp=0xfffff800038f2800, ifp@entry=0xfffffe000378cd80, flags=65536,
inp=inp@entry=0x0)
    at ../../../net/pfil.c:214
#5  pfil_mbuf_in (head=0xfffff8000389de00, p=p@entry=...,
ifp=ifp@entry=0xfffff800038f2800, inp=inp@entry=0x0) at ../../../net/pfil.c:226
#6  0xffffffff80dcfbb6 in ip_input (m=0xfffff800276b0200) at
../../../netinet/ip_input.c:613
#7  0xffffffff80d4d261 in netisr_process_workstream_proto
(nwsp=0xffffffff825866c0, proto=1) at ../../../net/netisr.c:929
#8  swi_net (arg=0xffffffff825866c0) 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 corresponding
PF_OUT and the state isn't matched. The return packets cause a PF_IN from the
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 destination 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 local
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.