Problems with squid 3.1 to 3.3 upgrade

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Problems with squid 3.1 to 3.3 upgrade

Tom Karches
I am in the process of upgrading our Squid proxy server from 3.1 (on RHEL6) to 3.3 (on RHEL7). It is configured as a explicit (not transparent) proxy that listens on port 3128. Clients are explicitly configured to use the proxy.

On the 3.3 system with the same squid.conf as the 3.1 system (I have made changes to fix warnings), the system is able to proxy internal (*.ncsu.edu) http traffic and https traffic. Anything https outside the ncsu.edu domain fails.

The system (which does not use caching) was configured to log https transactions as such :

1565183014.309    230 127.0.0.1 TCP_MISS/200 62539 CONNECT entrepreneurship.ncsu.edu:443 - DIRECT/152.1.227.116 -

which requires SSL Bumping (I believe), though there is no reference in the current configs to the use of SSL bumping .

I used curl to test the new proxy. When I attempt to proxy an external https connection, this is the result :

$ curl --proxy http://127.0.0.1:3128 https://www.google.com
curl: (56) Received HTTP code 503 from proxy after CONNECT

Proxying internal (ncsu.edu) connections this way is working correctly for http and https

When I change my squid.conf from :

http_port 3128

to 

http_port 3128 ssl-bump \
   cert=/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem \
   generate-host-certificates=on dynamic_cert_mem_cache_size=4MB

I now get the following error

squid[5796]: FATAL: No valid signing SSL certificate configured for HTTP_port [::]:3128

The certs on the new server are newer, but otherwise appear to be correct. 

Are there changes in the SSL bump config between 3.1 and 3.3 that would cause this kind of failure? Where should I be looking for the problem?

No previous experience with squid until this project. I've been doing much RTM (including the O'Reilly Squid book) searching online and debugging these past few days. Suggestions appreciated.

Thanks,
Tom

--
Thomas Karches
NCSU OIT CSI - Systems Specialist
M.E Student - STEM Education
Hillsborough 319 / 919.515.5508



_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problems with squid 3.1 to 3.3 upgrade

Alex Rousskov
On 8/8/19 3:29 PM, Tom Karches wrote:

> I am in the process of upgrading our Squid proxy server from 3.1 (on
> RHEL6) to 3.3 (on RHEL7).

It could have been worse! For example, you could ask a question about
upgrading Squid from v1.0 to v2.0... I will try to help, but I do not
remember much about v3.3 specifics.


> The system was configured to log https transactions as such:

> 1565183014.309    230 127.0.0.1 TCP_MISS/200 62539 CONNECT
> entrepreneurship.ncsu.edu:443 - DIRECT/152.1.227.116 -

> which requires SSL Bumping

No, simply logging HTTP CONNECT requests does not require bumping SSL.


> I used curl to test the new proxy. When I attempt to proxy an external
> https connection, this is the result :

> $ curl --proxy http://127.0.0.1:3128 https://www.google.com
> curl: (56) Received HTTP code 503 from proxy after CONNECT

Your Squid told curl that something went wrong. If you look at the
actual response, you may know what went wrong. The same information may
be available in Squid access.log, but the error response may have more
details than a log record. Please share that info here if it does not
point you to a solution.


> http_port 3128 ssl-bump \
>    cert=/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem \
>    generate-host-certificates=on dynamic_cert_mem_cache_size=4MB

> I now get the following error

>     squid[5796]: FATAL: No valid signing SSL certificate configured for
>     HTTP_port [::]:3128


Avoid opening the SslBump Pandora box until you have to. If all you need
is CONNECT logging, then you should be able to accomplish what you want
without SslBump pains.


> Where should I be looking for the problem?

In Squid response to curl. You can use curl tracing options or Wireshark
to see it. Squid access.log may have some clues as well.


Go Tuffy!

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problems with squid 3.1 to 3.3 upgrade

Tom Karches
In reply to this post by Tom Karches

On 8/8/19 3:29 PM, Tom Karches wrote:

> I am in the process of upgrading our Squid proxy server from 3.1 (on
> RHEL6) to 3.3 (on RHEL7).

It could have been worse! For example, you could ask a question about
upgrading Squid from v1.0 to v2.0... I will try to help, but I do not
remember much about v3.3 specifics.

I realize that it's a bit old. It is the default for RHEL 7 and unless there is a specific reason to update to the latest version, I usually stick with the default. The current proxy is 3.1 and totally works for our application.



