Summary and reproducible workaround
On my Flint 3e (GL-BE6500), Wi-Fi clients experience HTTPS failures when using a self-hosted WireGuard tunnel with Hardware Acceleration enabled.
The main symptoms are:
-
Homepage | sciensano.be fails consistently.
-
Other websites, including https://auchan.fr/ and https://carrefour.fr/, intermittently display a connection error, then load after an apparent automatic retry.
Disabling Network Acceleration resolves both symptoms in my tests. Re-enabling Hardware Acceleration brings them back; disabling it again restores normal operation.
The same tunnel works over Ethernet with Hardware Acceleration enabled. WireGuard connections to NordVPN servers also work over Wi-Fi with Hardware Acceleration enabled.
This report documents the controlled comparisons and remaining uncertainties. It does not assume that every WireGuard server or Wi-Fi client is affected.
1. Environment
| Component | Configuration |
|---|---|
| Client router | GL.iNet Flint 3e / GL-BE6500 |
| Client location | Asia |
| GL.iNet firmware version/build | 4.9.0 |
| OpenWrt version shown in Device Info | 23.05-SNAPSHOT r0-3601c2a49 |
| Kernel version | 5.4.213 |
| Personal VPN server | TP-Link Archer BE550 in Belgium |
| Server Internet connection | Residential Proximus fibre, dynamic public IP with DDNS |
| VPN protocol | WireGuard |
| Original personal VPN profile | IPv4 full tunnel; DNS 10.5.5.1; MTU 1420; PersistentKeepalive 25 |
| NordVPN profiles used for comparison | WireGuard; MTU 1350 |
| Browser tests | Chrome, Chrome Incognito and Edge |
| Client devices | Failure reproduced on two PCs over Wi-Fi |
| Wi-Fi | Same Flint SSID; original PC connected on 5 GHz |
Automatic firmware updates were enabled, but I have not established which update, if any, introduced the behaviour.
Cloudflare Secure DNS was enabled in Chrome during the final Ethernet/Wi-Fi and acceleration on/off comparisons. The acceleration changes were made without changing the VPN endpoint or DNS settings.
2. Initial symptoms and diagnostic checks
Initially, the problem appeared to involve the Belgian VPN connection because switching to NordVPN generally allowed the affected sites to load.
There were also occasional local Wi-Fi ping losses at the original desk location. However, moving the PC next to the Flint eliminated those losses without eliminating the HTTPS failures.
Further tests showed:
-
The problem also occurred in Chrome Incognito and Edge.
-
A second PC reproduced the Wi-Fi failures.
-
A phone using the same Wi-Fi and the same Belgian public exit IP showed no anomaly during a ten-minute browsing test. This was a negative observation over that period, not proof that phones are universally unaffected.
-
During subsequent controlled tests, 300 pings to the Flint’s LAN address completed without loss.
-
Cloudflare Secure DNS did not eliminate the HTTPS failures.
These observations made a browser-profile problem, an issue unique to the original PC, and weak Wi-Fi signal alone insufficient explanations.
3. Decisive comparison: Ethernet versus Wi-Fi on the same PC
I tested a second PC through the Flint, first over Ethernet with Wi-Fi disabled, then over the same Wi-Fi used by the original PC.
The Belgian VPN exit and Chrome Cloudflare DNS configuration were retained.
| Test | Result |
|---|---|
| Second PC over Ethernet, Wi-Fi disabled, Hardware Acceleration enabled | Sciensano loads; no intermittent browsing error observed |
| Same second PC over Wi-Fi, Hardware Acceleration enabled | Sciensano fails; intermittent browsing errors reproduce |
| Local ping during both scenarios | No packet loss |
This showed that the same PC, browser and personal WireGuard tunnel could work correctly over Ethernet while failing over Wi-Fi.
4. Decisive comparison: Hardware Acceleration enabled versus disabled
I then changed only the Flint’s Network Acceleration setting while retaining the Wi-Fi connection and personal WireGuard tunnel.
| Configuration | Result |
|---|---|
| Wi-Fi + personal WireGuard tunnel + Hardware Acceleration | Sciensano blocked; intermittent browser errors |
| Same configuration, Network Acceleration Disabled | Sciensano accessible; intermittent errors no longer reproduced during testing |
| Hardware Acceleration re-enabled | Both symptoms return |
| Network Acceleration disabled again | Normal operation returns |
The enabled → disabled → enabled → disabled sequence reproduced the relationship.
My current working configuration is Network Acceleration Disabled.
5. NordVPN comparison and MTU observations
With Hardware Acceleration enabled, WireGuard connections through NordVPN servers in Brussels and Frankfurt passed the browsing tests.
There is a known configuration difference:
-
Personal BE550 tunnel: effective client MTU shown in the Flint interface is 1420.
-
Working NordVPN profiles: MTU 1350.
However, an earlier test reducing the personal tunnel MTU to 1280 did not restore access to Sciensano. A simple “MTU is too high” explanation has therefore not been established.
The NordVPN results are useful controls: Hardware Acceleration does not fail with every WireGuard connection. They do not establish whether the decisive difference is the profile, packet characteristics, network path, remote implementation, or an interaction between them.
Software Acceleration has not been validated as an alternative workaround in my setup.
6. What the network diagnostics showed
For Sciensano under the failing personal VPN configuration:
-
DNS resolution returned an address.
-
Failures persisted when curl used a fixed destination IPv4 address, bypassing DNS resolution for the site.
-
TCP port 443 could connect successfully, with a connection time around 0.23 seconds.
-
TLS negotiation failed to complete; repeated attempts ended with a connection reset after approximately 16 seconds.
-
Forcing HTTP/1.1 and TLS 1.2 did not resolve the failure.
For an additional intermittent HTTPS failure captured in Chrome NetLog:
-
Cloudflare DNS-over-HTTPS resolution succeeded promptly.
-
TCP connected successfully.
-
Chrome sent its TLS ClientHello, but received no response on that connection during the attempt.
-
A subsequent connection to the same destination IPv4 address completed TLS and received HTTP 200.
-
A parallel QUIC attempt also stalled after receiving an initial packet.
-
Other HTTP exchanges succeeded during the affected period.
These traces do not identify where packets were lost or which device caused the reset. They do show that the symptoms cannot all be attributed to DNS failure or a complete outage of the VPN tunnel.
Earlier captures also contained DNS refusals and fallback delays. Switching Chrome to Cloudflare DoH removed that DNS path from the later reproduction, but the HTTPS failures remained until acceleration was disabled.
7. Why ping, curl benchmarks and Speedtest can miss the issue
Passing basic connectivity tests did not guarantee working browser sessions:
-
Local ping could show 0% loss while Sciensano remained inaccessible.
-
Ten-request curl benchmarks against another HTTPS endpoint succeeded with acceleration both enabled and disabled.
-
Speedtest completed in both modes.
Individual Speedtest results were:
| Setting | Download | Upload |
|---|---|---|
| Network Acceleration Disabled | 253.78 Mbps | 349.79 Mbps |
| Hardware Acceleration enabled | 200.65 Mbps | 406.77 Mbps |
These are individual measurements, not a controlled performance benchmark. Their relevance is that substantial throughput can coexist with the HTTPS failures.
Sciensano and repeated browser navigations were more useful reproduction tests than ping or throughput alone.
8. Suggested reproduction procedure
-
Connect a PC to the Flint’s Wi-Fi and route it through a WireGuard client tunnel.
-
Enable Hardware Acceleration.
-
Open Homepage | sciensano.be and repeatedly browse https://auchan.fr/ and https://carrefour.fr/.
-
Record any connection errors and automatic retries.
-
Disable Network Acceleration, keeping the PC, Wi-Fi, VPN endpoint and DNS configuration unchanged.
-
Reconnect the VPN and repeat with fresh browser connections.
-
Re-enable Hardware Acceleration and repeat to check whether the failures return.
-
Where possible, compare the same PC over Ethernet with Wi-Fi disabled.
9. Interpretation and request to GL.iNet
The reproducible finding is an interaction between the Flint’s accelerated Wi-Fi forwarding and this particular WireGuard setup.
The personal VPN server and Internet path remain unchanged when disabling acceleration restores connectivity. Ethernet also works through the same server. Conversely, the working NordVPN tests show that the failure is not universal across WireGuard profiles or endpoints.
The underlying mechanism has not been identified. Possibilities such as segmentation, MSS handling, checksum processing or accelerated flow handling require appropriate packet captures and router diagnostics.
Could GL.iNet:
-
Investigate this specifically on the GL-BE6500 / Flint 3e?
-
Provide an issue reference and identify any affected or fixed firmware builds?
-
Advise which captures and accelerator diagnostics can reliably distinguish the failing and working configurations?
-
Specify a capture method that remains valid while Hardware Acceleration is enabled?
-
Confirm whether any additional profile settings should be compared between the personal tunnel and the working NordVPN profiles?
Please advise how to share the necessary diagnostic files privately. Public excerpts will be anonymized.
Related discussions
A Flint 3e Wi-Fi troubleshooting discussion includes a support recommendation to test with Network Acceleration disabled:
A separate Wi-Fi/VPN acceleration issue was confirmed on the GL-BE9300 and GL-BE3600:
These are relevant precedents, but I am not assuming that they share the same underlying defect as this GL-BE6500 case.