Firewall redirect doesn't work any more...

[Max Laier]

On Monday 22 September 2008 12:22:09 Pawel Jakub Dawidek wrote:
> On Fri, Sep 19, 2008 at 03:38:02PM +0200, Max Laier wrote:
> > I might be wrong, but I don't think we ever supported rdr without
> > net.inet.ip.forwarding enabled.  Maybe to a different local address, but
> > even then you'd need net.inet.ip.check_interface=0.  Looking at the code,
> > I don't see where IPFW forwarding fails (as it has its own ip_forward()
> > call), though.
>
> Ok, I did some more tests. I'm running bridge in there and trying to
> redirect packets that goes through my bridge to a local daemon.
> UDP redirect seems to work with PF:
>
> rdr on bridge0 proto udp from 10.0.1.1 to 10.0.0.2 port 12345 -> 10.0.5.123
> port 12345
>
> Between 10.0.1.1 and 10.0.0.2 there is my bridging machine. Now when I
> call 'nc -u -l 12345' on 10.0.5.123 and call 'nc -u 10.0.0.2 12345' on
> 10.0.1.1 machine I can receive packets on my nc daemon just fine, I can
> even send packets back and they are send with source address set to
> 10.0.0.2 - this is exactly what I'm looking for.
>
> Unfortunately it doesn't work for TCP. I see packets beeing redirected to
> 10.0.5.123, but my local daemon never accepts the connection and nc client
> keeps resending SYN packets.
>
> I also see weird messages in the logs:
>
> TCP: [10.0.1.1]:36973 to [10.0.5.123]:12345 tcpflags 0x4<RST>;
> syncache_chkrst: Spurious RST without matching syncache entry (possibly
> syncookie only), segment ignored (Both tcps_badrst and tcps_sc_dropped are
> increased on every connection attempt.)
>
> Any ideas how to make it work with TCP?
>
> PS. The same functionality doesn't work at all with ipfw(8) (because of
> if_bridge(4)?).

The problem is that the packet is still subject to bridge's L2 processing and 
thus will make it's way to the original MAC receiver that will bark on it.

What you could try is a pf route-to rule to lo0 and 127.0.0.1 and then rdr on 
lo0.  In contrast to rdr, a route-to rule will consume the packet and reinject 
it into the IP-processing path.  This way it won't be forwarded by the bridge 
and there should not be problems.

That being said, it's rather difficult to write firewall rules for a bridge as 
there is no clear concept of direction (in/out).  In scenarios like this I 
usually suggest filtering on the member interfaces only:

net.link.bridge.pfil_member: 1
net.link.bridge.pfil_bridge: 0

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News