No, simply logging HTTP CONNECT requests does not require bumping SSL.


Great. Don't want to go down that path. 

 
> I used curl to test the new proxy. When I attempt to proxy an external
> https connection, this is the result :

> $ curl --proxy http://127.0.0.1:3128 https://www.google.com
> curl: (56) Received HTTP code 503 from proxy after CONNECT

Your Squid told curl that something went wrong. If you look at the
actual response, you may know what went wrong. The same information may
be available in Squid access.log, but the error response may have more
details than a log record. Please share that info here if it does not
point you to a solution.

> Where should I be looking for the problem?

In Squid response to curl. You can use curl tracing options or Wireshark
to see it. Squid access.log may have some clues as well.




With this command :
$curl --trace --proxy http://127.0.0.1:3128 https://www.google.com

I get the HTML of the page, with this near the top :
<title>ERROR: The requested URL could not be retrieved</title>
<style type="text/css"><!--

and then :

<div id="content">
<p>The following error was encountered while trying to retrieve the URL: <a href="/">/</a></p>
<blockquote id="error">
<p><b>Invalid URL</b></p>
</blockquote>

and no 503 error at the end.

Getting this in access.log :
1565358617.666      0 127.0.0.1 TAG_NONE/400 3958 GET / - HIER_NONE/- text/html

Which seems odd. So the page is being delivered, but I don't see it unless --trace is turned on.

When I use :
curl --proxy http://127.0.0.1:3128 https://www.google.com

I get this in access.log :
1565358720.756      2 127.0.0.1 TAG_NONE/503 0 CONNECT www.google.com:443 - HIER_NONE/- -

My http_port directive is set as such :

# Squid normally listens to port 3128
http_port 3128

This is an explicit proxy so everything should be going through 3128.


I don't feel so bad about not figuring this out sooner. There was a thread with a similar problem on the list (though it was not helpful) where they were still stuck at this point after a month. I've only spent a week.



Thanks,

Tom

--
Thomas Karches
NCSU OIT CSI - Systems Specialist
M.E Student - Technology Education
Hillsborough 319 / 919.515.5508



_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problems with squid 3.1 to 3.3 upgrade

Alex Rousskov
On 8/9/19 9:59 AM, Tom Karches wrote:

> With this command :
> $curl --trace --proxy http://127.0.0.1:3128 https://www.google.com

> <p><b>Invalid URL</b></p>

Yeah, that command does not do what you think it does. This has bitten
me many times. You may want to remove the file name "--proxy" now :-).

Hint: The --trace option requires an argument.

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problems with squid 3.1 to 3.3 upgrade

Tom Karches


On Fri, Aug 9, 2019 at 11:38 AM Alex Rousskov <[hidden email]> wrote:
On 8/9/19 9:59 AM, Tom Karches wrote:

> With this command :
> $curl --trace --proxy http://127.0.0.1:3128 https://www.google.com

> <p><b>Invalid URL</b></p>

Yeah, that command does not do what you think it does. This has bitten
me many times. You may want to remove the file name "--proxy" now :-).


Doh....that was dumb. FWIW, I'm running 3.5.20, not 3.3

Ok, here is the info from the real trace. First time with #dns_v4_first on  commented out, 2nd time "dns_v4_ first on" is active. Difference is with no "dns_v4_first on" directive, I get a RR_CONNECT_FAIL 111. When active, I get a RR_CONNECT_FAIL 101. 

#dns_v4_first on   commented out
--------------------------------
<= Recv header, 34 bytes (0x22)
0000: 48 54 54 50 2f 31 2e 31 20 35 30 33 20 53 65 72 HTTP/1.1 503 Ser
0010: 76 69 63 65 20 55 6e 61 76 61 69 6c 61 62 6c 65 vice Unavailable
0020: 0d 0a
.
.
<= Recv header, 37 bytes (0x25)
0000: 58 2d 53 71 75 69 64 2d 45 72 72 6f 72 3a 20 45 X-Squid-Error: E
0010: 52 52 5f 43 4f 4e 4e 45 43 54 5f 46 41 49 4c 20 RR_CONNECT_FAIL
0020: 31 31 31 0d 0a                                  111..
.
.
== Info: Received HTTP code 503 from proxy after CONNECT
== Info: Connection #0 to host 127.0.0.1 left intact
curl: (56) Received HTTP code 503 from proxy after CONNECT



