thanks to everyone for the replies! Well, the preference of bridge over routing/IP forwarding was just for simplification of deployment. And, keeping the squid process locally means cost savings for smaller office deployments.
I've been building a similar (routing) solution using linux/netfilter/ZebOS devices (for larger installations); I'm not real keen on doing it this way any more. I tried the bridge+netfilter+squid approach and got weird behavior (yes, patched the Linux kernel - that's all I seem to do anymore :( ). Anyway, I agree that it would be preferable to not have that process local on the bridge (obviously removes some of the stealth), but that's the justification, just wanted to see if it was feasible. I will put another test system together and try it. Thanks again for all the help Cheers, -Mike ----- Original Message ----- From: "Daniel Hartmeier" <[EMAIL PROTECTED]> To: "Mike LaPane" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, January 24, 2003 6:11 AM Subject: Re: pf+bridge+transparent proxy to local squid process > Actually, the redirection itself will only work if the internal > interface has an IP address. > > A 'stealth' (IP-less) bridge functionally isolates its own userland from > any networks. No userland process can establish connections, as there is > no routing table. That's basically the point of such a setup, isolating > the firewall itself from the networks. Hence, the only thing really > working in such a setup is filtering with pf. > > Consequently, if you want to keep the bridge isolated, you have to > move the squid process to another host, and redirect the http > connections to there. It will probably require a dedicated interface and > some route-to/reply-to rules, too. > > The question is really why you don't want to assign addresses to the > bridge interfaces, and why you prefer the bridge setup over plain IP > forwarding. If it's to isolate the firewall userland from the networks, > well, that's exactly what you get :) > > Daniel
