[squid-users] SquidNT cache_peer authentication/encryption/failover

Hi everyone,

Here is my goal:
I would like for my laptop users to be routed through my public squid proxy
so that when they are anywhere, including in a hotel/coffee shop/etc, their
traffic is coming through us.
 
After asking around and researching some options, one interesting option
includes using squid in a way I had never thought of.

The setup I saw had one Squid server as a standard Internet facing proxy
server (nothing special about that). The interesting thing was they also had
installed Squid locally on the laptop clients and ran Squid using the
cache_peer option to forward all traffic to the standard Squid server (this
is somewhat guesswork because the setup I saw is closed source, but I had
some clues that points me in this direction).

NOTE:
SquidNT (2.7.STABLE5 on server, 2.7.STABLE6 on clients) Windows XP SP3 on
clients Windows 2003 Server for server role Clients all have proxy settings
set to localhost on port 3128 Server is listening on port 80 This is an AD
domain, all settings pushed by GPO's.
Users running with user rights, and machines are fairly locked down (can't
touch the options in IE)
server- internet facing Squid server running normal proxy service
client- laptop computers running Squid and forwarding all requests to the
server using cache_peer

I have gotten both the Squid server and Squid client up and running, with a
few problems/questions.

1. I have the forwarding working in some manor. The problem I have is I have
the public facing server set up to require authentication. I have tried the
login=user:password option for cache_peer on the client side, still with no
luck. When looking at the the access logs on the server, the Squid client
isn't passing the credentials supplied to the Squid server (ie. see below)

1237037364.556 0 68.117.163.156 TCP_DENIED/407 1804 GET
http://yahoo.com/ - NONE/- text/html

2. I also am looking for an option in squid.conf that essentially says "if
you cant reach the cache_peer, then go direct for this query". Hopefully
this will resolve the problems I have been having in hot spots with captive
portals. I have looked at always_direct and never_direct, but after reading,
it doesn't look either of those are what I am looking for. I would expect
this to allow the authentication to the captive portal, but as soon as the
cache_peer was reachable, for all traffic to be redirected to it.

3. Lastly, I am interested in using SSL to encrypt the traffic going from
the client to the server. I am using the SSL version of SquidNT
(http://squid.acmeconsulting.it/download/squid-2.7.STABLE6-bin-SSL.zip), so
the options are available, I just have not found any good documentation on
how to set this up (specifically, what has to be configured on the server
side (the client settings seem pretty strait forward, the stuff I have found
is always for setting up SSL redirects/etc. for web servers using
acceleration mode).

If I need to provide any further information, please let me know. Thanks for
any help/suggestions, have a good one!
 
Josh
 
 
Before I came to trying Squid in this manor, here were other ways I tried to
proxy users sessions.
 
1. A simple proxy setting in Internet Explorer to point all traffic back
through the public proxy. This fails in the following way: Say a user is at
a hot spot with a captive portal that requires authentication. This sets it
up a problem where the browser cant get to the proxy server because of the
captive portal, and cant authenticate to the captive portal because of the
proxy settings (and bypass proxy server for local addresses wont work
because a lot of captive portals authenticate to non local addresses).
2. PAC files- I thought this was going to be the answer, but unfortunately
this leaves too many holes open. The problem is that when the user first
logs on to a hot spot, the browser cant talk to the proxy (because the user
isn't authenticated yet to the captive portal), so everything is direct
(unfiltered, not good). It takes the user having to close and then open the
browser again before the session would be directed to the proxy (again, not
good).

NOTE: All this is worthless is some situations, as some hot spots don't
allow proxy connections (even if they are going to a proxy on port 80).

Here is my client squid.conf (without commenting for brevity ;)
WELCOME TO SQUID 2.7.STABLE6
auth_param ntlm program c:/squid/libexec/mswin_ntlm_auth.exe
auth_param ntlm children 5
auth_param ntlm keep_alive
onexternal_acl_type win_domain_group ttl=300 %LOGIN
c:/squid/libexec/mswin_check_lm_group.exe -G -c acl all src all
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8
acl localnet src 10.0.0.0/8
acl localnet src 172.16.0.0/12
acl localnet src 192.168.0.0/16
acl SSL_ports port 443
acl Safe_ports port 80
acl Safe_ports port 21
acl Safe_ports port 443
acl Safe_ports port 70
acl Safe_ports port 210
acl Safe_ports port 1025-65535
acl Safe_ports port 280
acl Safe_ports port 488
acl Safe_ports port 591
acl Safe_ports port 777
acl CONNECT method CONNECT
http_access allow all #this is for testing ONLY
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localnet
http_access deny all
icp_access allow localnet
icp_access deny all
http_port 3128
cache_peer squidserver.com parent 80 0 proxy-only no-query
hierarchy_stoplist cgi-bin ?
access_log c:/squid/var/logs/access.log squid
cache deny all
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
acl shoutcast rep_header X-HTTP09-First-Line ^ICY.[0-9]
upgrade_http0.9 deny shoutcast
acl apache rep_header Server ^Apache
broken_vary_encoding allow apacheprefer_direct off
coredump_dir c:/squid/var/cache

-- 
View this message in context: http://www.nabble.com/SquidNT-cache_peer-authentication-encryption-failover-tp22540738p22540738.html
Sent from the Squid - Users mailing list archive at Nabble.com.