dns_v4_first on
---------------------
<= Recv header, 34 bytes (0x22)
0000: 48 54 54 50 2f 31 2e 31 20 35 30 33 20 53 65 72 HTTP/1.1 503 Ser
0010: 76 69 63 65 20 55 6e 61 76 61 69 6c 61 62 6c 65 vice Unavailable
0020: 0d 0a                                           ..

<= Recv header, 37 bytes (0x25)
0000: 58 2d 53 71 75 69 64 2d 45 72 72 6f 72 3a 20 45 X-Squid-Error: E
0010: 52 52 5f 43 4f 4e 4e 45 43 54 5f 46 41 49 4c 20 RR_CONNECT_FAIL
0020: 31 30 31 0d 0a                                  101..
.
.
== Info: Received HTTP code 503 from proxy after CONNECT
== Info: Connection #0 to host 127.0.0.1 left intact
curl: (56) Received HTTP code 503 from proxy after CONNECT

--
Thomas Karches
NCSU OIT CSI - Systems Specialist
M.E Student - Technology Education
Hillsborough 319 / 919.515.5508



_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problems with squid 3.1 to 3.3 upgrade

Alex Rousskov
On 8/9/19 1:37 PM, Tom Karches wrote:
> On Fri, Aug 9, 2019 at 11:38 AM Alex Rousskov wrote:

> Ok, here is the info from the real trace. First time with #dns_v4_first
> on  commented out, 2nd time "dns_v4_ first on" is active. Difference is
> with no "dns_v4_first on" directive, I get a RR_CONNECT_FAIL 111. When
> active, I get a RR_CONNECT_FAIL 101.

BTW, it may be easier for you to read --trace--ascii output.

Both are ERR_CONNECT_FAIL errors ("connection reset by peer" and
"connection refused"). Your Squid cannot connect to where it needs to
connect in order to establish a TCP tunnel. It could be a Squid
misconfiguration, a routing problem, insufficient capabilities, and many
other things.

I suggest checking cache.log for WARNINGs and ERRORs. After arriving at
a clean cache.log, I would use a packet capture (or similar) to see
where Squid is trying to connect (and which local address it is
connecting from). That information may be enough to figure out why Squid
cannot connect successfully.

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problems with squid 3.1 to 3.3 upgrade

Tom Karches


On Fri, Aug 9, 2019 at 2:37 PM Alex Rousskov <[hidden email]> wrote:
On 8/9/19 1:37 PM, Tom Karches wrote:
> On Fri, Aug 9, 2019 at 11:38 AM Alex Rousskov wrote:

> Ok, here is the info from the real trace. First time with #dns_v4_first
> on  commented out, 2nd time "dns_v4_ first on" is active. Difference is
> with no "dns_v4_first on" directive, I get a RR_CONNECT_FAIL 111. When
> active, I get a RR_CONNECT_FAIL 101.

BTW, it may be easier for you to read --trace--ascii output.

I didn't see anything additional using the ascii option, though it is easier to read
 

Both are ERR_CONNECT_FAIL errors ("connection reset by peer" and
"connection refused"). Your Squid cannot connect to where it needs to
connect in order to establish a TCP tunnel. It could be a Squid
misconfiguration, a routing problem, insufficient capabilities, and many
other things.

I suggest checking cache.log for WARNINGs and ERRORs. After arriving at
a clean cache.log, I would use a packet capture (or similar) to see
where Squid is trying to connect (and which local address it is
connecting from). That information may be enough to figure out why Squid
cannot connect successfully.


This is what I am seeing from cache.log when I attempt the proxy :

 

2019/08/09 16:19:08.127 kid1| 33,2| client_side.cc(817) swanSong: local=127.0.0.1:3128 remote=127.0.0.1:33428 flags=1

2019/08/09 16:19:10.051 kid1| 33,2| client_side.cc(817) swanSong: local=152.7.114.135:3128 remote=10.50.54.21:43198 flags=1

Right now my debug is set to ALL,1 33,2. Is there a better set of options to provide me more visibility of what might be wrong?

Here is our config file, in case that helps. If it's something obvious I'm not seeing. We have some whitelists, but I am running with those turned off until this is working so I won't include them here. Thanks for the help.

Tom

# squid config file - 2019-08-09
# Timeouts
connect_timeout 2 minutes  # For CDWG Vendor
debug_options ALL,1 33,2

