Hub 4 modem mode: regular issues with SSL traffic

[heliosfa]

Hello,

For the past decade or so I have been running a Virgin connection with the hub in modem mode connected to a pfsense firewall. For the most part, my setup has was working fine on the 200 Mb/s service with a Hub 2ac for a fair few years. I upgraded on the 18th of January to the 500 Mb/s service with a Hub 3 and this was also working fine. The problems started on the 26th of January when I was upgraded to Gig1 with a Hub 4 as a Volt benefit.

Since then, I am having a regular issues with SSL traffic to *some* destinations breaking when the Hub 4 is in modem mode. In Firefox, this manifests as the browser hanging on "Performing TLS Handshake" until it times out. In Chrome it hangs on "Establishing Secure Connection".

Some of the problem sites include:

• https://www.bbc.co.uk/news
• https://www.hobbycraft.co.uk
• https://community.virginmedia.com
• https://www.netflix.com

When the problem occurs, I also have issues tunneling traffic (e.g. remote desktop) over SSH. Other websites (e.g. https://old.reddit.com and https://www.speedtest.net ) and anything routed over my Hurricane Electric IPv6 tunnel continue to work absolutely fine. Online game traffic (CS:Go, Tarkov, etc.) also seems to be unaffected. Speed tests continue to report the full expected speed.

Pings to the problem sites continue to work. Even the redirect from news.bbc.co.uk to www.bbc.co.uk/news works, the browser just hangs after the redirect.

Sometimes the problem is transient and resolves itself after a few minutes. Other times it takes a reboot of the Hub 4 to resolve. Rebooting the firewall does not resolve the issue and the issue occurs with other devices (including an alternative router and a straight Windows desktop) in place of the firewall.

Packet captures show that the traffic is correctly leaving the firewall's WAN interface.

Also, the admin interface for the Hub 4 at 192.168.100.1 stops responding within an hour or two of rebooting the hub. Ping to the hub also become sporadic with only one in every ten or 20 pings eliciting a response. It takes a reboot of the Hub 4 to regain access to the admin interface.

The issues (including the admin interface one) do not occur if I introduce a double-NAT scenario with the Hub 4 in "normal" mode with the firewall in the DMZ. Obviously this is not an ideal long-term solution.

Has anyone else come across this? is it a "feature" of the Hub 4 or have I just got a bad one?

I am dreading trying to explain this to support over the phone as it is an intermittent issue and involves modem mode.

[heliosfa]

---

@BaldrickBravo wrote:

I do like a good graph.
And that has to be the first time I've seen MTU size plotted on a graph, so that's doubly nice.

Good luck getting the problem resolved.

---

MTU is not normally so... variable, so it is not usually something that you would need to graph.

Can anyone tell when I enabled modem mode last night?

There were no other changes to the network - it was a case of going from router mode (with the firewall getting a private IP) to modem mode after the hub restarted.

Thanks, I am going to leave it for a couple of days then call them again.

[heliosfa]

Just an update from my latest phone contact with Virgin. The tech could not see any issues, all their diagnostics showed no problems and all he has done is opened a trouble ticket and the connection will apparently be monitored for 24 hours. I don't expect this monitoring to show anything as the tech's tests didn't pick up anything.

Latest graph for reference, tonight is being particularly bad...

[jem101]

@heliosfa it won't be monitored for 24 hours, that's just a standard fob off to get you off the line - and even if it is (hint: actually it isn't) they will just claim that it has stayed on line for this time so all is well.

The hub needs to have a completely accidental encounter with a club hammer, requiring it being replacing.

[Tudor]

“The hub needs to have a completely accidental encounter with a club hammer, requiring it being replacing.”
Where I used to work someone came up with a solution, they put their bad equipment sealed into two plastic bags and put in in the microwave. Never tried it, but it should work.

[heliosfa]

---

@jem101 wrote:

@heliosfa it won't be monitored for 24 hours, that's just a standard fob off to get you off the line - and even if it is (hint: actually it isn't) they will just claim that it has stayed on line for this time so all is well.

---

Maybe that is the case. I called again today as things are bad and apparently the monitoring showed nothing.

While I appreciate that the techs are following a script and that this problem is more out of the ordinary than they are used to, it gets rather frustrating when they ask you to do the same thing again and again on each call.

Also, is it me or does their script only recognise "slow service" and "no servcie"? They don't seem to have options for strange occurences...

Latest development is that the person I spoke to today has raised a(nother?) ticket and I should receive a call back from the technical team in four to six hours. Bets on it happening?

Latest plot for people to laugh at my misfortune:

---

@jem101 wrote:

The hub needs to have a completely accidental encounter with a club hammer, requiring it being replacing.

---

intentional damage to kit is not something I am into. I have no idea what is wrong with this particular poor hub, but it probably just wants some tender loving care rather than being turned into more eWaste...

[heliosfa]

And today has reminded me yet again why I hate calling virgin media.

Part 1: I call 150 as I never received the call back from the "technical team" that I was promised. End up having to explain the issue yet again and have them want to run through the same series of diagnostics and resets. I put my foot down and the tech says she needs to pop me on hold for a minute to check something. Ends up transferring me without notice, but to a wrong number...

Part 2: I call back. End up speaking to one of the UK call centres for the first time in this entire saga and actually got some more information. After checking with another team on chat, apparently there are two things going on at the moment: There is a utilisation fault in my area (nothing new, but this is the first I have heard about this one with an estimated fix date of the 22nd...) but that doesn't explain my issue. There is also apparently an issue with the Hub 4 in modem mode at the moment and they have been having a few calls from people with issues after upgrading. No ETA on the fix...

I am expecting a call back on the 23rd to see where we go from here.

[legacy1]

Have you done a reset on the hub then back to modem mode?

Just to recap can you receive MTU 1500 fine but its the sending of 1500 MTU that the hub stops forwarding at that MTU?

Its like the hub is doing per-session MTU limiting in modem mode which it shouldn't and in router mode if thats the case ICMP with Destination unreachable (Fragmentation needed) with the lower MTU would be sent to the device but in modem mode how could it send that to you? but why is it being triggered in the first place...😕   

[heliosfa]

---

@legacy1 wrote:

Have you done a reset on the hub then back to modem mode?

---

I have done a factory reset and left it in router mode for a while before going into modem mode. It is fine in router mode, problematic in modem mode.

I have also done a factory reset and put it straight into modem mode. Same problem

---

@legacy1 wrote:

Just to recap can you receive MTU 1500 fine but its the sending of 1500 MTU that the hub stops forwarding at that MTU?

---

It depends. When I was digging into which way the problem was, initially it was inbound 1500-byte packets that were being dropped.

I went away for 20 minutes, came back and tested again. This time it was outbound packets that were being dropped.

In other words, it varys over time

---

@legacy1 wrote:

Its like the hub is doing per-session MTU limiting in modem mode which it shouldn't and in router mode if thats the case ICMP with Destination unreachable (Fragmentation needed) with the lower MTU would be sent to the device but in modem mode how could it send that to you? but why is it being triggered in the first place...😕   

---

We were not seeing any change in MTU in router mode - the pings being used to monitor are Do Not Fragment and anything short of a response is a failure.

As for how it would send Frag Needed in modem mode, the same way it (should be) responding to ping and the web interface when it is in modem mode would make sense. But then, MTU shouldn't be varying and should be 1500 on a DOCSIS connection (or possible 2000 on Docsis 3.1)

[legacy1]

Fragments don't have to happen but in that ICMP is a next hop MTU that the end receiving it lowers the packet size are you seeing these in router mode?

So your testing remotely to your VM IP?

[heliosfa]

---

@legacy1 wrote:
Fragments don't have to happen but in that ICMP is a next hop MTU that the end receiving it lowers the packet size are you seeing these in router mode?

So your testing remotely to your VM IP?

---

I am NOT seeing Fragmentation needed packets in router mode. Also, I am sending 1500-byte packets with DF set. If the MTU was changing in router mode, these would fail in the same way whether I was getting Fragmentation needed or not.

I have done some remote testing from my home Virgin connection to another.