> Ok... here's a status report. In trying to debug this thing, we > disabled the "transparency" mode by changing the firewall configuration > to NOT route all HTTP traffic to the squid-cache and instead run HTTP > traffic through itself as it did before. I then reconfigured my browser > settings to force me to go through the proxy-cache and tried reaching > the same troubled web sites. THEY WORKED!! This leads me to believe > that there is something wrong with the way I'm setting up the > "transparency" configuration. The Watchguard firewall allows me to > enter the IP and Port of a proxy server. While reading through the > "transparency" how-to, they tell you to create a route on the > proxy-server back to the firewall. But my firewall and proxy-server are > on the same subnet. So by simply keeping the default route that is on > the proxy-server, it finds the firewall anyways. But this is where I > start to doubt if I'm correct. > > Do you have any ideas?? Not really, only the list of possible caveats which can be encountered with transparant proxying, therefore I advice against it : - Intercepting HTTP breaks TCP/IP standards because user agents think they are talking directly to the origin server. - It causes path-MTU to fail. Possibly making the website not accessible. - As a result for instance on older IE versions ; "reload" did not work as expected. - You can't use proxy authentication - You can't use IDENT lookups - Intercepting proxies are incompatible with IP filtering designed to prevent address spoofing. - Clients are still expected to have full Internet DNS resolving capabilities , when in certain Intranet/Firewalling setups , this is not always wanted. - Related to above : because of transp. proxy setup : squid connects to a site which is down.HOWEVER , due to the transparant proxying setup. It gets a connected state to the interceptor. The end user may get wrong error messages or a browser, seemingly doing nothing anymore. > > The firewall and squid run on a 10.0.200.0/24 subnet (This is the subnet > we keep all our main servers on) > Workstations use a 10.0.204.0/22 subnet > Render Farms and Storage use a 10.0.108/22 > > Do I need to put a route into the squid for each of the other networks > that point back to the firewall? (10.0.204.0/22, 10.0.108.0/22) > I don't think so. M.