Date: Thu, 02 Oct 2008 21:01:22 -0700 From: Julian Elischer <julian@elischer.org> To: Dan Johnson <dan_johnson@doomed.us> Cc: freebsd-ipfw@freebsd.org Subject: Re: IPFW fwd issue. Message-ID: <48E59912.10903@elischer.org> In-Reply-To: <f29069d60810021512h1483be20t8010d62b69647991@mail.gmail.com> References: <f29069d60810021512h1483be20t8010d62b69647991@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Johnson wrote: > After beating my head against this for days I ran out of places to look for > information, and almost sent this as a help request instead of an > observation. So excuse the present tense. > > > All I am actually trying to accomplish is a simple (This worked flawless > last i tried under 4.5) squid transparent proxy. so, what revision are you trying to do this on? I think in 6.1 it was disabled without an extra option. (see in LINT) > I'm using this rule before the nat rule: > > 00100 fwd 127.0.0.1,3128 log ip from any to any 80 out > > When I attempt to hit port 80 on an external server, the security log shows > the rule was processed, and claims it was forwarded to 127.0.0.1,3128. OK > > Watching tcpdump -nnvvei lo0 shows no relevant activity. BUT, watching > tcpdump -nnvvei xl1 (external iface) shows the port 80 SYN being sent to the > remote web server with the original source ip address from 192.168.0.0/24, > still using the destination MAC of my default gateway. This is with or > without the squid daemon running. And when i do have it running i have it on > the local console with debugging enabled (incase a stray packet actually > makes it in.) that sounds a bit like the problem I mention above... however, sending it to 127.0.0.1 doesn't mean it goes through lo0 so you'll never see it there. > > The same holds true if i setup the fwd to my xl1 interface ip address, or > another host ex 192.168.0.30. > > Running tcpdump (Linux) eth0 in promisc on 192.168.0.30 also doesn't show > any traffic being forwarded its way when configured to do so. So I'm > inclined to beleive this isn't just an error on tcpdumps part (as there is > an open issue reported with tcpdump and ipfw fwd) but that the traffic > really isn't being modified. > > The only thing I was doing that is unique is I recompiled the ipfw module to > include -DIPFIREWALL_NAT and -DIPFIREWALL_FORWARD instead of adding the > whole mess to the base kernel. ah that will fail because the IPFIREWALL_FORWARD option has to change things in teh tcp and Ip code too. > > After noting that I was using a module, I said screw it, and compiled IPFW > into the base kernel, viola now it works fine. yeah the whole ip stack need to be compiled with those options.. > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48E59912.10903>