[squid-users] squid-users Digest, Vol 27, Issue 28
squid3 at treenet.co.nz
Wed Nov 16 01:27:11 UTC 2016
On 16/11/2016 1:28 p.m., vze2k3sa at verizon.net wrote:
> On 15/11/2016 9:05 a.m., Patrick Flaherty wrote:
>> Can anyone tell me if the 'HIER_NONE' entries below is Squid not able
>> to connect to www.website.com? The 21 sec timeout is a classic Windows
>> TCP connection timeout. I just need confirmation that that Squid on
>> these 2 clients behalf (10.10.15.96 & 10.10.15.81) could not connect
>> to www.website.com and timed out after ~21 secs.
>> 09/Nov/2016:11:54:53 -0500 21029 10.10.15.96 TAG_NONE/503 0 CONNECT
>> www.website.com:443 - HIER_NONE/- -
>> 09/Nov/2016:11:54:53 -0500 21029 10.10.15.81 TAG_NONE/503 0 CONNECT www.
>> website.com:443 - HIER_NONE/- -
> HIER_NONE - no upstream server was involved / contacted.
> 503 - Squid encountered an error which prevented upstream server transaction being successful.
> TAG_NONE - non-TCP protocol occuring.
> This NONE/503 combo appears usually when SSL-Bump feature is doing TLS interception - either the TLS handshake failed or your configured choice of bumping action is not possible.
> Thanks Amos for that clarity although now I'm not sure why this happened. If the upstream server did not respond (which is what I thought) I would say I understand. But if Squid actually made no attempt to contact the server, then Squid itself had an issue. I do not use SSL-Bump so maybe Squid had some internal error?
> When you say ' HIER_NONE - no upstream server was involved / contacted.' does that mean Squid did not even try to connect to the upstream server or could it mean that it tried to connect and there was no response?
Squid may have attempted TCP connection(s) to servers, but none succeeded.
> Here is my Squid.conf file in case of misconfiguration.
> # Smart911 CPE/Smart911 Console Squid Proxy Configuration
> # Network(s) where proxy traffic is originating
> # acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
> # acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
> # acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
> acl localnet src all
localnet is supposed to be your LAN network range(s). "all" means entire
> # acl and http_access ("rmsc.txt")
> acl whitelist dstdomain "c:/squid/etc/squid/rmsc.txt"
> http_access allow whitelist
> acl http proto http
> acl https proto https
> acl SSL_ports port 443
> acl Safe_ports port 80 # http
> acl Safe_ports port 443 # https
> acl CONNECT method CONNECT
> # rules allowing proxy access
> http_access allow http Safe_ports whitelist localnet
> http_access allow https SSL_ports whitelist localnet
None of these rules do anything after the "allow whitelist" rule above
which already let everything from any source, or protocol through to
Also, custom http_access rules need to be ....
> # Deny requests to certain unsafe ports
> http_access deny !Safe_ports
> # Deny CONNECT to other than secure SSL ports
> http_access deny CONNECT !SSL_ports
... down here after the default port-based security protection.
> # Lastly deny all other access to this proxy
> http_access deny all
> # Listens to port 3128
> http_port 3128
> # DNS servers
> dns_nameservers 18.104.22.168 22.214.171.124
The Google DNS service delivers a different IP address result in every
lookup for domains which have more than one IP.
It is better to have a local resolver that is shared by Squid and
clients. That resolver can forward to the Google service if you like.
Doing that will protect the proxy from constantly changing domains.
> # Roll log file daily and keep 30 days
> logfile_rotate 30
> # Access log format
> logformat squid %tl %6tr %>a %Ss/%03>Hs %<st %rm %ru %un %Sh/%<A %mt
Either use the built-in 'squid' format, or define a custom one with a
new name. Please do not re-define the native format, results are not
what one expects.
> # Debug
> # debug_options ALL,2
> # Use IPv4 based DNS first
> dns_v4_first on
> # Log definitions
> access_log stdio:c:/Squid/var/log/squid/access.log
> cache_store_log stdio:c:/Squid/var/log/squid/store.log
You can improve performance by not using a store.log. It is only useful
for debugging cache issues.
More information about the squid-users