[squid-users] Disable IPV6 for certain destinations only?

[Stephen Borrill]

On 31/10/2023 13:08, Stephen Borrill wrote:
> On 18th April 2023 Alex Rousskov wrote:
>> On 4/18/23 03:38, Ralf Hildebrandt wrote:
>>
>>> We're using squid-6, currently v4 only. The use case for us is mostly
>>> our users using our proxy to retrieve full text publications of
>>> several thousand medical journals... via IPv4.
>>>
>>> The publishers "know" our IPv4 range for the proxies and allow us to
>>> download freely. What they don't (yet) know is our ipv6 range.
>>>
>>> Thus arises the need to "fall back" to ipv4 in the unlikely case some
>>> publisher already has ipv6, we connect via ipv6 and suddenly are not
>>> allowed to download the publications.
>>>
>>> Is there an acl for that kind of need?
>>
>> I will rephrase your question to avoid the distraction of "acl":
>>
>>    How can I configure Squid to try IPv4 if IPv6 fails?
>>
>> The answer depends on how IPv6 fails:
>>
>> 1. If IPv6 fails at DNS resolution time (i.e. the DNS resolver does not respond with a usable address to a AAAA query), then Squid will automatically use IPv4 (i.e. the DNS resolver address in an A response). There is nothing to configure.
>>
>> 2. If IPv6 fails at TCP connection establishment time, then Squid will automatically use an IPv4 connection. There is nothing to configure (although there are a few Happy Eyeballs configuration options that you can tune).
>>
>> 3. If IPv6 fails at TLS connection establishment time, then, IIRC, #2 applies unless SslBump is involved. Squid will not retry failed TLS connections that are subject to SslBump IIRC.
>>
>> 4. If IPv6 fails at HTTP request time, then Squid will retry in _some_ cases. See [1] for a long list of conditions; you are probably mostly interested in the last four or five bullets, but keep in mind that the list is of cases where Squid does _not_ re-forward the failed request.
>>
>> [1] https://wiki.squid-cache.org/SquidFaq/InnerWorkings#when-does-squid-re-forward-a-client-request
>>
>> You can also replace your DNS resolver with a custom one (that drops AAAA answers) or, as Adam has suggested, with hard-coded IPv4-only /etc/hosts entries.
> 
> On a machine with no IPv6 connection to the Internet and bearing in mind 2 and 3 above,
> what is going on in the following situation? The host is being resolved to IPv6,
> the connection is failing with (presumably) no route to host and the client's connection is rejected
> with a 503 error:
> 
> 
> peer_select.cc(373) checkAlwaysDirectDone: ALLOWED
> peer_select.cc(379) checkAlwaysDirectDone: direct = DIRECT_YES (always_direct allow)
> peer_select.cc(612) selectMore: CONNECT forcesafesearch.google.com
> peer_select.cc(1102) addSelection: adding HIER_DIRECT#forcesafesearch.google.com
> peer_select.cc(460) resolveSelected: Find IP destination for: forcesafesearch.google.com:443' via forcesafesearch.google.com
> Address.cc(389) lookupHostIP: Given Non-IP 'forcesafesearch.google.com': hostname or servname not provided or not known
> peer_select.cc(1174) handlePath: PeerSelector33640 found conn271011 local=[::] remote=[2001:4860:4802:32::78]:443 HIER_DIRECT flags=1, destination #1 for forcesafesearch.google.com:443
> peer_select.cc(1180) handlePath:   always_direct = ALLOWED
> peer_select.cc(1181) handlePath:    never_direct = DENIED
> peer_select.cc(1182) handlePath:        timedout = 0
> peer_select.cc(479) resolveSelected: PeerSelector33640 found all 1 destinations for forcesafesearch.google.com:443
> peer_select.cc(480) resolveSelected:   always_direct = ALLOWED
> peer_select.cc(481) resolveSelected:    never_direct = DENIED
> peer_select.cc(482) resolveSelected:        timedout = 0
> client_side.cc(1953) clientParseRequests: Not parsing new requests, as this request may need the connection
> FwdState.cc(1568) GetMarkingsToServer: from [::] tos 0 netfilter mark 0
> ConnOpener.cc(42) ConnOpener: will connect to conn271013 local=[::] remote=[2001:4860:4802:32::78]:443 HIER_DIRECT flags=1 with 60 timeout
> comm.cc(372) comm_openex: comm_openex: Attempt open socket for: [::]
> comm.cc(414) comm_openex: comm_openex: Opened socket conn271014 local=[::] remote=[::] FD 1218 flags=1 : family=24, type=1, protocol=6
> fd.cc(168) fd_open: fd_open() FD 1218 forcesafesearch.google.com
> ConnOpener.cc(312) createFd: conn271013 local=[::] remote=[2001:4860:4802:32::78]:443 HIER_DIRECT flags=1 will timeout in 60
> comm.cc(844) _comm_close: start closing FD 1218 by ConnOpener.cc:232
> comm.cc(580) commUnsetFdTimeout: Remove timeout for FD 1218
> HappyConnOpener.cc(522) sendFailure: conn271013 local=[::] remote=[2001:4860:4802:32::78]:443 HIER_DIRECT flags=1 @0
> fd.cc(93) fd_close: fd_close FD 1218 forcesafesearch.google.com
> tunnel.cc(1364) sendError: aborting transaction for HappyConnOpener gave up
> errorpage.cc(751) errorSend: conn271010 local=127.0.0.1:8123 remote=127.0.0.1:56146 FD 1217 flags=1, err=ERR_CONNECT_FAIL

After restarting (not reloading), I get the following and it will work for while before stopping again:

peer_select.cc(1174) handlePath: PeerSelector1666 found conn12948 local=0.0.0.0 remote=216.239.38.120:443 HIER_DIRECT flags=1, destination #1 for forcesafesearch.google.com:443
peer_select.cc(1180) handlePath:   always_direct = ALLOWED
peer_select.cc(1181) handlePath:    never_direct = DENIED
peer_select.cc(1182) handlePath:        timedout = 0
peer_select.cc(1174) handlePath: PeerSelector1666 found conn12949 local=[::] remote=[2001:4860:4802:32::78]:443 HIER_DIRECT flags=1, destination #2 for forcesafesearch.google.com:443
peer_select.cc(1180) handlePath:   always_direct = ALLOWED
peer_select.cc(1181) handlePath:    never_direct = DENIED
peer_select.cc(1182) handlePath:        timedout = 0
peer_select.cc(479) resolveSelected: PeerSelector1666 found all 2 destinations for forcesafesearch.google.com:443

This is a newly occurring problem after upgrade from 4.x to 6.3.

-- 
Stephen