IPFW fwd issue.

[Julian Elischer]

Dan Johnson wrote:
> On Fri, Oct 3, 2008 at 12:01 AM, Julian Elischer <julian at elischer.org>wrote:
> 
>> 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)
>>
> 
> 7.0-Release.  In my research I'd found that in 6 and I believe some point in
> 5.x  the option IPFIREWALL_FORWARD_EXTENDED was needed for this
> configuration, but apparently it was switched back for 7.

yeah that was me switching it back.. the whole feature is kinds 
useless without being able to do that..
man ssh

> 
>>
>>
>>  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.
>>
> 
> Thats what I figured might have been the case, odd that there were no errors
> logged in the firewall logs though.
> 
>>
>>
>>> 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..
> 
> 
> Hopefully next person with this issue wont bang their head on the wall as
> long once this thread is indexed. :)
> 
> 
>>
>>  _______________________________________________
>>> 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"
>>>
>>
> _______________________________________________
> 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"