Date: Tue, 16 Mar 2004 11:17:25 -0700 From: Dan Vande More <dvm@firstlink.com> To: Tony Frank <tfrank@optushome.com.au> Cc: freebsd-ipfw@freebsd.org Subject: Re: transparent squid bridge Message-ID: <1079461045.1240.315.camel@dvmgentoo> In-Reply-To: <20040316123848.GA89792@marvin.home.local> References: <1079113870.1238.8.camel@dvmgentoo> <1079366908.1274.5.camel@dvmgentoo> <20040316123848.GA89792@marvin.home.local>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2004-03-16 at 05:38, Tony Frank wrote:
> 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 ?
Options bridge is on, I am using ipfw2 / 5.2.1
Well ok, here comes the dumb part.
If I'm using 5.2.1, it's using ipfw2 by default right? I don't need to
do anything special to use it, is what I read. (And ipfw2 is not a
kernel option like it is in 4.x)
I've googled six ways from sunday and don't see how to check with
version I'm using.
ipfw -v/ipfw --version/strings /sbin/ipfw doesn't work/reveal anything.
>
> > 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?
Yeah, it says it diverted the packet, but it doesn't show up at the
machine it was diverted to.
>
> > 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.
Yeah, they are different servers, for the sake of simplicity. Once I get
this working, I intend to experiment with keeping them on the same
server.
By saying either worked for your, are you saying that you have this
working?
>
> 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.
>
It doesn't look like you have it enabled but should I have
net.inet.ip.check_interface=0
on? I know I need it when I run dsr on my load balanced mail servers,
because they need to accept packets destined for another ip.
> >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.
So you got past the ipfw stuff, and now you can't get squid working?
Did you try --enable-ipf-transparent in the configure?
How about httpd_accel_uses_host_header on in the conf?
I have that setup working on openbsd, works perfect. But openbsd
doesn't:( (Can't handle the load)
>
>
> > *************************************
> > 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?
>
Yeah but the 3rd one is wrong, with 5.2 it appears it's:
sysctl net.link.ether.bridge.enable=1
(Which is what I used, I just forgot to include it above.)
> 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
>
Everything looks exactly the same minus the number of
"net.link.ether.bdg_predict", but I assume that's related to packets
going in and out. Mines 180.
> >
> > **************************************
> > 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
>
What do you mean check the fwd rule, it looks the same, minus your rule
10. (which I'm gonna try)
> 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
Thank you Tony, you've been a big help, considering I still didn't even
know if this had been done by anybody but Mr. Rizzo.
In your opinion, is it better for me to try this on 4.9?
Thanks!
Dan Vande More
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1079461045.1240.315.camel>