The Travel Router That Tunnels Home: GL.iNet + WireGuard on Hostile Wi-Fi

Hotel Wi-Fi sees a hotel Wi-Fi client. That's the whole trick: connect your laptop to the travel router, and everything behind it — phone, laptop, work gear — exits through an encrypted WireGuard tunnel back to your home network. You keep your home public IP, you reach your internal resources (NAS, Home Assistant, the game server), and there's no monthly VPN subscription in the middle.

Before you start//

• Two GL.iNet routers. One at home as the server (the official tutorial uses a GL-MT6000 or GL-MT5000; any model that runs WireGuard server works — even the GL-MT2500 if you don't need Wi-Fi at home). One small one as the travel client (GL-MT3000 Beryl AX, AR300M, etc.).
• Firmware v4.x on both. UI paths below are verified against the v4 docs as of 2026-09-10 — note that v4.7 and v4.8+ differ in a couple of places (VPN Dashboard layout, kill switch), and the docs call out both; we'll flag it where it matters.
• A public IP at home. This is the load-bearing requirement: check from a device behind your home router whether whatismyipaddress.com matches your WAN IP. If it doesn't, you're behind CGNAT and DDNS will not save you — see "When it breaks."
• ISP router admin access if the GL.iNet sits behind your ISP's modem/router (sub-router topology) — you'll need to port-forward UDP 51820.
• Skill floor: basic comfort in a router web UI. Time cost: ~2–3 hours including testing, most of which is the first tunnel coming up and then proving it doesn't leak.

The setup//

1. Pick your topology (decide once, saves an hour)

From the home GL.iNet admin panel, check INTERNET → connection details: if it's directly connected to the ISP modem via Ethernet with a public WAN IP, it's the main router and needs no port forwarding at all — that's the clean setup. If your ISP's modem/router is in front (the common case), you're the sub-router: forward UDP 51820 to the GL.iNet's LAN IP on the main router, and reserve a static IP for it first so a reboot doesn't orphan the port-forward rule. Both paths are covered in the official tutorial.

2. Home router: WireGuard server + DDNS (10 min)

On the home GL.iNet, go to VPN → WireGuard Server. Confirm the listen port is 51820 and click Apply. If your public IP is dynamic (most cable/fiber), enable DDNS first: APPLICATIONS → Dynamic DNS, toggle on Enable DDNS, accept the terms, Apply — then generate client profiles with the DDNS Domain option enabled so the endpoint survives an IP change.

Why: WireGuard is UDP-only and stateless; one port, one protocol, no NAT hairpin weirdness. A dynamic IP without DDNS means your tunnel breaks every time your ISP renews your lease — which happens more often than you'd think.

3. Generate the client profile (2 min)

Still on VPN → WireGuard Server, open the Profiles tab, click Add. The router generates a full client configuration; switch to the Configuration File tab and either scan the QR with a phone's WireGuard app for a quick test or download/save the .conf for the travel router.

4. Travel router: change its LAN IP (5 min) — do this before anything else

Both GL.iNet routers ship at 192.168.8.1. If you've ever tried to set one up on the same network as the other, you know how that goes. On the travel router: NETWORK → LAN, change the LAN IP from 192.168.8.1 to something off your home subnet — e.g. 192.168.10.1 (the exact example in the official tutorial). You'll lose admin access at the old address; reconnect to the new one.

5. Import and start the tunnel (10 min)

On the travel router: VPN → WireGuard Client → Add Manually, create a group, upload the .conf (or paste the config text), Apply once it passes verification, then hit the three-dot icon on the profile and click Start. A green dot means connected. Confirm from both sides — the client's VPN Dashboard shows the connection with your home public IP, and the server shows the client attached. UI note: on firmware v4.7 and earlier the server-side view is under VPN → VPN Dashboard; on v4.8+ it's VPN → WireGuard Server. The page layout differs slightly between versions; the state you're confirming (client connected, counters moving) is the same either way.

6. Hardening: kill switch, DNS inside the tunnel, IPv6 off (15 min) — this is where most setups leak

This step isn't in the basic "get a green dot" flow, and it's what makes a travel VPN actually private:

• Kill switch. On firmware v4.7 or earlier: VPN → VPN Dashboard → Global Options, toggle on Block Non-VPN Traffic. On v4.8+: the kill switch is per-tunnel and enabled by default once the tunnel activates; for full coverage, switch to Policy Mode in the VPN Dashboard and disable the "All Other Traffic" fallback tunnel so unmatched traffic gets blocked instead of leaking out the WAN. Both paths are documented in GL.iNet's VPN Kill Switch FAQ. Why: without it, any app that bypasses the tunnel (or a dropped connection) sends plaintext straight to the hotel network — you've just encrypted 95% of your traffic.
• DNS through the tunnel. On the travel router: NETWORK → DNS, switch to Manual DNS and point it at your home router's LAN IP, so queries resolve on your network inside the tunnel (docs). If you set custom DNS here, also check "Allow Custom DNS to Override VPN DNS" is behaving as intended — that toggle decides whether your manual setting wins over whatever the VPN hands out.
• Disable IPv6. On the travel router: NETWORK → IPv6, turn it off (docs). Why: IPv6 addresses are assigned per-interface and don't ride your IPv4 tunnel — one leaked v6 query exposes your real location even with a perfect v4 setup.

7. Optional: bind both routers to GoodCloud before you leave (5 min)

GL.iNet GoodCloud lets you reach the admin panels remotely — the official tutorial's last step, and genuinely worth it: when the tunnel is down at 9pm in a hotel, "log into the router locally" is not an option. The tradeoff (a cloud relay touching your box) is small but real; if that bothers you, skip this and accept that remote debugging means carrying the router home.

Verify it worked//

Non-negotiable — do all three:

1. IP check: from a device behind the travel router, open whatismyipaddress.com. It must show your home public IP, not the hotel's.
2. DNS leak test: run dnsleaktest.com (extended). Only resolvers you'd expect from your home network should appear — a hotel or ISP resolver in that list means your DNS step didn't take.
3. Counters: watch the travel router's VPN Dashboard while generating traffic; send/receive counters must be moving. A green dot with flat counters is a tunnel that connected but isn't routing anything through itself.

When it breaks//

• "Client is starting, please wait…" forever — the classic. The travel router can't reach port 51820 at home: check the forward is UDP, points at the GL.iNet's reserved IP, and that your DDNS hostname actually resolves to your current public IP (stale records after an ISP IP change are common). Some ISPs block inbound UDP outright — a phone hotspot test on the same port tells you fast.
• No public IP / CGNAT — if whatismyip never matched your WAN IP at home, no amount of DDNS fixes it: the forward has nowhere to land. Your fallback is GL.iNet's own AstroWarp SD-WAN or Tailscale on both routers — same payoff, different plumbing, and honestly the right choice for Starlink-style setups.
• Tunnel up but DNS leaking (dnsleaktest shows your real location): re-do step 6 — Manual DNS pointed at home LAN IP, IPv6 off. This is the #1 "it looks fine but isn't" state in travel-router setups (community reference agrees).
• Rollback: every step above is a UI toggle or a config file — delete the WireGuard client profile and revert the LAN IP to go back to stock. Nothing here touches your home router's existing setup except (in sub-router mode) the port-forward rule, which you remove when done.