[squid-users] Strange Interaction between Squid and Facebook

[Amos Jeffries]

On 30/10/2015 8:44 a.m., Patrick Blair - Peapod wrote:
> Since then, everything has been working fine, apart from one site,
> Facebook, not loading correctly. It varies based on the particular browser
> accessing it, but some/most of the style sheets or content don't appear to
> load correctly, resulting in a very mangled look. Running the developer
> tools for each respective browser give us information that the connections
> to the stylesheets or content are aborted. Most of this content is hosted
> on fbcdn.net, which we've made sure is on our allowed domains list.
> What is interesting is that the first object (or multiple ones) is
> retrieved successfully through the proxy, but subsequent ones are denied.
> Again, this appears to vary depending on browser/os combinations, with
> Chrome on OSX and IE (on Windows) seeming to work the best.
> 
> We are NOT running a Tproxy or any other sort of intercepting proxy, all
> the clients are explicitly aware of the proxy's existence through a .pac
> configuration file pushed out through Group Policy.
> 

Are these https:// traffic arriving to the proxy in the form of CONNECT
requests?

Or regular http:// URLs arriving as GET method?

Is a POST or PUT method request involved with the fetch or just prior?

Is there an unusual port being used?

Or an OPTIONS request happening for some reason?



> I've tried disabling ssl_bump (which shouldn't be enabled anyway) for the
> facebook domains, setting cache deny for those domains, and setting always
> direct for those domains, none of which has had any effect.

Nod. As long as you do not use "ssl-bump" on any http_port or https_port
bumping will not happen.

> 
> I've also tried reverting to a more "simple" config, even the exact config
> that we were using on the "old" Squid that was working on Solaris, but that
> too fails. I've also changed from using Squid 3.5.10 to the version
> packaged by CentOS (squid-3.3.8-12.el7_0.x86_64), tried this with both
> configurations to no avail.
> 
> The only thing that has worked is setting up a "test" squid at our primary
> datacenter, same configurations, but this one does work. We've checked and
> verified that there are no custom routes or any other network
> configurations that vary between the servers, only IP addresses. Both are
> on unrestricted vlans that allow direct access to the internet. We are
> checking with our networking team to see if there is any custom routing
> that is in place on their end, but it's very doubtful that is the case.

I'm also a bit suspicious in these situations that it might have
something to do with the network IP-range the clients are on vs the
uplink being used.

Is it breaking only when Squid is in the "other" datacenter from the
client(s) ?

Is one datacenter IPv6-enabled but not the other ?


You could possibly set "debug_options ALL,0 17,4" to track the Squid
outbound message forwarding and see what appears to be going on when it
is connecting out for that domain.

Amos