Date: Tue, 16 Mar 2004 23:38:48 +1100 From: Tony Frank <tfrank@optushome.com.au> To: Dan Vande More <dvm@firstlink.com> Cc: freebsd-ipfw@freebsd.org Subject: Re: transparent squid bridge Message-ID: <20040316123848.GA89792@marvin.home.local> In-Reply-To: <1079366908.1274.5.camel@dvmgentoo> References: <1079113870.1238.8.camel@dvmgentoo> <1079114684.1240.22.camel@dvmgentoo> <1079366908.1274.5.camel@dvmgentoo>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040316123848.GA89792>