From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 16 04:39:01 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B18E16A4CE for ; Tue, 16 Mar 2004 04:39:01 -0800 (PST) Received: from mail017.syd.optusnet.com.au (mail017.syd.optusnet.com.au [211.29.132.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FAAA43D39 for ; Tue, 16 Mar 2004 04:38:59 -0800 (PST) (envelope-from tfrank@optushome.com.au) Received: from marvin.home.local (c211-28-241-126.eburwd5.vic.optusnet.com.au [211.28.241.126])i2GCcmA16340; Tue, 16 Mar 2004 23:38:49 +1100 Received: by marvin.home.local (Postfix, from userid 1001) id 949721FB81; Tue, 16 Mar 2004 23:38:48 +1100 (EST) Date: Tue, 16 Mar 2004 23:38:48 +1100 From: Tony Frank To: Dan Vande More Message-ID: <20040316123848.GA89792@marvin.home.local> References: <1079113870.1238.8.camel@dvmgentoo> <1079114684.1240.22.camel@dvmgentoo> <1079366908.1274.5.camel@dvmgentoo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1079366908.1274.5.camel@dvmgentoo> User-Agent: Mutt/1.4.2.1i cc: freebsd-ipfw@freebsd.org Subject: Re: transparent squid bridge X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 12:39:01 -0000 Hi there, On Mon, Mar 15, 2004 at 09:08:28AM -0700, Dan Vande More wrote: > /*Repost, does anyone have an answer?*/ Maybe, see below. > Ok, to show I did try here's my diff on the manual patching. I've triple > checked my work, and everything appears to be the way it is supposed to > be. Your diff looks ok, though I only took a cursury look at it. Are you running with 'options BRIDGE' in your kernel or loading bridge module? Are you using ipfw2 or ipfw1 ? > I don't see the expected behavior, if anyone sees anything wrong, I > would appreciate some input. I wonder if you are expecting something other than the behaviour this gives? > Although the counter increases on rule 400 when a client requests a > webpage on the other side of the bridge, a 'tcpdump port 80' on > {proxy_server_ip_address} sees no packets whatsoever. > A tcpdump on the bridge server (tcpdump -n port 80) shows the packets > from the client going straight to the requested host, instead of being > hijacked and sent to the proxy server. Is your proxy and your bridge on the same system? If it is, perhaps try building the setup with two separate servers to make things a bit clearer. Either setup seemed to work for me. Note: The traffic that is 'captured' will not be rewritten to have a new destination IP address. Rather that traffic is instead sent to the new destination directly. It is up to the destination to 'recognise' this traffic and treat it appropriately. If the hosts are on separate servers you should see 'uncaptured' traffic being sent on to the default gateway (check ethernet link headers with -E option to tcpdump) and 'captured' traffic being sent to the proxy server. This is where it helps to have separate box for each function to clearly see the ethernet headers being different. >From luigi's original post: >on bridge: >sysctl net.link.ether.bridge_cfg="rl0 rl1" >sysctl net.link.ether.bridge_ipfw=1 >sysctl net.link.ether.bridge=1 >sysctl net.inet.ip.forwarding=1 >ipfw add forward proxy proto tcp from any to any 80 > >on proxy: >ipfw add forward localhost,8080 tcp from not me to any 80 Note this second ipfw line on the proxy itself. It needs to be configured to redirect the traffic to the proxy software port otherwise the server might well forward the traffic someplace else (like to a default next-hop) This setup works for me in that the tcp connection to port 80 is intercepted and sent to the local bridge/squid system, however my squid currently returns an error due to 'invalid URL' or similar. Basically it seems the URL hostname is not seen by squid. I'm running 2.4.STABLE7 and did not configure anything new in squid. That aside, the point is the redirecting of traffic from a bridge is working with these patches and FreeBSD 4.9-STABLE cvsupped today. If I have the fwd line in ipfw I get a squid error page on by client browser. If I stop squid I get a browser error due to TCP reset being received as nothing is listening on the proxy for the traffic. > ************************************* > bash-2.05b# egrep -v "^#" /etc/sysctl.conf > sysctl net.link.ether.bridge_cfg='xl0 dc0' > sysctl net.link.ether.bridge_ipfw=1 > sysctl net.link.ether.bridge=1 > sysctl net.inet.ip.forwarding=1 > ************************************* Umm, is this really what you're using? Perhaps check that all these options applied by running sysctl manually? My sysctl.conf looks like this: %%% net.link.ether.bridge_cfg="fxp0 fxp2" net.link.ether.bridge_ipfw=1 net.link.ether.bridge=1 %%% And if I run sysctl manually I get: midway [298] [11:30pm] [/var/log/squid]# sysctl net.link.ether net.link.ether.inet.prune_intvl: 300 net.link.ether.inet.max_age: 1200 net.link.ether.inet.host_down_time: 20 net.link.ether.inet.maxtries: 5 net.link.ether.inet.useloopback: 1 net.link.ether.inet.proxyall: 0 net.link.ether.inet.log_arp_wrong_iface: 1 net.link.ether.inet.log_arp_movements: 1 net.link.ether.bridge_cfg: fxp0 fxp2 net.link.ether.bridge: 1 net.link.ether.bridge_ipfw: 1 net.link.ether.bridge_ipf: 0 net.link.ether.bridge_ipfw_drop: 0 net.link.ether.bridge_ipfw_collisions: 0 net.link.ether.verbose: 0 net.link.ether.bdg_split_pkts: 0 net.link.ether.bdg_thru: 11580 net.link.ether.bdg_copied: 0 net.link.ether.bdg_copy: 0 net.link.ether.bdg_predict: 11351 net.link.ether.bdg_fw_avg: 0 net.link.ether.bdg_fw_ticks: 0 net.link.ether.bdg_fw_count: 0 net.link.ether.ipfw: 0 > > ************************************** > bash-2.05b# ipfw show > 00100 56 2920 allow ip from any to any via lo0 > 00200 0 0 deny ip from any to 127.0.0.0/8 > 00300 0 0 deny ip from 127.0.0.0/8 to any > 00400 21 1078 fwd {proxy_server_ip_address} tcp from any to any > dst-port 80 > 65000 19137 2942276 allow ip from any to any > 65535 0 0 deny ip from any to any > ************************************** Looks ok,but check the fwd rule - here's my setup: midway [297] [11:29pm] [/var/log/squid]# ipfw show 00010 46 3439 skipto 20000 ip from any to any layer2 00100 12 2122 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 01000 16 2202 allow ip from any to any 20000 46 3439 count log ip from any to any 20010 5 497 fwd 127.0.0.1,3128 tcp from any to any dst-port 80 20011 41 2942 count log ip from any to any 20012 41 2942 allow ip from any to any 65000 0 0 deny log ip from any to any 65535 0 0 deny ip from any to any I have squid listening on 127.0.0.1 port 3128. I also got it working using a second server, albeit with the error listed above (which is squid configuration, not ipfw) Hope it helps, Regards, Tony