[squid-users] unusual TCP_DENIED situation

Hello all,

I run the network for a UK boarding school (1000 pupils and around 400
staff) and use a combination of squid and dansguardian to provide time
controlled and filtered web access for all users. From time to time a
number of users have reported receiving squid access denied messages -
though if they try accessing the same site a minute or two later they
get through to it without any issue. Is anyone able to shed light on the
condition under which a TCP_DENIED/403 message may be returned by squid
(apart from the obvious acl based ones).

My configuration is thus :

FreeBSD 8.3-RELEASE-p3 amd64 running squid-3.1.19

I actually run 5 squid instances on the server all of which use a common
set of configuration files, yet it is only one particular class of user
(the teaching staff) who are are directed via an instance with a
slightly different configuration that the others that experience the issue.

The important part of the configuration for this instance is as follows :-

visible_hostname www-proxy-a-s
http_port 10.129.128.31:8081

pid_filename /var/log/proxy/squids.pid

icp_port 0

#cache_dir null /cache

cache_peer 127.0.0.1 parent 7000 0 no-query no-digest sourcehash name=c0
cache_peer 127.0.0.1 parent 7001 0 no-query no-digest sourcehash name=c1
cache_peer 127.0.0.1 parent 7002 0 no-query no-digest sourcehash name=c2
cache_peer 127.0.0.1 parent 7003 0 no-query no-digest sourcehash name=c3

include /usr/local/etc/squid/confs/squidmachines.conf
include /usr/local/etc/squid/confs/staff/squidcontrols.conf
cache_peer_access c0 deny full_access_users
cache_peer_access c1 deny full_access_users
cache_peer_access c2 deny full_access_users
cache_peer_access c3 deny full_access_users
cache_peer_access c0 deny direct_sites
cache_peer_access c1 deny direct_sites
cache_peer_access c2 deny direct_sites
cache_peer_access c3 deny direct_sites
include /usr/local/etc/squid/confs/staff/squidaccess.conf
http_access deny pupil_own_machines
http_access deny guest_own_machines
include /usr/local/etc/squid/confs/staff/squiddelay.conf
include /usr/local/etc/squid/confs/squidcommon.conf

access_log /var/log/proxy/squidsaccess.log fsquid
cache_log /var/log/proxy/squidscache.log

always_direct allow full_access_users
always_direct allow direct_sites

tcp_outgoing_address our-public-ip-address full_access_users
tcp_outgoing_address our-public-ip-address direct_sites

The 'cache peers' are actually dansguardian instances (each having a max
of 192 processes available) and the machines being used are not in the
'full_access_users' list neither are the sites they are attempting to
access in the 'direct_sites' list.

Has anyone else experienced such behaviour in a similar environment ?

regards,
Mark Redding
Received on Wed Nov 20 2013 - 15:38:40 MST