OpenWrt travel router hardening for hotels and public Wi-Fi in Australia
OpenWrt travel router hardening for hotels and public Wi-Fi in Australia
Hotel and airport Wi-Fi is a shared network you neither control nor audit, and in Australia you meet it constantly — conference centres, airports, serviced apartments, motels on the highway. The standard advice, "just use a VPN app on your phone", is right about encryption but wrong about architecture: your laptop still sits directly on the hostile network, still queries the local DNS resolver, and still loads whatever the captive portal decides to serve it during the one window when nothing is protecting it. A travel router changes the architecture instead. Your devices join a network you built; only the router touches theirs.
The threat model, stated plainly
Three problems dominate hotel-style networks, and they are worth naming separately because each needs a different control:
A shared broadcast domain. On most hotel networks, every guest is a peer. Client isolation — the setting that stops guests talking to each other — has to be deliberately enabled by the venue, and plenty of venues have not done it. Anyone in the building can port-scan your laptop, and the network operator sees every DNS lookup and connection metadata field you do not encrypt.
Evil twins and rogue access points. Anyone can stand up an SSID named after the airport's free network and wait for your phone to auto-join. Your devices connect to familiar-looking names by design, and once attached, the attacker sits in the middle. HTTPS protects the content of most traffic, but not which sites you visit and not your device from a well-built captive-portal trap.
The captive portal itself. That "agree to terms" page is an unencrypted web server the network controls, injected before any of your protection is up. It is the one moment you are guaranteed to load attacker-influenced content — a fake login prompt, a pushed certificate, device fingerprinting. As one detailed travel-router security write-up puts it, the captive portal is a security blind spot precisely because it happens while you are unprotected.
A travel router does not fix these problems at the hotel; it removes your devices from the blast radius. Only the router completes the portal, only the router joins the hotel SSID, and everything behind it sits on a private subnet behind a firewall you wrote.
The setup that matters
Step 1: flash OpenWrt and set a real password
On a GL.iNet Beryl AX (GL-MT3000) — the most commonly recommended OpenWrt-native travel router in this class, with the GL.iNet Brume 2 as the always-on gateway option when you get home — you can run either the stock firmware or a clean OpenWrt build. For hardening purposes, flash a current OpenWrt release: it removes vendor cloud-phone-home features, gives you the full firewall configuration surface, and lets you control every package installed. Keep the stock bootloader intact for recovery; on small flash chips, back up your /etc/config/ directory before every sysupgrade so a rebuild takes seconds rather than an evening.
First session checklist: change the admin password, rename the router's own SSID to something non-obvious, use a long WPA3 passphrase, and disable the admin interface's access from the WAN side. Treat the router's LAN like your home Wi-Fi, because that is exactly what it now is.
Step 2: bring the uplink automation
The OpenWrt travelmate package is purpose-built for this exact scenario: it maintains a wireless "uplink" to a hotel or hotspot, rebroadcasts your own access point, handles captive-portal detection with a heartbeat that keeps hotel sessions alive, supports auto-login hooks, and — a feature worth the price of admission — has an evil-twin protection mode that skips access points with locally-administered BSSIDs, which is the signature of spoofed SSIDs. It reconnects automatically when the portal times out or you walk from the lobby to your room, which is the operational detail that makes the whole thing usable in practice.
Step 3: tunnel everything
WireGuard is the right protocol on travel-router-class hardware: its kernel-space implementation performs far better than OpenVPN on a modest CPU, and the handshake is quick and quiet. Route all LAN egress through the tunnel to infrastructure you control — a home connection with a static address, or a small VPS you administer. The hotel network then sees only encrypted UDP to a single endpoint: no DNS queries touching the hotel resolver, no destination metadata, no HTTP the portal can rewrite. Configure a fail-closed policy so that if the tunnel drops, LAN traffic is blocked rather than leaking to the raw network — this is the difference between "tunnel enabled" and "tunnel enforced".
For DNS, resolve inside the tunnel. DNS-over-TLS to a resolver of your choice — Quad9 and Cloudflare both run open DoT endpoints — stops the hotel gateway from hijacking UDP 53, a standard behaviour on commercial hotel gateways that inject advertisements and enforce filters. We cover the surrounding choices in more depth in our public Wi-Fi safety guide.
Step 4: segment if you travel with multiple device classes
If you carry a work laptop, a personal phone, and an ESP32 sensor or camera rig, keep them on separate firewall zones or VLANs. Lateral movement between your own devices is the personal-scale version of the trust-boundary failures that dominate incident reports, and OpenWrt's nftables firewall makes the separation a ten-minute configuration exercise.
Why this beats per-device VPN apps
It is worth being precise about what the router buys you that per-device VPNs do not:
- The portal moment is delegated. Your laptop never loads the captive portal; the router does. The one genuinely dangerous interaction is taken out of your devices' hands entirely.
- Tunnel coverage is total and automatic. A phone VPN silently drops when the phone sleeps; a streaming stick and a Raspberry Pi cannot run VPN apps at all. Behind the router, everything is tunnelled, including things that cannot protect themselves.
- One device, one login. Hotels that cap or charge per device see one MAC address. Your whole kit hides behind it.
- A consistent, tested environment. Your SSID, your DNS, your firewall rules are identical in every hotel, so what you verified at home is what runs on the road.
None of this is exotic. It is the same zero-trust posture enterprises apply, scaled to a palm-sized router, and the practical effect is that the hostile network never reaches your devices at all.
Field-tested practicalities
A few details decide whether this actually works on the road:
- Power. These routers draw 5–8 watts, so any USB-C port works — laptop, power bank, airport seat. A power bank is the reliable nightstand option.
- Portal quirks. Some portals only fire on the first DNS lookup; if the login page does not appear, reboot the router. Repeat hotel chains are consistent — configure each chain's portal once and travelmate remembers it.
- Keep the recovery path. Travel with the ability to reflash: carry a copy of your config, and know the router's reset button procedure before you leave home.
- Test before departure. Run the whole flow — uplink, portal, tunnel, DNS — at home by hotspotting from your phone. Every failure you debug in your lounge is one you avoid in a lobby at midnight.
The honest summary: a travel router is not paranoia, it is boundary control. For the price of one product and an hour of configuration, every device you own stops touching networks that scan, log, spoof, and inject — and starts touching only networks you built. For Australian travellers who work remotely, that hour is among the highest-return security configuration you can do all year.
This article is general security information, not legal advice. All measures described are lawful defensive steps.