Intermittent connection issues loading/changing site- secure connection failed/site can't be reached

[EDIflyer]

Is anyone else occasionally getting a 'connection down' error from Chrome (or 'Secure Connection Failed' from Firefox) when changing page - if I hit refresh it works fine. At first I wondered if it was the site I was using but have noticed it on multiple different major websites over the past couple of months and not noticed it from other locations where I don't use Three Broadband so does seem to be related to the router/connection (this is via wired Ethernet too, so not a WiFi problem).  I've tried changing DNS server in case that helps but no difference.

It mainly seems to happen when trying to first load a site or (annoyingly) at checkout when a different site is being loaded as part of the checkout process.  It certainly doesn't happen everytime but does happen with reasonable frequency.  I've also noticed I often get it when trying to pull/push from/to Github too and have to do so a number of times for it to work (browsing the Github website works fine).

I'm using a NR5103E with Firmware Version V1.00(ACBJ.0)b14 - I tried rebooting it but to no effect.

[Midnight54]

Like @EDIflyer my net also went down last night for approx 10mins, around 1am ish.  Only just had time to test it, hoping it was maybe resolved,but nope same issue here, sites like duckduckgo fairly frequently failing, debrid files failing to complete the download at the very end every time etc

[EDIflyer]

Oh damn, sorry to hear that - interesting you had an outage though too.

[wgen]

Sure, I will be down to participate. Issues are still prevalent on my connection.

[JonathanB]

Hi everyone,

@EDIflyer mentioned they haven't been seeing the same error recently, but I don't want to write this off as resolved, particularly when others have mentioned this issue coming and going in the past.

We'd like to do some live tracing against affected connections. Is anyone interested in participating in this?

Thanks,
Jonathan

[thelostlambda]

Hi Jonathan!

I've been away from the UK since December or so, but since coming back last week I've been suffering this problem quite badly... I'd love to participate / provide helpful information to get this issue resolved ASAP!

Thanks a ton!

[bytespider]

Id be happy to help.

[toaster]

Hi @JonathanB 

I'm still having this error across multiple sites. I'd be happy to help with some live tracing.

[JonathanB]

Thanks @toaster,

I've dropped you a PM now to get a couple of details to set this up

To view your private messages on the community, click on your avatar image in the top right of any community page, then "Messages".

Thanks,
Jonathan

[EDIflyer]

Although not glad you're having issues @toaster I'm equally glad you are if you know what I mean! Weird that it stopped for me today but great if you could help with live tracing.

[toaster]

I haven't had any communication from Three about sending the packet captures from my previous investigation, but I've carried on digging... and I think I've found a couple more nuggets of info.

I tried seeing what the failure rate was for some of the sites that have been listed so far in this thread. Typically I get around 0.5% - 2% failure rate. Then I checked https://royalmail.com - I'm getting a ~20%-25% failure rate which is interesting.

What's also interesting is that https://www.royalmail.com hasn't failed yet so has a 0% failure rate.

What do www.royalmail.com and royalmail.com do differently?

The most obvious thing is that www.royalmail.com looks like it's fronted by Akami. My client ends up with a TLS  1.3 connection. royalmail.com doesn't look like it's fronted by Akami and my client ends up with a TLS 1.2 connection.

I ran curl (and openssl s_client) with the option to specify the ciphers against royalmail.com and www.royalmail.com with a small variety of specified ciphers which had no noticeable difference to the failure rates.

At the moment, I don't think the TLS connection is a factor. Looking back at the packet capture from my server in the previous tests, the ACK from the 3-way handshake and the initial FIN-ACK appear to be sent at the same time - well before the TLS negotiation even begins and before any intermediary would be able to see the supported ciphers/certs/etc from the server.

I think the decision to close the connection is made during the 3-way handshake. I don't know if there's much more that I can dig into as I can't see from the client side what would be triggering an intermediary to close the connection so early because all the requests from a client to initiate a connection to a server will be very similar. There's no real difference in the SYN packets sent to royalmail.com vs www.royalmail.com from the same client.  I can't reliably see the SYN-ACK responses from the server because something in the middle is rewriting things.

I'd be interested in any thoughts on what to look at next and if anyone else sees the same difference between royalmail.com and www.royalmail.com