IPFW fwd issue.

[Julian Elischer]

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 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"