dns_v4_first on

acl SSL_ports port 443
acl SSL_ports port 1443     # b2b-test.apple.com:1443
acl SSL_ports port 3079     # bci.stapleslink.com special port
acl SSL_ports port 4443     # pascal.apple.com:4443
acl SSL_ports port 993      # IMAP from Stat application to Gmail
acl SSL_ports port 22       # Allow SSH and SFTP to proxy/connect
acl SSL_ports port 8443     # redhat cap port


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 Safe_ports port 5228        # google services
acl Safe_ports port 1935        # cam steamer port
acl Safe_ports port 8443        # redhat cap port
acl CONNECT method CONNECT

#
# Recommended minimum Access Permission configuration:
#
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager

# Deny requests to certain unsafe ports
http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
#http_access deny to_localhost

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#

# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localnet
http_access allow localhost

# And finally deny all other access to this proxy
http_access deny all

icp_access deny all

# Squid normally listens to port 3128
http_port 3128

# Uncomment and adjust the following to add a disk cache directory.
#cache_dir ufs /var/spool/squid 2048 16 256

# Default configuration value for cache_mem
#cache_mem 256 MB
cache deny all

# Leave coredumps in the first cache dir
coredump_dir /var/spool/squid

# Add any of your own refresh_pattern entries above these.
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

max_filedescriptors 65000


--
Thomas Karches
NCSU OIT CSI - Systems Specialist
M.E Student - Technology Education
Hillsborough 319 / 919.515.5508



_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problems with squid 3.1 to 3.3 upgrade

Amos Jeffries
Administrator
On 10/08/19 8:32 am, Tom Karches wrote:

>
>
> On Fri, Aug 9, 2019 at 2:37 PM Alex Rousskov wrote:
>
>     On 8/9/19 1:37 PM, Tom Karches wrote:
>     > On Fri, Aug 9, 2019 at 11:38 AM Alex Rousskov wrote:
>
>     > Ok, here is the info from the real trace. First time with
>     #dns_v4_first
>     > on  commented out, 2nd time "dns_v4_ first on" is active.
>     Difference is
>     > with no "dns_v4_first on" directive, I get a RR_CONNECT_FAIL 111. When
>     > active, I get a RR_CONNECT_FAIL 101.
>
>     BTW, it may be easier for you to read --trace--ascii output.
>
>
> I didn't see anything additional using the ascii option, though it is
> easier to read
>  
>
>
>     Both are ERR_CONNECT_FAIL errors ("connection reset by peer" and
>     "connection refused"). Your Squid cannot connect to where it needs to
>     connect in order to establish a TCP tunnel. It could be a Squid
>     misconfiguration, a routing problem, insufficient capabilities, and many
>     other things.
>
>     I suggest checking cache.log for WARNINGs and ERRORs. After arriving at
>     a clean cache.log, I would use a packet capture (or similar) to see
>     where Squid is trying to connect (and which local address it is
>     connecting from). That information may be enough to figure out why Squid
>     cannot connect successfully.
>
>
> This is what I am seeing from cache.log when I attempt the proxy :
>
>  
>
> 2019/08/09 16:19:08.127 kid1| 33,2| client_side.cc(817) swanSong:
> local=127.0.0.1:3128 <http://127.0.0.1:3128> remote=127.0.0.1:33428
> <http://127.0.0.1:33428> flags=1
>
> 2019/08/09 16:19:10.051 kid1| 33,2| client_side.cc(817) swanSong:
> local=152.7.114.135:3128 <http://152.7.114.135:3128>
> remote=10.50.54.21:43198 <http://10.50.54.21:43198> flags=1
>
> Right now my debug is set to ALL,1 33,2. Is there a better set of
> options to provide me more visibility of what might be wrong?
>

11,2 will show the HTTP message headers.

44,2 will show the servers Squid is finding as possible destinations for
the request/tunnel.

5,6 should show the TCP connection attempts activity by Squid.


If it is not clear from that, those should give you hints about lines to
look for (skip to) for searching a much larger ALL,6 trace.


> Here is our config file, in case that helps. If it's something obvious
> I'm not seeing. We have some whitelists, but I am running with those
> turned off until this is working so I won't include them here. Thanks
> for the help.
>


Few bits of polish. But nothing visible there to indicate what your
problem might be.

I think it is probably a firewall or routing problem for the traffic
leaving the proxy machine.


