[squid-users] tcp_outgoing_address and external ACL not reliable

From: <m.stiefenhofer@dont-contact.us>
Date: Mon, 15 Aug 2005 11:00:56 +0200

Hi,

we're using Squid with NTLM authentication and an external ACL (wb_group)
for windows group based authorization - which was working fine for years.

Now we've got an upstream "proxy" as content filter. The aim is to
"submit" windows group information to the upstream content filter for
using different filtering policies based on the users windows group. The
only way seems to be the tcp_outgoing_address.

Although there's already this thread:
http://www.squid-cache.org/mail-archive/squid-users/200309/0261.html we're
experiencing problems which are not covered there.

Here's our first attempt with:
Squid Cache: Version 2.5.STABLE10
configure options: --enable-default-err-language=German
--enable-ntlm-auth-helpers=SMB '--enable-auth=basic ntlm'
--enable-external-acl-helpers=wbinfo_group
--enable-basic-auth-helpers=NCSA

squid.conf:
[...]
auth_param ntlm program /usr/local/squid/libexec/ntlm_auth DOMAIN/pdc
DOMAIN/bdc
auth_param ntlm children 15
auth_param ntlm max_challenge_reuses 2
auth_param ntlm max_challenge_lifetime 20 minutes

external_acl_type NT_global_group ttl=300 negative_ttl=300 concurrency=15
%LOGIN /usr/local/squid/libexec/wb_group

acl ProxyUsersGroup1 external NT_global_group Proxy-group1
acl ProxyUsersGroup2 external NT_global_group Proxy-group2
acl ProxyUsersGroup3 external NT_global_group Proxy-group3
acl ProxyUsersGroup4 external NT_global_group Proxy-group4
acl ProxyUsersGroup5 external NT_global_group Proxy-group5

acl ProxyUsersDefault external NT_global_group Proxy

http_access allow password ProxyUsersGroup1
http_access allow password ProxyUsersGroup2
http_access allow password ProxyUsersGroup3
http_access allow password ProxyUsersGroup4
http_access allow password ProxyUsersGroup5

http_access allow password ProxyUsersDefault

http_access deny all

tcp_outgoing_address 10.2.74.14 ProxyUsersGroup5
tcp_outgoing_address 10.2.74.14 ProxyUsersGroup4
tcp_outgoing_address 10.2.74.13 ProxyUsersGroup3
tcp_outgoing_address 10.2.74.12 ProxyUsersGroup2
tcp_outgoing_address 10.2.74.11 ProxyUsersGroup1
tcp_outgoing_address 10.2.74.10
[...]

Most of the time this is working reliable, especially when there's not
much traffic. But sometimes 50% or more of requests from users that should
be in Group1...5 are going out with the default IP 10.2.74.10.
And even worse: in some cases, requests of users which are definitely not
in Groups1...5 are going out with one of the IPs 10.2.74.11...14.

The external ACL is forced to be evaluated, because it's used in
http_access, but the results seem to get lost sometimes somewhere before
tcp_outgoing_address.

We've even tried the hint from the above mentioned thread and added the
following before the first http_access_allow (and even tried moving it
after the last http_access allow):

acl dummy src 0.0.0.0/32
http_access deny ProxyUsersGroup1 dummy
http_access deny ProxyUsersGroup2 dummy
http_access deny ProxyUsersGroup3 dummy
http_access deny ProxyUsersGroup4 dummy
http_access deny ProxyUsersGroup5 dummy

Where are we wrong, or ist it some kind of bug?

Kind regards,
 
Marek Stiefenhofer
ECOFIS GmbH
IT Security
Received on Mon Aug 15 2005 - 03:00:59 MDT

This archive was generated by hypermail pre-2.1.9 : Thu Sep 01 2005 - 12:00:02 MDT