IPFW fwd issue.

[Dan Johnson]

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 at 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 at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
>> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe at freebsd.org"
>>
>>
>
>