Re: [squid-users] Inaccessible google.com (squid-3.4)

2014-04-23 Thread Marcello Romani

Il 28/03/2014 15:19, Kinkie ha scritto:

Hi Marcello,
   have you tried accessing google FROM the squid box itself?



Hi,
the problem just happened again.
Strangely enough, on the squid box itself the command host 
www.google.com gave me this output:


$ host www.google.com
www.google.com has address 173.194.112.19
www.google.com has address 173.194.112.20
www.google.com has address 173.194.112.18
www.google.com has address 173.194.112.17
www.google.com has address 173.194.112.16
;; connection timed out; no servers could be reached
;; connection timed out; no servers could be reached



After a few seconds the problem fixed itself for no apparent reason.
Google.com was normally browsable again, and host www.google.com gave:

$ host www.google.com
www.google.com has address 173.194.112.20
www.google.com has address 173.194.112.16
www.google.com has address 173.194.112.17
www.google.com has address 173.194.112.18
www.google.com has address 173.194.112.19
www.google.com has IPv6 address 2a00:1450:4001:800::1014


So far I think it's safe to assume it's not an issue with squid itself, 
but rather something (occasionally) broken in our DNS chain...


--
Marcello Romani


Re: [squid-users] Inaccessible google.com (squid-3.4)

2014-04-03 Thread Marcello Romani

The issue happened a couple more times since my first post.

I've applied a modified logformat, which highlights response times, dns 
query times and reply sizes.
Sorting by response time descending it appears I've got a problem with 
CONNECT requests to port 443.


Could it be a SSL-related misconfiguration on my part?

Thank you in advance.


