[squid-users] Problem with https://www.google.com and squid interception

[Yogesh Gawankar]

hello peter
can you check if your squid does gre return? 


It is unrelated to your issue though :) Thanks and regards

Yogesh Gawankar
 

     On Wednesday, November 12, 2014 9:02 AM, Amos Jeffries <squid3 at treenet.co.nz> wrote:
   

 -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/11/2014 7:47 a.m., Peter Gross wrote:
> Hi, I am a new user of Squid and would first like to thank the
> developers for this excellent software. This is my first post to
> the mailing list ... I have been tasked with setting up quite
> restrictive web access control at work. I plan to use an
> intercepting squid proxy with SSL bump. There will also be WCCPv2
> to/from a Cisco IOS router. Since this is quite a bit of
> complexity, I though it prudent to start slowly, in steps. So first
> -- to get my feet wet -- I set up squid (version 3.4.8, built using
> rpmbuild from the src rpm from ngtech) on a home linux server
> (Centos 5.11 -- no Cisco at home) which is also the firewall router
> for my home network. I also decided to start out with plain vanilla
> proxying (no interception -- use browser setting). This worked 
> fine. I then tested HTTP interception by changing squid.conf from: 
> http_port 3128 -to- http_port 3128 intercept

Please use a second http_port with a different number for each input
"mode". Squid needs at least one forward-proxy port for things like
icons URLs in error pages - 3128 is the port number W3C allocated for
that.

> 
> and adding the following rule to my shorewall firewall: 
> REDIRECT:info  loc:192.168.101.9      3128    tcp    http
> 
> I wanted to test intercepting just one host before turning it on
> for all hosts and wireless devices in my network.
> 
> 192.168.101.9 is another Centos PC on my network. Squid is running
> on 192.168.101.253.
> 
> The interception seemed to work fine ... access.log showed lots of 
> successful proxy activity. Then came the problem: going to 
> https://www.google.com failed (not every time, but frequently). If
> I turned off the REDIRECT line in the shorewall rules file and
> restarted shorewall, no problem. This seemed very peculiar because
> no HTTPS traffic should be redirected to the proxy.

Correct. Very perculiar.

> Here are the errors that showed up in cache.log when redirection
> (NAT-ing) was on:
> 
> 2014/11/11 11:03:42 kid1| ERROR: NF getsockopt(ORIGINAL_DST) failed
> on local=192.168.101.253:3128 remote=192.168.101.9:34165 FD 11
> flags=33: (92) Protocol not available

That is forward-proxy traffic going to the port with intercept on it.
Separating the ports should help you identify if this is error pages
embeded objects or not.


Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUYtSvAAoJELJo5wb/XPRjcJ0H/jeEbRpFJYp0v5nfTWlwdOTV
ajA2SpQ+3GY0s8iPX0FJnl2mFSfNVs5V+515/iOSGfEUhIS/+qGyWCqIjA79tTHy
dTx9eKOc1boF/7nadgfFl/60rpJprNfuosh9iIhkDShC3bNzz3y5lcPVyPi4bhKD
wkG/dT5GdUdVTVn1aA1cojebrJ2SUMe/NMyFdEADIyOLSNsDT000MMB4Mr3VnVBA
68nq6wdGdnK0/ydm/OvErruVgPqQGP/IvpdLaHw0+2ck2fYRlzgB9+6P1an24rDA
hgsn0sZ/MfIxJd/biC5Pk0gnNzapVI+n4E2NIx+F0aN/y2Bgn0+AncvEqKnSS3U=
=tp1A
-----END PGP SIGNATURE-----
_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20141112/bffb1813/attachment-0001.html>