Date: Mon, 22 Sep 2008 17:31:08 +0400 From: Roman Kurakin <rik@inse.ru> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: Max Laier <max@love2party.net>, freebsd-net@freebsd.org Subject: Re: Firewall redirect doesn't work any more... Message-ID: <48D79E1C.3060003@inse.ru> In-Reply-To: <20080922102209.GB2468@garage.freebsd.pl> References: <20080919075633.GA4333@garage.freebsd.pl> <20080919121602.GC4333@garage.freebsd.pl> <200809191538.02698.max@love2party.net> <20080922102209.GB2468@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, 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)?). > I use ipfw(8) fwd for tcp with bridge and it works (more or less) fine for me. The network scheme in my setup is: if0 - bridge0 - vlanX lo0 connected jails with private IPs. forwarding enabled, also net.link.bridge.pfil_local_phys=1 to get more control on traffic, but this should not affect the result. I do not use pf since it have problems with ftp+nat. All packets from vlanX to any 80 are redirected to a squid-jail, and there is no problems. (Mostly no, since I have some instability and I get connection timeouts and need to press reload time to time in my browser window. Can't say what is the reason since IIRC the squid version was of the last but no-stable version and it was the first time I've used jail for squid and also jail are behind the natd. I just didn't have a time to dig this problem.) But once again it works. So, could you draw you connections and related firewall rules. And the one you are trying to setup. I will also try to update the machine to the most recent 7 to see if my setup will stop working. Currently machine runs early September checkout. PS. Also check the mac address issue that was discussed here (case where the brdige0 and the first bridge member share the same MAC). rik
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48D79E1C.3060003>