[squid-users] no fallback to ipv4 if ipv6 remote address is non-functional

[Amos Jeffries]

On 15/06/2015 2:42 a.m., Brian J. Murrell wrote:
> On Sat, 2015-06-13 at 21:49 +1200, Amos Jeffries wrote:
>> On 12/06/2015 11:48 p.m., Brian J. Murrell wrote:
>>> On Fri, 2015-06-12 at 10:13 +1200, Amos Jeffries wrote:
>>>>
>>>> see <http://readlist.com/lists/squid-cache.org/squid-users/11/58405.html>
>>>
>>> Of course, I did see the rest of the messages in the thread.  I'm not
>>> sure what I'm supposed to be seeing in that particular message though
>>> other than 3.4.3 worked for the person reporting that.
>>>
>>> So maybe I have a different problem?
>>
>> On the side of "probably".
>>
>>>
>>>> - You speak of a 
> 
> 
>> If I assume it got as far as trying to connect it looks like it took
>> 10sec waiting for some response.
> 
> Indeed.  That's what it looks like to me.
> 
>> So,
>> * can all of the DNS servers in your /etc/resolv.conf return results for
>> irc.bcwireless.net?
> 
> Yes.  There is only one DNS server in my resolv.conf and that's the one
> that runs on the same host as squid:
> 
> $  dig irc.bcwireless.net any
> 
> ; <<>> DiG 9.8.1-P1 <<>> irc.bcwireless.net any
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52707
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;irc.bcwireless.net.            IN      ANY
> 
> ;; ANSWER SECTION:
> irc.bcwireless.net.     300     IN      AAAA    fcaa:8ef7:51b9:8f04:58f1:7364:e16e:fe2f
> irc.bcwireless.net.     300     IN      A       198.27.79.54
> 
> ;; AUTHORITY SECTION:
> bcwireless.net.         162451  IN      NS      kim.ns.cloudflare.com.
> bcwireless.net.         162451  IN      NS      kip.ns.cloudflare.com.
> 
> ;; Query time: 52 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Sun Jun 14 10:39:21 2015
> ;; MSG SIZE  rcvd: 133
> 
>> Probably these:
>>   debug_options ALL,1 11,2 44,2 5,5 17,5
> 
> I sent you a private e-mail with the log since it's long and as much as
> I think I might have sanitized it, I don't want to unnecessarily leak
> sensitive info.

Sure. Thank you.


1)
I have confirmed my suspicion that your IPv6 routing is a bit broken.

The IPv6 address is in a private IP range fc00::/7. Which is the IPv6
equivalent of RFC1918 10.0.0.0/8 or 182.168.0.0/16. When your Squid
contacts it nothing at all happens within 10 seconds.

What should be happening is that when Squid tries to contact a network
range which is not your own LAN fd31:aeb1:48df::/48 sub-net. The routing
system in your Squid machine responds with a "network unavailable"
within nanoseconds. This signal which is not appearing is what Squid
depends on to to do the failover.

 Are you blocking ICMP? if so remove that. ICMP is not optional even in
IPv4.

 Do you have an entry in the routing table for fc00::/7 or /8 ? in
particular one larger than the fd31::/16 network your machines are
talking on. If so, narrow it down to only your actual LAN range.


2)
Squid should still be attemoting the IPv4 address though. Instead its
just responding with an error and closing.doing failover though, but the
CONNECT handling is for some reason seems to be generating an error page
and deliverign it to teh celint iinstead of trying the IPv4.


I also see you have Squid-3.4.3. Can you try an upgrade to 3.5.5 ? there
have been some deep code stability fixes in this area since your version.

If the problem persists after that upgrade. Please redo with 26,5 in the
debug list.

Also, check your proxy connect_timeout is shorter than forward_timeout.
The connect timout affects these individual connections, forward_timeout
needs to allow mulitiple (25?) of them for failover to have a chance in
lost packet situations like this.

Amos