From owner-freebsd-ipfw@FreeBSD.ORG Fri Oct 3 04:36:48 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00716106568A for ; Fri, 3 Oct 2008 04:36:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outv.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id DA0C08FC19 for ; Fri, 3 Oct 2008 04:36:47 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id E3A5923F1; Thu, 2 Oct 2008 21:36:47 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 40FC72D6010; Thu, 2 Oct 2008 21:36:45 -0700 (PDT) Message-ID: <48E5A166.8000806@elischer.org> Date: Thu, 02 Oct 2008 21:36:54 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Dan Johnson References: <48E59912.10903@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: IPFW fwd issue. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2008 04:36:48 -0000 Dan Johnson wrote: > On Fri, Oct 3, 2008 at 12:01 AM, Julian Elischer 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@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >>> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >>> >> > _______________________________________________ > 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"