Re: [squid-users] Config Analysis for VPN Access

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Fri, 18 Oct 2013 01:13:38 +1300

On 17/10/2013 10:41 p.m., Edmonds Namasenda wrote:
> Hi Squid Users / Admins,
>
> Below is my squid.conf of 3.1.23 running on openSuSe 11.4 32-bit using
> transparent mode and Shoreline Firewall.
> The server controls five networks, four of them through VPNs.
>
> Problems...
> - Failure to access Internet on VPNs unless proxy settings are added

Can only be a client software or routing problem for traffic reaching
the proxy.
If it were a proxy problem then manually configuring would have no
effect either.

> - Failure to reach DNS and HQ public IP Address

By who/what ?

> - Some "admin" IP addresses are randomly (time) blocked from accessing
> the Internet

You mean the ACL named "admin" ? see below.

Before we start note that "all" on the end of lines has _no meaning_
unless an authentication related ACL is immediately to its left.

You dont have authentication ACLs. So every single "all" on the end of
lines is wasted CPU time.

> Where could we be going wrong? How can the set-up be improved?
>
> ## Start squid.conf
>
> acl manager proto cache_object
> acl localhost src 127.0.0.1/32 ::1
> acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
>
> alnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines

cut-n-past error?

> acl SSL_ports port 443
> acl Safe_ports port 80 # http
> acl Safe_ports port 21 # ftp
> acl Safe_ports port 443 # https
> acl Safe_ports port 70 # gopher
> acl Safe_ports port 210 # wais
> acl Safe_ports port 1025-65535 # unregistered ports
> acl Safe_ports port 280 # http-mgmt
> acl Safe_ports port 488 # gss-http
> acl Safe_ports port 591 # filemaker
> acl Safe_ports port 777 # multiling http
> acl CONNECT method CONNECT
>
> acl usul src 10.40.1.0/24 10.40.2.0/24 10.40.3.0/24 10.40.4.0/24 10.40.5.0/24

Try:
   acl usul src 10.40.1.0-10.40.5.0/24

> acl noaccess src "/etc/squid/noaccess.txt"
> acl admin src "/etc/squid/admin.txt"
> acl a37 src "/etc/squid/one37.txt"
> acl srvips src "/etc/squid/srvips.txt"
> acl mgrs src "/etc/squid/mgrs.txt"
> acl clerix src "/etc/squid/clerix.txt"
>
> acl NoGenNet time MTWHFA 08:00-12:59
> acl NoGenNet time MTWHFA 13:59-16:59
> acl NoGenNet time S 07:00-12:59
> acl NoGenNet time SMTWHFA 19:00-23:59
> acl NoGenNet time SMTWHFA 00:00-06:59
>
> acl YouTube time SMTWHFA 19:00-23:59
> acl YouTube time SMTWHFA 00:00-07:59
>
> acl nommq req_mime_type -i "/etc/squid/nommq.txt"
>
> acl donot urlpath_regex -i "/etc/squid/donot.txt"
> acl srvurls dstdomain -i "/etc/squid/srvurls.txt"
> acl fewurls dstdomain -i "/etc/squid/fewww.txt"
> acl one37 dstdomain -i "/etc/squid/url37.txt"
> acl malice dstdomain -i "/etc/squid/malware.acl"
> acl porn dstdomain -i "/etc/squid/xxx.acl"
> acl ads dstdomain -i "/etc/squid/ads.acl"
> acl tubeyou dstdomain -i "/etc/squid/utube.txt"
>
> http_access allow manager localhost
>
> http_access allow srvurls all
> http_access allow fewurls all
> http_access allow admin mgrs all

Possible problem. Only admin who are both "admin" AND "mgrs"
simultaneously are permitted here.
Any "admin" IPs which are not "mgrs" as well will continue on down the
access controls ...

> http_access allow one37 a37

Note: admin who are not in "mgrs" but are in "a37" will be permitted to
these sites.

> http_access deny tubeyou !YouTube

Note: admin who are not in "mgrs" or "a37" will be time-blocked from
tubeyou destinations.

> http_access deny malice all
> http_access deny porn all
> http_access deny ads all
>
> http_access deny noaccess
> http_access deny srvips !srvurls all

Note: admin who are not in "mgrs" or "a37" MAY be blocked by any of the
above denials.

> http_access deny NoGenNet clerix all

Note: admin who are not in "mgrs" or "a37" but are in "clerix" WILL be
time-blocked.

>
> http_access deny donot !admin
> http_access deny nommq !admin !mgrs
> http_access allow usul all

Note: admin who are not in "mgrs" or "a37" but are n "usul" will be
permitted by the above line.

Note also: general users matched by any of the above lines, including
"usul" will have unlimited access through the proxy with CONNECT method
and to any unsafe port (heard of many HTTP proxies relaying email to
port 25 from infected clients? yours *is* one of those).

> http_access deny manager noaccess
>
> http_access deny !Safe_ports
>
> http_access deny CONNECT !SSL_ports
>
> http_access deny to_localhost
>
> http_access allow localhost
>
>
> http_access deny all
>
> error_directory /usr/share/squid/errors/en
>
> icp_access allow usul
> icp_access deny all
>
> htcp_access allow usul
> htcp_access deny all
>
>
> http_port 3128 intercept

It is best not to use port 3128 for interception. Pick a random port
number for receiving intercepted traffic and firewall it away from
direct access by any contact from outside the machine running Squid. The
NAT operation should be done by the Squid machine firewall itself
diverting port 80 to your port-X. Only that firewall and Squid should
know the port number.

The current releases of Squid require a separate forward-proxy port
separate from the interception port. You may as well use port 3128 for
its intended purpose, although the exact port number for that is optional.

> #http_port 80 intercept ## ?!
> #http_port 8080 intercept ## ?!
>
> #http_port all intercept ## Best each port above or this?
>
> hierarchy_stoplist cgi-bin ?
>
> cache_mem 400 MB
>
> cache_dir ufs /var/cache/squid 20000 16 256
>
> coredump_dir /var/cache/squid
>
> access_log /var/log/squid/access.log squid
>
> minimum_object_size 512 KB
> maximum_object_size 4 MB
> maximum_object_size_in_memory 6 MB
>
> 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
>
> dns_nameservers 41.##.##.# 41.##.##.#
>
> visible_hostname ######
> icp_port 3130
> cache deny YouTube tubeyou

Why is caching of youtube contents only permitted during certain times?
This directive has the annoying side effect of starting to purge cache
contents which it blocks, since they are non-cacheable they should not
have been stored.

Amos
Received on Thu Oct 17 2013 - 12:13:49 MDT

This archive was generated by hypermail 2.2.0 : Thu Oct 17 2013 - 12:00:06 MDT