> Tom
>
> # squid config file - 2019-08-09
> # Timeouts
> connect_timeout 2 minutes  # For CDWG Vendor
> debug_options ALL,1 33,2
>
> dns_v4_first on
>
> acl SSL_ports port 443
> acl SSL_ports port 1443     # b2b-test.apple.com:1443
> <http://b2b-test.apple.com:1443>
> acl SSL_ports port 3079     # bci.stapleslink.com
> <http://bci.stapleslink.com> special port
> acl SSL_ports port 4443     # pascal.apple.com:4443
> <http://pascal.apple.com:4443>
> acl SSL_ports port 993      # IMAP from Stat application to Gmail
> acl SSL_ports port 22       # Allow SSH and SFTP to proxy/connect
> acl SSL_ports port 8443     # redhat cap port
>
>
> 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

The ports below are all included in the 1024-65535 range. No need to
list them explicitly here.


> acl Safe_ports port 5228        # google services
> acl Safe_ports port 1935        # cam steamer port
> acl Safe_ports port 8443        # redhat cap port
> acl CONNECT method CONNECT
>
> #
> # Recommended minimum Access Permission configuration:
> #
> # Only allow cachemgr access from localhost
> http_access allow manager localhost
> http_access deny manager
>

Latest Squid recommendation is to have these manager lines after the
CONNECT !SSL_ports line.


> # Deny requests to certain unsafe ports
> http_access deny !Safe_ports
>
> # Deny CONNECT to other than secure SSL ports
> http_access deny CONNECT !SSL_ports
>
> # We strongly recommend the following be uncommented to protect innocent
> # web applications running on the proxy server who think the only
> # one who can access services on "localhost" is a local user
> #http_access deny to_localhost
>
> #
> # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
> #
>
> # Example rule allowing access from your local networks.
> # Adapt localnet in the ACL section to list your (internal) IP networks
> # from where browsing should be allowed
> http_access allow localnet
> http_access allow localhost
>
> # And finally deny all other access to this proxy
> http_access deny all
>
> icp_access deny all

ICP is off by default in modern Squid. No need for the above deny.

>
> # Squid normally listens to port 3128
> http_port 3128
>
> # Uncomment and adjust the following to add a disk cache directory.
> #cache_dir ufs /var/spool/squid 2048 16 256
>
> # Default configuration value for cache_mem
> #cache_mem 256 MB
> cache deny all
>
> # Leave coredumps in the first cache dir
> coredump_dir /var/spool/squid
>
> # Add any of your own refresh_pattern entries above these.
> 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
>
> max_filedescriptors 65000
>
> --
> Thomas Karches
> NCSU OIT CSI - Systems Specialist
> M.E Student - Technology Education
> Hillsborough 319 / 919.515.5508
>
>
>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problems with squid 3.1 to 3.3 upgrade

Alex Rousskov
In reply to this post by Tom Karches
On 8/9/19 4:32 PM, Tom Karches wrote:
> Right now my debug is set to ALL,1 33,2. Is there a better set of
> options to provide me more visibility of what might be wrong?

In theory, yes: You can increase verbosity levels to see exactly what is
going on. However, most people get lost in the debugging noise. FWIW, I
do not recommend using cache.log above ALL,1 (the default) for triaging
connectivity problems like yours by Squid newbies like you. Most likely,
the connectivity problem is outside Squid and can be seen/reproduced
outside Squid.

I would use Wireshark, tcpdump, or a similar packet-level tool to figure
out where Squid is trying to connect and from what address Squid is
trying to connect. If you are not familiar with those basic tools, any
capable local sysadmin can help you get started -- no Squid knowledge is
needed!

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problems with squid 3.1 to 3.3 upgrade

Tom Karches
I thought that this was being caused by a firewall because I was seeing (requests go out, but blocked coming back) so I had the ports over 1024 opened :

No.     Time           Source                Destination           Protocol Length Info
    156 16.493132      152.7.114.135         140.211.169.196       TCP      74     50994 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=2876033516 TSecr=0 WS=128
    157 16.493333      140.211.169.196       152.7.114.135         TCP      60     443 → 50994 [RST, ACK] Seq=1 Ack=1 Win=29200 Len=0
    158 16.493440      152.7.114.135         152.19.134.198        TCP      74     45744 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=2876033516 TSecr=0 WS=128
    159 16.493626      152.19.134.198        152.7.114.135         TCP      60     443 → 45744 [RST, ACK] Seq=1 Ack=1 Win=29200 Len=0