Here are some of the first lines of my access.log sorted by response 
time descending (some fields awk'd out for clarity):



1st column: %tr - response time
2nd column: $dt - total time spent making DNS lookups
3rd column: %st - req + reply size incl. headers
4th column: %rm - req method
5th column: %ru - req url from client

500256 96 6726 CONNECT javadl-esd-secure.oracle.com:443
357444 1959 3657 CONNECT www.google.com:443
357216 5382 3658 CONNECT www.google.com:443
298138 - 6907 CONNECT www.google.com:443
298136 797 3914 CONNECT www.google.com:443
223620 39 186847 CONNECT www.facebook.com:443
183223 40 36982 CONNECT scontent-b-mxp.xx.fbcdn.net:443
181589 180 7128 CONNECT pixel.facebook.com:443
180107 38 6825 CONNECT www.google.com:443
179132 - 5648 CONNECT www.google.com:443
179116 - 5648 CONNECT www.google.com:443
179101 896 2397 CONNECT www.google.com:443
179101 - 5911 CONNECT www.google.com:443
179100 244 5654 CONNECT www.google.com:443
179096 38 5659 CONNECT www.google.com:443
179095 48 5652 CONNECT www.google.com:443
179094 57 5651 CONNECT www.google.com:443
179094 - 5659 CONNECT www.google.com:443
179094 50 5650 CONNECT www.google.com:443
179093 - 5650 CONNECT www.google.com:443
179090 - 5652 CONNECT www.google.com:443
179088 0 5651 CONNECT www.google.com:443
178606 0 2398 CONNECT www.google.com:443
178577 39 2398 CONNECT www.google.com:443
178372 231 2393 CONNECT www.google.com:443
178302 217 2390 CONNECT www.google.com:443
178241 259 2395 CONNECT www.google.com:443
178114 212 2395 CONNECT www.google.com:443
178103 239 2399 CONNECT www.google.com:443
178095 342 2396 CONNECT www.google.com:443
178093 220 2395 CONNECT www.google.com:443
178090 339 2396 CONNECT www.google.com:443
177553 0 2396 CONNECT www.google.com:443



and here's my squid.conf (minus sensitive info)



logformat mylogformat  %tl %tr %dt %st %a %Ss %Sh %rm %ru
access_log daemon:/usr/local/squid/var/logs/access.log mylogformat
cache_log /usr/local/squid/var/logs/cache.log

client_netmask 255.255.255.0
acl localnet src 

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

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager

acl bulk_transfers_1 dstdomain ***
acl bulk_transfers_2 dstdomain ***
acl bulk_transfers_3 url_regex -i ***
acl bulk_transfers_4 url_regex -i ***
acl bulk_transfers_5 url_regex -i ***
acl bulk_transfers_6 url_regex -i ***
acl bulk_transfers_7 url_regex -i ***
acl bulk_transfers_8 url_regex -i ***
acl bulk_transfers_10 dstdomain ***
acl bulk_transfers_11 dst ***
acl bulk_transfers_12 dstdomain ***

acl primeblacklist dstdomain ***
acl myblacklist dstdomain ***
acl adv_domains_re dstdom_regex ***
acl adv_urls url_regex ***
acl adv_passthrough_regex url_regex ***
acl adv_passthrough_dstdom dstdomain ***

http_access allow adv_passthrough_regex
http_access allow adv_passthrough_dstdom
http_access deny primeblacklist
http_access deny CONNECT primeblacklist
http_access deny myblacklist
http_access deny CONNECT myblacklist
http_access deny adv_domains_re
http_access deny CONNECT adv_domains_re
http_access deny adv_urls
http_access deny CONNECT adv_urls

http_access allow localnet
http_access allow localhost
http_access deny all

http_port 3128

cache_replacement_policy heap LFUDA
cache_dir aufs /home/squid3/cachedir2 2 32 256

maximum_object_size 100 MB
cache_mem 512 MB

cache_effective_user proxy
cache_effective_group proxy

coredump_dir /usr/local/squid/var/cache/squid

refresh_pattern ^ftp:   144020% 10080
refresh_pattern ^gopher:14400%  1440
refresh_pattern -i (/cgi-bin/|\?) 0 0%  0
refresh_pattern .   0   20% 4320


append_domain ***

tcp_outgoing_address ***addr_A*** bulk_transfers_1
tcp_outgoing_address ***addr_A*** bulk_transfers_2
tcp_outgoing_address ***addr_A*** bulk_transfers_3
tcp_outgoing_address ***addr_A*** bulk_transfers_4
tcp_outgoing_address ***addr_A*** bulk_transfers_5
tcp_outgoing_address ***addr_A*** bulk_transfers_6
tcp_outgoing_address ***addr_A*** bulk_transfers_7
tcp_outgoing_address ***addr_A*** bulk_transfers_8
tcp_outgoing_address ***addr_A*** 

Re: [squid-users] Inaccessible google.com (squid-3.4)

2014-03-29 Thread Eliezer Croitoru

On 03/28/2014 06:23 PM, Marcello Romani wrote:

ping www.google.com from the box itself worked while Firefox on my PC
wasn't able to get to Google's home page.
Haven't tried accessing www.google.com via HTTP from the squid box,
though (it's a command-line only box). Will try next time, though
(perhaps with wget or lynx/links...)

Thanks for the hint.

wget and curl are fine.
You can also use telnet or nc to verify basic port 80 connectivity.
nc IP PORT -v
should do the trick.

Eliezer


[squid-users] Inaccessible google.com (squid-3.4)

2014-03-28 Thread Marcello Romani

Hi,
   I'm struggling with a recurring problem, namely the very long time 
it takes (and often the impossibility) to reach www.google.com from my 
LAN, which sits behind a custom compiled squid-3.4.


When this happens, other websites are not affected.
Also, if I change the browser setting to no proxy, the problem goes away.

As a workaround, issuing /usr/local/squid/sbin/squid -k reconfigure 
temporarily fixes the problem: after it has completed, pressing F5 or 
trying to directly access www.google.com again succeds within the usual 
time frame.


My squid.conf has

dns_v4_first on

Also, /proc/sys/net/ipv6/conf/default/disable_ipv6 == 1

squid -v reads as follows:

# /usr/local/squid/sbin/squid  -v
Squid Cache: Version 3.4.4
configure options:
'--prefix=/usr/local/squid'
'--enable-xmalloc-statistics'
'--enable-storeio=aufs diskd rock ufs'
'-enable-removal-policies=heap lru'
'--enable-icmp'
'--enable-delay-pools'
'--enable-ssl'
'--disable-auth'
--enable-ltdl-convenience

The box is a Primergy TX200 server running debian 6.0.9, with 
2.6.32-5-686-bigmem kernel.


Any hints as to where to look to pinpoint the issue would be greatly 
appreciated.


Thank you in advance.

--
Marcello Romani


Re: [squid-users] Inaccessible google.com (squid-3.4)

2014-03-28 Thread Eliezer Croitoru
I have the same issue and since they had couple issues with their dns 
cache services I assume it's not the only issue.
Can you try to use tcpdump and filter it to google related 
packets\connections?


Eliezer

On 03/28/2014 01:56 PM, Marcello Romani wrote:

Hi,
I'm struggling with a recurring problem, namely the very long time
it takes (and often the impossibility) to reach www.google.com from my
LAN, which sits behind a custom compiled squid-3.4.

When this happens, other websites are not affected.
Also, if I change the browser setting to no proxy, the problem goes away.

As a workaround, issuing /usr/local/squid/sbin/squid -k reconfigure
temporarily fixes the problem: after it has completed, pressing F5 or
trying to directly access www.google.com again succeds within the usual
time frame.

My squid.conf has

dns_v4_first on

Also, /proc/sys/net/ipv6/conf/default/disable_ipv6 == 1

squid -v reads as follows:

# /usr/local/squid/sbin/squid  -v
Squid Cache: Version 3.4.4
configure options:
'--prefix=/usr/local/squid'
'--enable-xmalloc-statistics'
'--enable-storeio=aufs diskd rock ufs'
'-enable-removal-policies=heap lru'
'--enable-icmp'
'--enable-delay-pools'
'--enable-ssl'
'--disable-auth'
--enable-ltdl-convenience

The box is a Primergy TX200 server running debian 6.0.9, with
2.6.32-5-686-bigmem kernel.

Any hints as to where to look to pinpoint the issue would be greatly
appreciated.

Thank you in advance.





Re: [squid-users] Inaccessible google.com (squid-3.4)

2014-03-28 Thread Marcello Romani

Il 28/03/2014 15:19, Kinkie ha scritto:

Hi Marcello,
   have you tried accessing google FROM the squid box itself?



ping www.google.com from the box itself worked while Firefox on my PC 
wasn't able to get to Google's home page.
Haven't tried accessing www.google.com via HTTP from the squid box, 
though (it's a command-line only box). Will try next time, though 
(perhaps with wget or lynx/links...)


Thanks for the hint.



On Fri, Mar 28, 2014 at 11:56 AM, Marcello Romani
mrom...@ottotecnica.com wrote:

Hi,
I'm struggling with a recurring problem, namely the very long time it
takes (and often the impossibility) to reach www.google.com from my LAN,
which sits behind a custom compiled squid-3.4.

When this happens, other websites are not affected.
Also, if I change the browser setting to no proxy, the problem goes away.

As a workaround, issuing /usr/local/squid/sbin/squid -k reconfigure
temporarily fixes the problem: after it has completed, pressing F5 or trying
to directly access www.google.com again succeds within the usual time frame.

My squid.conf has

dns_v4_first on

Also, /proc/sys/net/ipv6/conf/default/disable_ipv6 == 1

squid -v reads as follows:

# /usr/local/squid/sbin/squid  -v
Squid Cache: Version 3.4.4
configure options:
'--prefix=/usr/local/squid'
'--enable-xmalloc-statistics'
'--enable-storeio=aufs diskd rock ufs'
'-enable-removal-policies=heap lru'
'--enable-icmp'
'--enable-delay-pools'
'--enable-ssl'
'--disable-auth'
--enable-ltdl-convenience

The box is a Primergy TX200 server running debian 6.0.9, with
2.6.32-5-686-bigmem kernel.

Any hints as to where to look to pinpoint the issue would be greatly
appreciated.

Thank you in advance.

--
Marcello Romani







--
Marcello Romani


Re: [squid-users] Inaccessible google.com (squid-3.4)

2014-03-28 Thread Marcello Romani

Il 27/03/2014 15:25, Eliezer Croitoru ha scritto:

I have the same issue and since they had couple issues with their dns
cache services I assume it's not the only issue.
Can you try to use tcpdump and filter it to google related
packets\connections?

Eliezer


I will next time it happens.

I haven't been able to reproduce the issue at will yet.

Thanks.



On 03/28/2014 01:56 PM, Marcello Romani wrote:

Hi,
I'm struggling with a recurring problem, namely the very long time
it takes (and often the impossibility) to reach www.google.com from my
LAN, which sits behind a custom compiled squid-3.4.

When this happens, other websites are not affected.
Also, if I change the browser setting to no proxy, the problem goes
away.

As a workaround, issuing /usr/local/squid/sbin/squid -k reconfigure
temporarily fixes the problem: after it has completed, pressing F5 or
trying to directly access www.google.com again succeds within the usual
time frame.

My squid.conf has

dns_v4_first on

Also, /proc/sys/net/ipv6/conf/default/disable_ipv6 == 1

squid -v reads as follows:

# /usr/local/squid/sbin/squid  -v
Squid Cache: Version 3.4.4
configure options:
'--prefix=/usr/local/squid'
'--enable-xmalloc-statistics'
'--enable-storeio=aufs diskd rock ufs'
'-enable-removal-policies=heap lru'
'--enable-icmp'
'--enable-delay-pools'
'--enable-ssl'
'--disable-auth'
--enable-ltdl-convenience

The box is a Primergy TX200 server running debian 6.0.9, with
2.6.32-5-686-bigmem kernel.

Any hints as to where to look to pinpoint the issue would be greatly
appreciated.

Thank you in advance.






--
Marcello Romani


Re: [squid-users] Inaccessible google.com (squid-3.4)

2014-03-28 Thread Kinkie
Hi Marcello,
  have you tried accessing google FROM the squid box itself?


On Fri, Mar 28, 2014 at 11:56 AM, Marcello Romani
mrom...@ottotecnica.com wrote:
 Hi,
I'm struggling with a recurring problem, namely the very long time it
 takes (and often the impossibility) to reach www.google.com from my LAN,
 which sits behind a custom compiled squid-3.4.

 When this happens, other websites are not affected.
 Also, if I change the browser setting to no proxy, the problem goes away.

 As a workaround, issuing /usr/local/squid/sbin/squid -k reconfigure
 temporarily fixes the problem: after it has completed, pressing F5 or trying
 to directly access www.google.com again succeds within the usual time frame.

 My squid.conf has

 dns_v4_first on

 Also, /proc/sys/net/ipv6/conf/default/disable_ipv6 == 1

 squid -v reads as follows:

 # /usr/local/squid/sbin/squid  -v
 Squid Cache: Version 3.4.4
 configure options:
 '--prefix=/usr/local/squid'
 '--enable-xmalloc-statistics'
 '--enable-storeio=aufs diskd rock ufs'
 '-enable-removal-policies=heap lru'
 '--enable-icmp'
 '--enable-delay-pools'
 '--enable-ssl'
 '--disable-auth'
 --enable-ltdl-convenience

 The box is a Primergy TX200 server running debian 6.0.9, with
 2.6.32-5-686-bigmem kernel.

 Any hints as to where to look to pinpoint the issue would be greatly
 appreciated.

 Thank you in advance.

 --
 Marcello Romani



-- 
Francesco