Table of Contents
- Introduction
- The Challenge of Captive Portals
- Why Relay a Captive Network? (A Cybersecurity Perspective)
- Prerequisites
- Step-by-Step Configuration Guide
- Advanced Tactics: MAC Cloning & Evading Detection
- Securing Your Relayed Network
- Troubleshooting Common Issues
- Conclusion
Introduction
If you’ve ever stayed in a hotel, worked out of a coffee shop, or connected to a university network, you’ve almost certainly run into a captive portal — that web page that pops up demanding you log in, agree to terms, or pay before you can actually use the internet.
For a single laptop or phone, that’s just a minor annoyance. But when you need to get a smart TV, a game console, or a whole bunch of lab devices online, it becomes a real problem. Most of those devices don’t have a web browser to complete the authentication, so they’re just stuck. The fix? Use a travel router or a spare wireless router as a relay. You authenticate once through the portal, the router’s MAC address gets whitelisted, and every device behind it rides along — no individual logins needed.
The Challenge of Captive Portals
To understand why this works, it helps to know what a captive portal is actually doing under the hood. When you first connect to one of these networks, it intercepts your DNS requests or redirects your traffic at the routing level — essentially trapping you in a “walled garden” until your device’s MAC address is authenticated.
The problem with plugging a standard router into that network is that the portal only sees the router’s WAN MAC address, and the router itself has no way to render the login page. By switching the router into WISP (Wireless Internet Service Provider) or Client Router mode, you let a connected phone or laptop handle that one-time authentication, after which the router’s MAC gets approved. From then on, all your devices behind the router’s NAT share that single authenticated connection.
Why Relay a Captive Network? (A Cybersecurity Perspective)
This isn’t just about convenience — it’s genuinely good operational security. Here’s why it matters:
- Device Isolation: Public Wi-Fi networks are open and hostile by nature. When your router creates a NAT boundary, your personal devices are no longer visible to everyone else on the same network segment.
- Network-wide VPN: With your own router in the middle, you can push all traffic through a VPN at the router level. That means even devices that don’t natively support VPNs — smart TVs, IoT gadgets, game consoles — get encrypted tunnels automatically.
- Minimal Exposure: You’re only authenticating one device (the router) against the untrusted captive portal, rather than every individual device you own.
Prerequisites
Before you start, make sure you have the following:
- A Router with WISP or Repeater Mode: Travel routers from GL.iNet are excellent for this, as are routers running custom firmware like OpenWrt or DD-WRT. One important caveat — don’t use a standard “Access Point” mode. That bridges your devices directly to the host network, meaning each one would need to authenticate separately. You specifically need a mode that routes and NATs your local subnet behind a single client connection.
- Network Credentials: Whatever the captive portal needs — a room number, password, voucher code, or just a checkbox acceptance.
- A Configuration Device: A smartphone or laptop with a browser to complete the setup and portal authentication.
Step-by-Step Configuration Guide
1. Connect and Access the Router’s Admin Interface
- Power on your relay router and connect your laptop or phone to its default Wi-Fi network.
- Open a browser and go to the router’s admin page — usually
192.168.1.1,192.168.8.1, or10.0.0.1depending on the model. - Log in with your admin credentials.
2. Enable WISP or Repeater Mode
Important: Avoid standard bridging/AP mode here. You need routing with NAT enabled so that all your devices appear as a single client to the host network.
- Go to Wireless or Internet settings in the admin panel.
- Select WISP, Repeater, or Client Router mode — the exact label varies by firmware.
- Scan for available networks and select the target public Wi-Fi.
- Save and apply. The router will reboot and connect to the public network as a client.
3. Authenticate Through the Captive Portal
- Make sure your phone or laptop is connected to your relay router’s own Wi-Fi network.
- Open a browser and go to
http://neverssl.com— this forces a plain HTTP request, which the captive portal can intercept and redirect. - The portal will load in your browser. Complete the login or acceptance flow.
- Once authenticated, the portal whitelists your router’s MAC address. Because all your devices are behind the router’s NAT, they all get internet access immediately — no further action needed.
Advanced Tactics: MAC Cloning & Evading Detection
Some enterprise or hospitality networks go further and actively try to detect relayed connections, using Deep Packet Inspection (DPI) or TTL analysis. Here’s how to handle those situations.
MAC Address Cloning
Some networks tie authentication to a specific device’s MAC address — for example, the portal might register your phone and then expect all traffic to come from that MAC. If your router’s OUI gets flagged, or if re-authenticating is a hassle:
- Authenticate directly on your smartphone first.
- Disconnect your phone from the public network.
- In your router’s admin panel, find the MAC Clone or MAC Spoof option under WAN settings.
- Enter your phone’s Wi-Fi MAC address.
- The network now sees your router as your phone, keeping the session intact.
Adjusting TTL Values (OpenWrt / Custom Firmware)
Every time a packet passes through a router, its TTL (Time-to-Live) value drops by 1. A network admin watching for routers can spot this — packets arriving with a TTL of 63 instead of 64 suggest something is relaying traffic.
On OpenWrt with iptables, you can fix the outgoing TTL:
iptables -t mangle -I POSTROUTING -o wlan0 -j TTL --ttl-set 65
On newer systems running nftables, the equivalent is:
nft add rule ip mangle POSTROUTING oifname "wlan0" ip ttl set 65
Adjust the interface name (wlan0) to match your router’s actual WAN interface. This makes outgoing packets look like they originated directly from a single device.
Securing Your Relayed Network
Relaying a public network means inheriting its risks. Don’t stop at getting connected — take a few extra steps to lock things down:
- Run a VPN on the Router: Set up WireGuard or OpenVPN directly on the relay router. This encrypts everything leaving your network, shielding it from the host network’s admins and any eavesdroppers on the same Wi-Fi.
- Use Encrypted DNS: Configure DNS over HTTPS (DoH) or DNS over TLS (DoT) on the router — Cloudflare’s
1.1.1.1and Quad9’s9.9.9.9both support this. It prevents the captive portal from logging your DNS queries and stops DNS-based redirect tricks from leaking data.
Troubleshooting Common Issues
1. The Captive Portal Won’t Load
Cause: Your browser might be enforcing HTTPS-only connections or using a custom DNS resolver that bypasses the portal’s redirect mechanism.
Fix: Disable any custom DNS settings on your device temporarily, then navigate to http://neverssl.com — the plain HTTP request gives the portal something to intercept. Alternatively, try typing the router’s default gateway IP directly into the browser.
2. Devices Keep Disconnecting
Cause: Many captive portals enforce session timeouts — often 24 hours — or kick idle connections after a period of inactivity.
Fix: You’ll need to re-authenticate when sessions expire. To avoid idle disconnects, you can set up a simple script on a connected device to ping an external server (like 8.8.8.8) every few minutes, keeping the session alive.
3. IP Subnet Conflicts
Cause: Your relay router’s LAN subnet matches the public Wi-Fi’s subnet — for example, both using 192.168.1.x. This causes routing loops and breaks connectivity.
Fix: Change your router’s LAN IP to a different subnet entirely, such as 10.50.50.1/24. This guarantees there’s no overlap between your private network and the host network.
Conclusion
Setting up a Wi-Fi relay is one of the most practical security moves you can make when working from public networks. Beyond just solving the multi-device problem, it creates a meaningful security boundary between your gear and whatever else is happening on that hotel or airport Wi-Fi. Combine it with a router-level VPN and encrypted DNS, and you’ve turned an untrusted network into something you can actually work on with confidence.