but now it is still failing and I am also seeing this in access.log. It looks like connections are going out but not coming back :

2019/08/19 13:17:38.576 kid1| 33,2| client_side.cc(817) swanSong: local=152.7.114.135:3128 remote=10.50.54.22:57230 flags=1
2019/08/19 13:17:52.050 kid1| 33,2| client_side.cc(817) swanSong: local=152.7.114.135:3128 remote=10.50.54.21:48557 flags=1
2019/08/19 13:17:53.608 kid1| 33,2| client_side.cc(817) swanSong: local=152.7.114.135:3128 remote=10.50.54.22:57330 flags=1
2019/08/19 13:18:07.053 kid1| 33,2| client_side.cc(817) swanSong: local=152.7.114.135:3128 remote=10.50.54.21:48651 flags=1
2019/08/19 13:18:08.725 kid1| 33,2| client_side.cc(817) swanSong: local=152.7.114.135:3128 remote=10.50.54.22:57426 flags=12


Do you see anything else relevant in here?

Thanks,
Tom

On Sat, Aug 10, 2019 at 1:57 PM Alex Rousskov <[hidden email]> wrote:
On 8/9/19 4:32 PM, Tom Karches wrote:
> Right now my debug is set to ALL,1 33,2. Is there a better set of
> options to provide me more visibility of what might be wrong?

In theory, yes: You can increase verbosity levels to see exactly what is
going on. However, most people get lost in the debugging noise. FWIW, I
do not recommend using cache.log above ALL,1 (the default) for triaging
connectivity problems like yours by Squid newbies like you. Most likely,
the connectivity problem is outside Squid and can be seen/reproduced
outside Squid.

I would use Wireshark, tcpdump, or a similar packet-level tool to figure
out where Squid is trying to connect and from what address Squid is
trying to connect. If you are not familiar with those basic tools, any
capable local sysadmin can help you get started -- no Squid knowledge is
needed!

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users


--
Thomas Karches
NCSU OIT CSI - Systems Specialist
M.E Student - Technology Education
Hillsborough 319 / 919.515.5508



_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problems with squid 3.1 to 3.3 upgrade

Alex Rousskov
On 8/19/19 1:58 PM, Tom Karches wrote:

> It looks like connections are going out but not coming back :
>
> 2019/08/19 13:17:38.576 kid1| 33,2| client_side.cc(817) swanSong:
> local=152.7.114.135:3128 remote=10.50.54.22:57230 flags=1
> 2019/08/19 13:17:52.050 kid1| 33,2| client_side.cc(817) swanSong:
> local=152.7.114.135:3128 remote=10.50.54.21:48557 flags=1
...
> 2019/08/19 13:18:08.725 kid1| 33,2| client_side.cc(817) swanSong:
> local=152.7.114.135:3128 remote=10.50.54.22:57426 flags=12

> Do you see anything else relevant in here?

No, I do not. These cache.log records are normal/benign AFAICT. See my
earlier warning about using non-default cache.log debugging in your
specific case.

Alex.


> On Sat, Aug 10, 2019 at 1:57 PM Alex Rousskov wrote:
>
>     On 8/9/19 4:32 PM, Tom Karches wrote:
>     > Right now my debug is set to ALL,1 33,2. Is there a better set of
>     > options to provide me more visibility of what might be wrong?
>
>     In theory, yes: You can increase verbosity levels to see exactly what is
>     going on. However, most people get lost in the debugging noise. FWIW, I
>     do not recommend using cache.log above ALL,1 (the default) for triaging
>     connectivity problems like yours by Squid newbies like you. Most likely,
>     the connectivity problem is outside Squid and can be seen/reproduced
>     outside Squid.
>
>     I would use Wireshark, tcpdump, or a similar packet-level tool to figure
>     out where Squid is trying to connect and from what address Squid is
>     trying to connect. If you are not familiar with those basic tools, any
>     capable local sysadmin can help you get started -- no Squid knowledge is
>     needed!
>
>     Alex.
>     _______________________________________________
>     squid-users mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     http://lists.squid-cache.org/listinfo/squid-users
>
>
>
> --
> Thomas Karches
> NCSU OIT CSI - Systems Specialist
> M.E Student - Technology Education
> Hillsborough 319 / 919.515.5508
>
>
>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users