The complaint
"The site opens fine on my laptop, but my phone says This site can't be reached." The server looks healthy: no errors in the web server logs, normal CPU, nothing blocked at the firewall. Reload a few times and the page sometimes loads.
Symptoms
All of these together point at this bug:
- Browsers show ERR_CONNECTION_RESET, ERR_CONNECTION_TIMED_OUT, ERR_CONNECTION_ABORTED or "Check your internet connection", intermittently.
- Phones notice it first; desktops seem fine.
- The web server logs nothing for the failed attempts, because the request never gets that far.
- curl or a TLS 1.2 test from your own network always works.
- CDN and DDoS dashboards show no drops.
- The server runs Windows Server with Receive Segment Coalescing (RSC) enabled on its network card.
What is actually going on
- The hello got bigger
Chrome, Edge and Firefox now add a post-quantum key exchange (X25519MLKEM768) to every TLS 1.3 handshake. That adds over a kilobyte to the ClientHello, which no longer fits in one TCP packet and arrives as two segments.
- The card merges them and gets one field wrong
RSC lets the network card combine back-to-back segments before Windows sees them. In the environment we observed (NVIDIA/Mellanox ConnectX-4 Lx, WinOF-2 driver 2.42) the merged segment arrived with the top bit of its TCP timestamp cleared.
- Windows throws the rest away
TCP's PAWS check discards segments whose timestamp looks older than the last one accepted. With the top bit flipped, the second half of the ClientHello looks like it is from the past and is dropped on every retransmit. The handshake never completes.
- Why only about half the time
Clients start TCP timestamps at a random value, so the top bit is set on about half of all connections. Those are the ones that fail.
- Why it looks like a phone problem
It is not really a phone bug. Desktops tend to reuse an open connection, while phones open fresh ones constantly as radios sleep and networks switch. Older clients send a hello small enough to fit in one packet.
How to confirm it in two minutes
From a Linux machine outside your network with OpenSSL 3.5 or newer, connect several times with a large key share and several times with a small one: openssl s_client -connect YOUR_IP:443 -tls1_3 -groups X25519MLKEM768, then the same with -groups x25519.
If the first fails some of the time and the second never fails, this is your bug. A packet capture on the server shows the second segment dropped, and the first segment's timestamp exactly 2^31 away from the client's.
Fix 1: on the server
Disable RSC in Windows. It takes effect immediately without resetting the adapter: netsh int tcp set global rsc=disabled. Also check your NIC vendor for a newer driver or firmware.
In our tests, phone-style handshakes went from failing about half the time to 20 out of 20 succeeding.
Fix 2: at the network edge (what we did)
One server is easy; finding every affected server in a datacentre is not. So our edge routers now remove the TCP timestamp option from incoming SYN packets. A connection that starts without timestamps never uses them, so there is nothing for the card to corrupt and nothing for PAWS to drop.
On a Linux router with nftables the whole fix is one rule in a forward chain: tcp flags syn / syn,ack,rst tcp option timestamp exists reset tcp option timestamp.
- Strip SYNs only, never SYN-ACKs. If traffic is asymmetric and only the reply were stripped, the two ends would disagree about timestamps, which is worse than the original bug.
- The cost is small: you give up the timestamp option's finer round-trip measurement and its protection for very fast single flows. On a busy edge router the CPU cost was too small to measure.
The takeaway
When some users cannot connect and every log is clean, test the way your users connect: a modern browser, a fresh connection, a post-quantum key share. More of the internet now sends handshakes that need two packets, and old offload bugs are coming back into view.
Running on BookMyHost? This fix is already active on our network, so there is nothing for you to change. Questions: support@bookmyhost.com.