On 11/11/2014 9:05 PM, Yogesh Gawankar wrote:
hello peter can you check if your squid does gre return?
Yohesh -- there are no Cisco routers in my home network, so no GRE. I will be using GRE when/if I configure squid at work since we have Cisco routers/switches in that network.
It is unrelated to your issue though :) *Thanks and regards Yogesh Gawankar* ** On Wednesday, November 12, 2014 9:02 AM, Amos Jeffries <squid3@xxxxxxxxxxxxx> 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 <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@xxxxxxxxxxxxxxxxxxxxx <mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx> http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
