[squid-users] Squid do not reply

[Amos Jeffries]

On 5/10/21 2:37 pm, Alex Rousskov wrote:
> On 10/4/21 5:18 PM, Henning Svane wrote:
> 
> 
>> I search more on the problem and it shows that Squid as default only use IPv6
> 
> I really doubt that. Your access.log records seem to confirm my belief
> that your Squid was listening on an IPv4 address (at least) -- Squid
> would not see (and log) requests from IPv4 clients like 10.40.61.11 if
> it were listening on IPv6 only.
> 
> Unfortunately, the exact meaning of "::" and "[::]" addresses (and even
> "tcp6 ... ::" lines in netstat!) depends on the environment. Lots of
> folks (mis)interpret those symbols as "any IPv6 address". That
> interpretation is correct in some environments and wrong in many others.

No. "any IPv6 address" is the literal definition of "::".

The situation is that some (dual-stack, hybrid-stack) environments treat 
IPv4 as a part of IPv6 and others (split-stack) do not. Squid has been 
well tested in this area. It correctly opens the appropriate ports for 
the stack type.
  Ubuntu is dual-stack so the IPv6 port ("[::]:3128" is the correct one 
to open and use for both IPv4 and IPv6 clients.


> Here is one detailed answer that enumerates a few cases, including what
> looks like yours (except for an sshd instead of Squid):
> https://serverfault.com/a/39561
> 

That documentation is about Windows Vista which have a split-stack where 
IPv4 needs a dedicated IPv4-only port opened. As I mentioned above, 
Squid is well tested for these and will properly open both IPv6 and IPv4 
ports on split-stack OS.


> You can, of course, verify whether Squid listens on an IPv4 address by
> connecting to port 3128 on that IPv4 address using telnet or another
> program.
> 
> 
> Please note that Squid listening address has nothing to do with Squid
> outgoing address. That is why I suggested that you disable
> (misconfigured?) IPv6 in your environment so that Squid does not try to
> forward a request it received via IPv4 using a Squid-server connection
> with IPv6 addresses.
> 

To clarify what Alex is suggesting is one of these;

Either,

   Add firewall rules that block public IPv6 traffic trying to be sent 
to your ISP. That means ip6tables rules to deny all traffic (not 
iptables which is IPv4-only).
  - this way Squid will attempt to connect to those IPv6 servers, but 
when rejected should failover to IPv4 ones. If you get ISP IPv6 
connectivity you just need to change firewall rules and Squid starts 
working with those.


Or,

  Configure the OS network interface not to allocate IPv6 addresses even 
for localhost.
  - this way Squid will detect the lack of IPv6 functionality on the 
machine and disable all use of IPv6 - incoming, internal uses, and 
outgoing traffic. If you get ISP IPv6 connectivity you need to change 
both the OS interface config and then restart Squid to pickup the change 
of capability.


However. Before you try those it would be helpful to test whether IPv4 
is actually going to work to those servers. The issue may not be IP 
related at all.

I suggest adding "dns_v4_first on" to squid.conf. Squid-4 and older will 
first try connecting to IPv4 servers, only trying IPv6 ones if those 
fail. You will then only see IPv6 addresses for servers which are not 
available over IPv4. (Squid-5+ work differently and do not provide this 
option).


One possible bug you may be encountering is a known APT issue. When APT 
hands the proxy a URL with raw-IPv6 it uses the 5xx/4xx status response 
as final. It does not try to reach a different IP address of the server 
it was connecting to. There is nothing we can do in Squid to fix that. 
Efforts to get it fixed in APT have so far not been successful.


Finally, please make sure that ICMP and ICMPv6 are functional in your 
environment and do anything you can to ensure your ISP has it functional 
as well. Yes there are *some* packet types that need to be blocked for 
security, but the rest MUST NOT.

Squid and many other software rely on ICMP control signals indicating 
that connections have failed so they can re-try using an different IP 
address. This is important even for retry with two IPv4 addresses. Your 
router or ISPs router should be delivering those signals to Squid, 
otherwise the connection retry may not even be attempted.


Amos