Yet Another Transparent Squid Thread, With A Twist?

All:

I've scoured the forums & Googled extensively before posting, perhaps I've missed something, but please take me at my word I did a thorough search for answers before posting this question, and I'm hoping DutchDaemon responds since he seems to be quite in the know about this. :)

I have a FreeBSD AMD64 7.2 installation, with squid 2.7STABLE6 from the ports tree (this version is in use since it's the production FreeBSD release @ my provider), and I'm attempting to create a transparent squid proxy, with this configuration:

- Management interface, bge0, IP address x.x.x.x
- em0, part of bridge0, no IP address.
- em1 part of bridge0, no IP address.
- bridge0, no IP address.
- transparent bridge squid configuration on lo0
- pf
- Nice, "unsafe" 666 permissions on /dev/pf. =)

I have my Internet traffic passing through the bridge sitting between a commercial firewall and the Internet uplink, and I've been happily able to snoop on traffic with tcpdump, etc. as well as filter traffic using PF on one of the member bridge links (the sysctl settings for filtering on the bridge as well as member interfaces are all set to 1). PF HFSC queueing works like a charm as well on the em0 interface pre-queuing outbound traffic to the 'Net.

What I'm wanting to do is create a transparent proxy, where I can re-route HTTP traffic (just like you specified, DutchDaemon, the PF rdr and route-to) to loopback, and then have it passed along out the bridge like it would have gone, out to the Internet router.

I'm a router / switch geek as well as a sysadmin, so thinking this through, I considered that - does squid need a "next hop" address to route it's connection to the destination website? If so, this configuration needs tweaking or won't work, but I'm hoping I've just missed something essential to make it go.

Thanks in advance for any / all responses.
 
I've never tested Squid on an 'IP-less' installation. Since Squid originates the outbound HTTP requests, it needs to be able to send these requests with a valid source IP address to a default gateway, at least (even with some next-hop, how would you route back to an IP-less machine?). So consider putting an IP address and a default gateway on (an element of) the bridge. Squid can remain bound to localhost:3128, but the outbound HTTP traffic will take the default gateway and use the available IP address. PF's state table will keep track of return traffic.
 
Thanks, Will Post Results.

DutchDaemon, thanks for responding, and so quickly! You confirmed what I suspected, so I'm going to go back into the lab, setup a new test environment and dump the results out here in a few days so maybe it can help others too. I was hoping PF had some "special bridge sauce" that would enable proxying across a bridge, maybe it's time to do some coding. :e

For the moment, I'll make a bridge member facing the firewall product IP-addressable, and tie the Squid configuration to that interface by making it the default route out. That makes a bit of a mess of the routing picture on the host, but I think it's workable with a few static routes pointing to my internal networks and changing the default route.
 
'proxying across a bridge' will work fine, 'proxying on a bridge' (intercepting, redirecting & originating traffic) is something else ...
 
Aye, I understand. :)

Thanks for clarifying on the post - the nomenclature is really important - "across" is one kind of forwarding activity , and "on" implies another set of activities on traffic that aren't the same.

I was hoping that there was some special, unknown-to-me PF feature + code in squid that would enable the "on-the-bridge" kind, along with squid, where squid did not have to originate a socket connection, but instead just scrubbed the web traffic in-the-middle, on the bridge.

I hope for too much LOL. :e

It does give me some interesting coding ideas, from a security perspective I find it highly desirable to eliminate as much routing / socket connection generation as possible, and instead replace with transparent, no-IP-endpoint devices to the point it doesn't wreck infrastructure or interfere with core routing functions, etc., etc.
 
BTW, this is enough for /dev/pf:

Code:
# Allow Squid read acess to /dev/pf
own     pf      root:squid
perm    pf      0640

This goes in /etc/devfs.conf.
 
Mmm, I think it is possible to do as a bridge, but like DD said the proxy will need some kind of IP address with which to fetch content from the web. I don't think the proxy has to be a gateway in order for it to intercept traffic from clients and generate traffic to clients - a bridge should be able to do the same.

Having said that I can't say I've ever tried it, and can't say I've ever encountered a situation in which it's worth considering. I generally dislike transparent proxies - have you considered just blocking port 80 and implementing WPAD instead? You'll be smiling the day the proxy server ever dies - just stop advertising it via WPAD instead of having it block all your traffic, web included. (I'm assuming this is for a corporate environment)
 
aragon said:
I don't think the proxy has to be a gateway in order for it to intercept traffic from clients and generate traffic to clients

No, it doesn't. It just needs an IP address to originate traffic from, and a default gateway somewhere on the bridged network to drop traffic on and receive return traffic from. The PF rdr rule is stateful and will relay the resulting HTTP reply back to the client.
 
Back
Top