Date: Thu, 2 Oct 2008 22:35:34 -0400 From: "Dan Johnson" <dan_johnson@doomed.us> To: "Jason Lewis" <me@sharktooth.org>, freebsd-ipfw@freebsd.org Subject: Re: IPFW fwd issue. Message-ID: <f29069d60810021935x72fcf9c5icb38d9b753df5329@mail.gmail.com> In-Reply-To: <48E580D1.2050106@sharktooth.org> References: <f29069d60810021512h1483be20t8010d62b69647991@mail.gmail.com> <48E580D1.2050106@sharktooth.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Correct. The issue was that watching lo0 "tcpdump -nnvvei lo0" didn't show the forwarded traffic, it was still going out xl1 unmodified, acting like the rule was a simple 'accept.' I saved this email draft then went back and recompiled my kernel to include ipfw at the core instead of as a module and that fixed everything. Apparently IPFIREWALL_FORWARD is horribly broken when compiled into ipfw as a module, I personally dont care that ipfw is a fixed part of that box's kernel now, but some might. Really the only reason I sent to the mailing list instead of discarding is so once it gets indexed, someone else banging their head against the wall will have this reference. :) On Thu, Oct 2, 2008 at 10:17 PM, Jason Lewis <me@sharktooth.org> wrote: > 127.0.0.1 is on the interface of lo0. You will need to run tcpdump > against that interface to see the traffic. You also need to setup squid > with transparent forwarding. This means that squid will accept any packet > as another host. > > 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. >> 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.) >> >> 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. >> >> After noting that I was using a module, I said screw it, and compiled IPFW >> into the base kernel, viola now it works fine. >> _______________________________________________ >> 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?f29069d60810021935x72fcf9c5icb38d9b753df5329>