Routers · GL.iNet
GL.iNet Travel Routers Travel VPN Disconnects
Persistent VPN disconnects on GL.iNet travel routers usually point to captive portal interference, aggressive public Wi-Fi lease renewals, or MTU packet fragmentation. Here is how to keep your tunnel stable on hotel and cafe networks.
Symptoms
- VPN client disconnects every few minutes on hotel or airport Wi-Fi
- WireGuard tunnel shows connected state but fails to pass web traffic
- Repeater mode continuously drops and reconnects to the host hotspot
- Captive portal authentication page will not load when router is booted
- Zoom calls or SSH sessions freeze while GL.iNet status LED blinks
- OpenVPN log shows repeated TLS handshake timeouts or reset errors
Quick troubleshooting
Step 1
Bypass Captive Portals Before Starting the VPN
Turn off the VPN client toggle in the GL.iNet Admin Panel before connecting to the hotel Wi-Fi. Connect a laptop or phone to the GL.iNet network, open a browser, and navigate to 192.168.8.1 or a plain HTTP site (like http://neverssl.com) to complete the hotel login. Once connected to the internet, toggle the VPN client back on.
Step 2
Lower the VPN Tunnel MTU Size
Hotel and cellular networks often wrap traffic in extra headers that drop standard 1500-byte packets. In the GL.iNet Admin Panel, navigate to VPN > VPN Client, edit your active profile, and lower the MTU setting from 1420 down to 1360 (or 1280 for OpenVPN). Save the settings and reconnect the tunnel to stop packet loss drops.
Step 3
Configure DNS Rebind Protection and Override
Go to Network > Custom DNS in your GL.iNet dashboard. Temporarily disable 'DNS Rebind Protection' while authenticating on public networks so the router doesn't block local IP redirects used by hotel login pages. Ensure 'Allow Custom DNS Override for VPN' is enabled only after authentication succeeds.
Step 4
Clone Your Authenticated Device's MAC Address
If the hotel network frequently drops the travel router, authenticate on the hotel network using your phone or laptop directly first. Then open Network > MAC Clone in the GL.iNet panel and clone that device's MAC address to the router's WAN/Repeater interface so the host network treats the router as an approved client.
Likely causes
- Host Wi-Fi network forcing periodic re-authentication via captive portal
- MTU size too high, causing packet fragmentation over cellular or hotel WAN
- DNS Rebind Protection blocking local captive portal redirections
- Aggressive keep-alive timeouts in WireGuard or OpenVPN configurations
- Underpowered USB power source causing Wi-Fi radio or CPU resets
- IP subnet conflict between host network and GL.iNet LAN subnet
What's going on
GL.iNet travel routers (such as the Slate, Beryl, and Opal series) excel at picking up a public Wi-Fi signal, running a local secure access point, and routing all client traffic through an encrypted WireGuard or OpenVPN tunnel. However, because you are layering a private VPN tunnel on top of a third-party host network, connection stability depends heavily on how the host network handles UDP traffic, MAC leases, and captive portals.
When a VPN drops repeatedly on a GL.iNet Travel Router, the router is usually struggling with network-level interruptions from the host hotspot, unhandled packet fragmentation, or DNS conflicts. Diagnostic tools in the GL.iNet Admin Panel can help isolate whether the issue lies in the Wi-Fi repeater bridge or the VPN tunnel itself.
Symptoms people notice
- WireGuard or OpenVPN drops handshake connection every 10 to 15 minutes.
- Connected devices display 'No Internet Access' even though the GL.iNet dashboard says connected.
- The hotel's splash page stops appearing when you join new guest networks.
- Admin Panel shows the Repeater status bouncing between 'Connecting' and 'Disconnected'.
- Video streams drop completely while standard browsing slowly loads after brief stalls.
Likely causes
Most GL.iNet travel VPN drops stem from configuration misalignments between the public host network and your internal tunnel:
- Captive Portal Interception: Host networks drop UDP VPN traffic until a browser accepts terms on their splash page.
- MTU Mismatches: Encrypted packets exceed the network path Maximum Transmission Unit, leading to silent packet dropping.
- IP Subnet Overlap: The host Wi-Fi uses the default
192.168.8.xsubnet, conflicting with the GL.iNet factory LAN range. - Insufficient USB Power: Running Wi-Fi Repeating and heavy OpenVPN encryption on low-voltage USB ports (like TV USB ports) causes silent CPU brownouts.
Quick checks first
Before changing deep configuration files, run through these quick triage checks:
- Power Supply Check: Ensure your router is powered by an adequate 5V/2A or 5V/3A wall charger rather than a weak laptop or hotel TV USB port.
- Subnet Isolation: Check your GL.iNet LAN IP under Network > LAN. If the hotel Wi-Fi also uses
192.168.8.1, change your GL.iNet LAN address to10.0.0.1to eliminate routing loops. - Persistent Keep-Alive: For WireGuard setups, add
PersistentKeepalive = 25to your peer configuration to prevent firewalls from closing idle UDP ports.
When it's a real hardware fault
Hardware failures on GL.iNet devices are less common than software misconfigurations, but physical stresses during travel do happen. Thermal throttling can occur if the small enclosure is covered in a bag while under heavy cryptographic load, triggering soft radio resets. If the router drops all Wi-Fi signals (both 2.4GHz and 5GHz local networks vanish) even when connected to a reliable wall charger with no VPN enabled, the internal Wi-Fi SoC or power regulator may be failing.
Physical damage to the USB-C power jack can also cause intermittent reboots whenever the cord moves. If the router reboots completely during high-bandwidth VPN transfers, test with a known-good high-wattage power adapter and cable.
Soft resets vs board/panel work
Fixing GL.iNet software and configuration issues should always start within the Web Admin UI or via the physical toggle switch mapped to VPN functions.
- Soft Reset: Use the physical reset button held for 4 seconds to reset network settings, or hold for 10 seconds to restore factory firmware if a bad OpenVPN config locks you out.
- Firmware Flashing: U-Boot fail-safe recovery mode allows you to re-flash stock firmware over Ethernet if a corrupt update breaks network interfaces.
- Internal Repairs: Micro-soldering power ICs or replacing onboard Wi-Fi antennas on these compact travel boards is rarely practical or cost-effective. Internal hardware failures generally warrant unit replacement.
Next steps
If your VPN drops only on specific public networks, tweaking MTU values and cloning your phone's MAC address will usually stabilize the link. Check our main router problems overview for general Wi-Fi triage, or explore our GL.iNet brand hub and hardware reviews to compare portable routers built for heavy remote work.
Next steps
Try the DIY guide if you're comfortable opening the device. Still stuck? Browse related problems for similar symptoms.
Related problems
- Rokid AR Glasses No Display / Nebula Not Detecting
- Viture XR Glasses No Display / Nebula Not Detecting
- Xreal AR Glasses No Display / Nebula Not Detecting
- Meta Oakley Smart Glasses Camera Capture Fails or Blurry
- Meta Ray-Ban Smart Glasses Camera Capture Fails or Blurry
- Samsung Smart Glasses Smart Glasses Case Not Charging Buds/Arms

