Re: [squid-users] Squid3 not working after update or reinstall

WetMogwai wrote:
> I run a Squid 3 server that is acting as a web filter. It worked fine on
> Etch. The system stopped working properly due to two of the three SATA
> cables being bad. Before I figured that out, I tried doing updates. Since
> Etch updates were no longer available, I did a distupgrade to Lenny.
> Immediately, Squid stopped working properly. It would take up to two and a
> half minutes for it to respond to a web request and add it to the
> access.log. This was using the same configuration file that it was using
> before the update.
>
> After I found the hardware problem, I did a clean install of Lenny. I used
> the basic squid.conf like I did on the previous system, only changing it to
> add my ACLs and because it wasn't saving an access.log to the default
> location unless I uncommented the path directive. Now, it won't respond to a
> request at all. Forwarding is enabled and the firewall seems to be set up
> correctly. I also specified the listening address with http_port
> ipaddress:3128.
>
> This is Squid Version 3.0.STABLE8.
>

Please try the version for Lenny available from backports.org. It has a
lot fewer problems.

> Here is my firewall configuration followed by my squid.conf:
> # Generated by iptables-save v1.4.2 on Tue Aug 3 12:15:22 2010
> *nat
> :PREROUTING ACCEPT [1069181:101812985]
> :POSTROUTING ACCEPT [5783:405174]
> :OUTPUT ACCEPT [11868:1177883]
> -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
> -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128

Two redirects for eth0?
  if one is a type of eth1 or something that may be the problem.

There is also no MASQUERADE on POSTROUTING.

http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxRedirect

> COMMIT
> # Completed on Tue Aug 3 12:15:22 2010
> # Generated by iptables-save v1.4.2 on Tue Aug 3 12:15:22 2010
> *filter
> :INPUT DROP [966:104230]
> :FORWARD DROP [604:51901]
> :OUTPUT DROP [7:852]
> -A INPUT -i lo -j ACCEPT
> -A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state
> NEW -j DROP
> -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -p icmp -m icmp --icmp-type 8 -m state --state
> NEW,RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -m limit --limit 49/min -j LOG --log-prefix "iptables DENY: "
> --log-level 7
> -A INPUT -p icmp -m icmp --icmp-type 0 -m state --state RELATED,ESTABLISHED
> -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 8080 -j ACCEPT
> -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
> -A OUTPUT -o lo -j ACCEPT
> -A OUTPUT -p icmp -m icmp --icmp-type 8 -m state --state
> NEW,RELATED,ESTABLISHED -j ACCEPT
> -A OUTPUT -p icmp -m icmp --icmp-type 0 -m state --state RELATED,ESTABLISHED
> -j ACCEPT
> -A OUTPUT -p tcp -m tcp --dport 21 -j ACCEPT
> -A OUTPUT -p tcp -m tcp --dport 22 -j ACCEPT
> -A OUTPUT -p tcp -m tcp --dport 25 -j ACCEPT
> -A OUTPUT -p tcp -m tcp --dport 53 -j ACCEPT
> -A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT
> -A OUTPUT -p tcp -m tcp --dport 993 -j ACCEPT
> -A OUTPUT -p tcp -m tcp --dport 3128 -j ACCEPT
> -A OUTPUT -p tcp -m tcp -j ACCEPT
> -A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
> -A OUTPUT -p udp -m udp --dport 67 -j ACCEPT
> -A OUTPUT -p udp -m udp --dport 631 -j ACCEPT
> COMMIT

Um, ... policy DROP and port 80 not permitted outwards.

Or does that " -p tcp -m tcp j ACCEPT " do what I think and allow
everything TCP related in without restrictions? making every other TCP
rule redundant.

<snip a lot of okay config>
> http_access deny bad
> http_access allow all

Everything possible is already allowed by the above. The following
http_access rules are never used.

> http_access allow localhost
> http_access deny all
> icp_access deny all
> htcp_access deny all
> http_port 192.168.1.206:3128

You have REDIRECT at the firewall passing traffic here but no
"transparent" flag configured saying to check the NAT table.

NP: recent 3.x releases will block traffic coming via NAT to a
non-interception port and vice versa. So it is a good idea to have one
port for each traffic type. That also helps you avoid CVE-2009-0801.

> hierarchy_stoplist cgi-bin ?
> access_log /var/log/squid3/access.log squid
> refresh_pattern ^ftp: 1440 20% 10080
> refresh_pattern ^gopher: 1440 0% 1440
> refresh_pattern (cgi-bin|\?) 0 0% 0

This rule as published in the early versions was slightly too loose.
It should be:
   refresh_pattern -i (/cgi-bin/|\?) 0 0% 0

> refresh_pattern . 0 20% 4320
> icp_port 3130

Along with your only rule being "icp_access deny all" it makes better
sense to turn off at the port.
   icp_port 0

I can't see any reason on the squid.conf.

Check that the DNS servers available to Squid are responding properly.

ICMP could also be at fault, your firewall drops all the control
messages that indicate whether a remote host exists, if the cables
elsewhere on the network are congested or unplugged, TLS handshakes,
etc, etc.
  Without these responses your OS and Squid will wait whole minutes
before re-trying the alternate routes it knows about.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.6
   Beta testers wanted for 3.2.0.1