The Kit
Left to right: GL.iNet AR150, Banana Pi BPI-R3 Mini, GL.iNet Slate7. Different tools, same principle.
I rotate through three routers depending on the situation. Each has a specific job.
GL.iNet AR150. The smallest unit. Square form factor. Runs off USB power alone. Pulls maybe 2 watts max. I pull this one out for short flights, quick hotel stays, anywhere I need minimum footprint and maximum portability. It handles five or six devices without sweat. No fancy hardware. Just enough to get the job done.
Banana Pi BPI-R3 Mini. My daily driver. MediaTek MT7986A (Filogic 830) quad-core ARM Cortex-A53, 2GB DDR4, 8GB eMMC, Wi-Fi 6 (MT7976C, 2x2 2.4G plus 3x3 5G), and two 2.5GbE ports. 65 by 65 millimetres. 100 grams. M.2 slots for NVMe storage and 5G modules if I need to skip the upstream network entirely. Accepts USB Type-C PD or 12V DC. Runs clean OpenWrt. No black boxes. This is the one on the desk in 90 per cent of hotel rooms.
GL.iNet Slate7. The heavy hitter. When I am dealing with an Airbnb, a small office, or somewhere with fifteen devices and mixed client types, the Slate7 steps in. More throughput, better radio density handling. Same WireGuard tunnel to my VPS. Same firewall rules. Just more headroom when the client count climbs.
All three run OpenWrt. All three tunnel through WireGuard to infrastructure I control. All three broadcast their own WPA3-encrypted SSID. The hardware differences are about capacity, not principle.
I also keep a backup GL.iNet Beryl AX (GL-MT3000) in the bag as redundancy. Operational planning, not paranoia.
What they all do:
→ Bridge whatever upstream connection exists. Public Wi-Fi, hotel ethernet, tethered 4G/5G, or a WISP bridge.
→ Create a private, encrypted subnet for all my devices.
→ Enforce firewall rules I wrote myself, between my devices and the upstream network.
→ Tunnel all egress traffic through WireGuard to a VPS I control.
→ Present a consistent SSID to my devices regardless of location.
What they do not do:
→ Trust the upstream network. Ever.
The Configuration: Zero Trust in Practice
The setup is straightforward but deliberate. Every decision flows from one principle: the upstream network is adversarial by default.
Firewall Zones
OpenWrt’s firewall (nftables) lets me define discrete zones. I create two:
→ wan is the upstream connection, whatever it happens to be. Treated as hostile. No forwarded traffic. No ingress accepted. MASQ enabled for egress only.
→ lan is my private subnet. Devices here can talk to each other if I allow it, and can reach the internet only through the WireGuard tunnel.
Traffic between zones is denied by default. I open only what is necessary, typically just DNS (forwarded to my own resolver over the tunnel) and the WireGuard handshake itself on the wan zone.
WireGuard Tunnel
All egress from the lan zone routes through a WireGuard tunnel to a VPS I administer. This means:
→ The upstream network operator, or the APT29 operator who has compromised it, sees only encrypted UDP traffic to a single endpoint.
→ DNS queries never touch the upstream resolver. No captive portal DNS manipulation. No redirection to ms365-device[.]com or m365-owa[.]com.
→ My real IP, traffic patterns, and destination metadata are hidden from the local network.
→ If the captive portal is injecting malicious payloads or rewriting HTTP responses, the tunnel makes it irrelevant.
WireGuard over OpenVPN, because WireGuard’s kernel-space performance on modest travel router hardware is markedly better, and the handshake is faster and less fingerprintable. On a GL.iNet device with limited CPU, this matters.
This is the part that defeats CaptiveCrunch specifically. Storm-2945’s entire campaign relied on manipulating DNS and HTTP traffic at the captive portal layer. My devices never touch the captive portal DNS. They never send HTTP requests through the upstream network. The travel router bridges the captive portal, authenticates if required, and then every byte after that goes through an encrypted tunnel to infrastructure I control. The manipulation has nothing to bite.
Wi-Fi Configuration
The travel router broadcasts its own WPA3-encrypted SSID. My devices are configured to connect only to this SSID. They never connect directly to upstream networks. This eliminates the risk of:
→ Rogue AP spoofing on the upstream network.
→ Deauth attacks forcing my devices onto attacker-controlled APs.
→ Unintended connection to open networks while my guard is down.
I also disable the radio on the upstream bridge when wired ethernet is available. Fewer radios, smaller attack surface.
VLAN Segmentation
If I am travelling with multiple devices, laptop, phone, tablet, IoT sensor, whatever, I segment them into separate VLANs on the lan side. The laptop does not need to talk to the phone. The phone does not need to talk to the IoT sensor. Lateral movement between my own devices is the personal-scale version of what APT10 did to the defence industrial base through shared trust between MSPs and their clients. I will not do their job for them.
Bonus Benefits Beyond Security
Security is the reason I started carrying a travel router. It is not the only reason I never stopped.
→ Geo-restrictions. My VPS sits in a fixed location. Streaming services, banking apps, and regional content see that location, not the one I am currently in. No surprise blocks when boarding in Tokyo and landing in Frankfurt.
→ Device limits. Hotels and airlines often cap concurrent devices per room or per ticket. My router registers as one device. Everything else talks to my LAN, not theirs.
→ Signal extension. Hotel Wi-Fi coverage is usually garbage. I place the router near the door where the signal is strongest and rebroadcast my own SSID across the room. Every device gets a clean connection instead of fighting for one bar next to the bed.
→ Airborne operation. These routers pull 5 to 8 watts. Any USB port on an aeroplane seat powers them. I skip the in-flight Wi-Fi entirely, connect the router to the seat-back port for power, and route my devices through my own subnet. The person in 14B does not get to touch my traffic at 35,000 feet either.
Zscaler, Tailscale, and the Layer Problem
A reasonable objection: “Why not just run Zscaler or Tailscale on the endpoint and skip the hardware?”
Because the threat model is different, and the difference is about layers.
Zscaler
Zscaler is enterprise infrastructure. It inspects outbound traffic through a cloud proxy, enforces policy, and gives visibility. But here is what happens when you connect a laptop running Zscaler to hotel Wi-Fi:
Step 1: Your laptop associates with the hotel SSID. It is now on the hostile network. Every device on that broadcast domain can reach it.
Step 2: The captive portal intercepts your browser’s first HTTP request. If APT29 has compromised the portal, your browser loads attacker-controlled ClickFix pages. Fake Windows Update. Fake Google verification. Fake DirectX installer.
Step 3: Your laptop asks the hotel DNS resolver where login.microsoftonline.com lives. The compromised resolver responds with attacker infrastructure. Your browser connects to a lookalike page. You enter a device code. Attacker now has an MFA-satisfied session.
Step 4: Zscaler’s agent eventually negotiates its tunnel. Now your traffic is encrypted. The damage may already be done.
The critical window is Steps 1 through 3. Your device is on the hostile network, interacting with hostile DNS and hostile HTTP, before the tunnel is up. Zscaler does not control what happens at the OS network stack before its tunnel establishes.
And then there is the local theft problem. Even after the tunnel is up, if CornFlake executed during that window, ChocoShell reads .tbres files from the Token Broker cache on disk. It reads cookies.sqlite from Firefox profiles on disk. It launches Chrome with a remote debugging port. None of that involves network traffic. The tunnel is irrelevant because the data never crosses the wire.
You also place complete trust in Zscaler’s infrastructure. Fine for an enterprise with a procurement relationship. Not fine for me.
Tailscale
Tailscale is lighter, faster, and built on WireGuard, which I respect. It creates a peer-to-peer encrypted mesh between your devices. But the same problem applies:
Step 1: Your laptop joins the hostile network.
Step 2: The captive portal loads in your browser before Tailscale connects.
Step 3: DNS poisoning fires before the tunnel takes over.
Step 4: If the payload executes, local token theft happens on disk. Tailscale never sees it.
Tailscale also relies on a coordination server for NAT traversal and key exchange. Less trust surface than Zscaler, but still third-party infrastructure you depend on.
The Travel Router
Here is the sequence with a travel router:
Step 1: The travel router, not your laptop, joins the hotel Wi-Fi. The router handles the captive portal authentication. Your devices are not on the hotel network. They are on your private LAN.
Step 2: The router establishes WireGuard to your VPS. All egress goes through the tunnel. The hotel sees only encrypted UDP to one IP.
Step 3: Your devices connect to the router’s WPA3 SSID. They receive DNS from the router, forwarded through the tunnel to your own resolver. They receive internet through the router, routed through the tunnel.
Step 4: Your devices never touch the captive portal. They never see the hotel DNS. They never load a ClickFix page. They never resolve ms365-device[.]com because their DNS goes through your VPS, not the hotel resolver. The device code phishing flow never triggers.
The difference in one sentence: Zscaler and Tailscale protect traffic after it leaves your device. The travel router prevents the hostile network from ever reaching your device.
With Zscaler or Tailscale, your laptop is physically on the hotel network, using hotel DNS, loading hotel captive portal content, for at least the initial connection window. The attack happens in that window.
With the travel router, your laptop is on your own network from the moment it connects. The hotel network is just an upstream pipe that carries encrypted UDP to your VPS. Nothing more.
I defend the boundary. I accept the endpoint risk. That is a calculated trade-off, not ignorance.
Why This Is Zero Trust, Not Paranoia
Zero trust is a term that has been beaten to death by marketing departments and compliance frameworks. At its core, it means one thing: never trust, always verify. No implicit trust based on network position. No assumption that because you are on the same network, you belong there.
The DoD’s CMMC programme tried to implement something like this across the Defence Industrial Base. It failed because compliance replaced security. Contractors passed audits and still got owned through lateral movement and supply chain pivots. The framework certified the prime while the tier-4 supplier still ran a default-password PBX.
The same failure mode applies to you and hotel Wi-Fi:
→ The hotel network “passed its audit.” Meaning some IT vendor checked a box.
→ The hotel network has a captive portal that APT29 has already compromised.
→ The hotel network puts you on the same broadcast domain as every other guest, including the one running responder in the corner.
→ The hotel network is logging your DNS queries and probably selling them.
You do not have a C3PAO. You do not have a compliance framework. What you have is a threat model that says the upstream network is not your friend. And you have OpenWrt.
The travel router is not paranoia. It is the physical manifestation of zero trust. It is the acknowledgement that trust must be earned, not granted by proximity. If the DoD cannot secure its supply chain with a multi-billion-dollar compliance programme, and APT29 is actively compromising hotel captive portals to steal enterprise SSO tokens, that is all the proof you need that zero trust starts at the edge. Your edge.
I have known this since 2004. The hardware has gotten smaller. The threats have gotten worse. The principle is unchanged.
Practical Notes for the Linux-Minded
If you want to replicate this setup:
→ Hardware: GL.iNet Beryl AX (GL-MT3000) or Slate AX (GL-AX1800). Both run OpenWrt natively. USB-powered. Compact enough to forget you are carrying it.
→ Firmware: Flash a clean OpenWrt build. Keep the GL.iNet bootloader intact for recovery. Sysupgrade via SSH. Do not rely on the web UI for flashing.
→ Packages: luci, luci-proto-wireguard, wireguard-tools, adblock (optional, for DNS-based ad blocking at the router), sqm-scripts (for QoS on marginal upstream connections).
→ Config: Back up your /etc/config/ directory. Version-control it in a private repo. Restore on fresh flashes in seconds.
→ VPS: Any cheap VPS with a static IP and kernel 5.6+ for native WireGuard. Hetzner, OVH, whatever you trust. Hardened SSH, fail2ban, and nothing else listening.
→ Editing: I maintain the router config in vim, naturally. If you are pushing config files to a router with nano, we need to have a conversation about your life choices.
The Takeaway
The gap between “I trust this network” and “this network compromised my devices” is measured in the time it takes an attacker to manipulate a captive portal DNS record. That gap closes fast on a hotel network. APT29 has already closed it.
The defence industrial base learned the hard way that trust relationships are vulnerabilities. CMMC Phase II got suspended because the implementation did not match the threat model. The threat did not suspend its operations to wait for the review. Neither did APT29.
Your hotel Wi-Fi is not a hypothetical anymore. It is an active attack surface being worked by a nation-state intelligence service right now.
So I carry a travel router. I run OpenWrt. I tunnel everything. And I sleep fine.
I have been doing this since the days of PCMCIA GSM cards and AirPort Express base stations. The hardware has evolved. The threat has caught up to what I always assumed it was. The principle is the same as it was in 2004: the upstream network can do whatever it likes. Manipulate DNS. Rewrite HTTP. Inject payloads at the captive portal. None of it touches my traffic.
Sources:
→ Russian Hackers Hijack Hotel Wi-Fi to Steal Microsoft 365 Tokens, Security Affairs, 1 August 2026
Related: My CMMC Phase II analysis on why compliance replaced security in the defence industrial base, and why that same failure mode applies to every network you do not control.