On 11/11/2014 11:47 AM, 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
Based on a suggestion from Amos Jeffries, I changed my squid.conf
http_port directives to:
http_port 192.168.101.253:3128
http_port 192.168.101.253:3129 intercept
#https_port 192.168.101.253:3130 intercept ssl-bump
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
cert=/etc/squid/ssl_cert/myca.pem key=/etc/squid/ssl_cert/myca.pem
Note that the https_port directive is commented out for now because I
just wanted to get HTTP interception working first. I have changed to
using the default proxy port of 3128 as a (no-intercept) forwarding port
and changed the intercept port to use 3129. Also -- and this may be
important in my case -- I added the squid server internal LAN IP address
to the http_port directives. This host has multiple NICs and I wonder if
not specifying the eth1 address (eth0 is for internet access) that
something weird happened before. In any case going to
https://www.google.com now works every time (keeping fingers crossed).
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. 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
Note that other HTTPS sites worked fine! It appears to be confined to a
google specific issue.
Thanks for any comments/suggestions you might have,
--peter
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
