Bizarre HTTPS Connection Issue: Every Other New Connection Times Out (TP-Link Omada ER8411 + KPN)
I Used ChatGPT to write this post because English is not my native language and its too technical to write a good post my self.
The Problem
I'm experiencing a strange intermittent HTTPS connection failure that only affects new TCP connections on my home network. The pattern is perfectly consistent:
- Attempt 1: ✅ Success (HTTP 302/200)
- Attempt 2: ❌ Timeout
- Attempt 3: ✅ Success
- Attempt 4: ❌ Timeout
- And so on...
What makes this REALLY weird:
- ✅ Works perfectly on 5G/mobile data
- ✅ Works perfectly when reusing TCP connections (HTTP keep-alive, connection pooling)
- ✅ PowerShell's
Invoke-WebRequestworks 10/10 times (maintains connection pool) - ❌
curlwith fresh connections fails every other attempt (new TCP handshake each time) - ❌ Any tool/app that creates new connections shows the alternating pattern
- ❌ Affects multiple Dutch HTTPS sites
- ❌ Happens on ALL devices on my network (phones, tablets, computers, TV)
The pattern is 100% consistent: First new connection works, second new connection times out, third works, fourth times out, etc. But if you reuse an existing connection, it works forever.
Setup
Hardware & Firmware:
- Gateway: TP-Link Omada ER8411 v1.0 - Firmware 1.3.6
- Switch 1: TP-Link SG3210X-M2 v1.0 - Firmware 1.0.16
- Switch 2: TP-Link SG3210X-M2 v1.0 - Firmware 1.0.16
- Access Points: EAP650(EU) v1.0 (FW 11.3), EAP690E HD(EU) v1.0 (FW 1.0.3)
- ISP: KPN Fiber (Netherlands)
Network Configuration:
- Connection: PPPoE over VLAN 6 (internet) + VLAN 4 (IPTV)
- Multiple VLANs: Management (192.168.1.x), Home (192.168.2.x), IoT (192.168.3.x), Servers (192.168.8.x)
WAN Configuration:
- Physical WAN: WAN/LAN4 with PPPoE (VLAN 6)
- IPTV: VLAN 4 (DHCP, IGMP proxy enabled, Bridge mode)
- MTU: 1492, MSS Clamping: Custom 1452
- Primary DNS: 9.9.9.9
What We've Found (The Smoking Gun)
The SSL/TLS handshake is failing on alternating new connections:
When establishing a new HTTPS connection, the TLS handshake sequence is:
- Client sends TLS ClientHello (works fine)
- Server should respond with TLS ServerHello + Certificate + Server Key Exchange
- This is where it fails - the response either times out completely or packets arrive scrambled
tcpdump analysis revealed: Server packets are arriving out of order during the TLS handshake!
```
15:45:47.995990 Server sends: seq 2897:4097 (TLS continuation - arrives FIRST)
15:45:47.996000 Client: SACK {2897:4097} (acknowledges packet 2)
Server sends: seq 1:2880 (TLS ServerHello - should arrive FIRST, but is missing!)
Connection stalls: Client waiting for seq 1:2880 that never arrives
Result: SSL connection timeout after 5 seconds
```
The server IS responding, but packets arrive in the wrong order, breaking TCP reassembly. The client sees packet #2 before packet #1, tries to wait for the missing data, and eventually times out.
Critical detail: This ONLY happens on new TCP connections. Once a connection is successfully established:
- HTTP keep-alive connections work flawlessly (can make 100s of requests)
- Connection pooling works perfectly
- No timeouts, no packet loss, full speed
This is why:
- ✅
curl --keepalive-time 60 [url] [url] [url]succeeds 100% (reuses same connection) - ✅ PowerShell
Invoke-WebRequestsucceeds 100% (maintains connection pool) - ✅ Browsers mostly work (they aggressively reuse connections)
- ❌
curl [url]with new connection each time: 50% failure rate (alternates) - ❌ Apps that make fresh connections: intermittent failures
What We've Tried (Extensively)
Network Configuration Changes:
- ✅ Disabled load balancing (was balanced across multiple WANs)
- ✅ Created policy route to force all traffic via single WAN
- ✅ Disabled "Application Optimized Routing"
- ✅ Fixed VLAN configuration (was using both VLAN 4 and 6 for internet - now only VLAN 6)
- ✅ Changed PVID from 4 to 6 on WAN port
- ✅ Disabled virtual WAN (KPN_TV IPTV interface)
- ✅ Verified only ONE WAN interface active with
show interfacevia CLI
Protocol/Stack Testing:
- ✅ Tested different MTU values (1400, 1492, 1500)
- ✅ Tested different TLS versions (--tlsv1.2, --tlsv1.3)
- ✅ Tested with/without TOS bits (
--ip-tos) - ✅ Forced IPv4 only (
-4) - ✅ Tested with specific IP (bypassing DNS)
- ✅ Cleared connection tracking table (
conntrack -F) - ✅ Disabled ECN
- ✅ Tested MSS clamping values (1400, 1452)
Gateway Settings:
- ✅ QoS: Disabled
- ✅ DPI/IPS/IDS: Not present/disabled
- ✅ Hardware offload: No accessible settings (limited CLI)
- ✅ NAT ALG: Disabled (FTP, H.323, PPTP, SIP, IPsec)
- ✅ Gateway rebooted multiple times
What Actually WORKS:
- ✅ Connection reuse:
curl --keepalive-time 60 [url] [url] [url]- 100% success rate - ✅ PowerShell
Invoke-WebRequest- 100% success rate (uses connection pooling) - ✅ Testing from 5G/mobile hotspot - 100% success rate
Key CLI Findings
Current WAN port configuration (confirmed via SSH):
```
Port name..................WAN/LAN4
Belonged vlan..............6t
Pvid.......................6
Vlan6 config
Vlan type..................wan
Routing Interface Status...UP
Primary IP Address.........xx.xx.xxx.xx/255.255.255.255
Proto......................pppoe
Default Gateway............xxx.xxx.xxx.xx
```
Only ONE WAN VLAN is active, no duplicate routes, no multi-path routing visible.
Current Theories
- ER8411 hardware offload bug: The SoC/ASIC is reordering packets at wire speed, breaking TCP sequence
- KPN transparent proxy/DPI: ISP doing packet inspection that causes reordering
- TCP window scaling issue: Something about the negotiation between gateway and KPN causes packet spray
- Firmware bug: ER8411 has known issues with certain versions
Questions
- Has anyone seen this specific pattern (every-other-connection failure) with Omada gateways?
- KPN users: Do you experience similar issues with certain HTTPS sites?
- ER8411 users: What firmware version are you running? Any known bugs?
- Workarounds: Besides using a VPN or connection-pooling proxy, what else can be done?
The fact that it works perfectly on mobile data proves my internal network and the destination servers are fine - something in the gateway→ISP→internet path is mangling packets for new connections only.
Any ideas? I'm completely stumped after hours of troubleshooting!
TL;DR: New HTTPS connections fail every other attempt due to server packets arriving out of order. Connection reuse works perfectly. Only happens on home network (TP-Link ER8411 + KPN), works fine on mobile data. Spent hours troubleshooting network config - everything looks correct but issue persists.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
$ cat omada.sh
#!/bin/bash
_x=1
_host="https://..."
while [ $_x -le 5 ];
do
curl --no-keepalive --silent --connect-timeout 3 "$_host" -o /dev/null
echo "attempt #$_x: exit code $?"
sleep 1
_x=$(( $_x + 1 ))
done
$ $ ./omada.sh attempt #1: exit code 0 attempt #2: exit code 28 attempt #3: exit code 0 attempt #4: exit code 28 attempt #5: exit code 0 |
Would it be possible to get the beta firmware as well (model: ER8411 v1.0, running v1.3.6)?
I suspect that I'm seeing the same TCP issue, since timeouts stop occurring after switching WAN from PPPoE --> static/DHCP.
Thank you!
- Copy Link
- Report Inappropriate Content
Hi,@ahr0
To better assist you, I've created a support ticket via your registered email address and escalated it to our support engineer to look into the issue. Please check your email box and ensure the support email is well received. Thanks!
- Copy Link
- Report Inappropriate Content
Hi, @Borm
I've created a support ticket via your registered email address. Please check your inbox, thank you!
- Copy Link
- Report Inappropriate Content
Message received - thank you!
Edit: Uploaded the new firmware and can confirm that the issue is resolved. Did a few throughput tests with IDS/IDP + DPI with no issues as well.
- Copy Link
- Report Inappropriate Content
Hi,
saw some hints on how to deal with this here: https://community.tp-link.com/en/business/forum/topic/848156?sortDir=ASC&page=4
but instead of tweaking individual configurations, I would also want to contribute by testing the beta FW.
Can this be sent?
Thanks!
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 2208
Replies: 28
Voters 0
No one has voted for it yet.