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
