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 <[EMAIL PROTECTED]> 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. >> _______________________________________________ >> [email protected] mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "[EMAIL PROTECTED]" >> >> > > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
