How to Configure Any Router as a Wi-Fi Relay for Networks with Captive Portals

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

A captive portal is a man-in-the-middle attack that the network operator runs against you on purpose. That is not rhetoric — the mechanism is identical: your DNS queries are answered with the wrong address, or your HTTP request is intercepted and answered by a device that is not the server you asked for, until you satisfy some condition. The only difference between a hotel portal and a hostile one is intent, and your devices cannot tell them apart.

Which is why the portal is such an awkward obstacle. Everything the modern web has done to prevent exactly this interception — HTTPS everywhere, HSTS, encrypted DNS — works against you here, and that is also why the browser tricks in this guide work the way they do.

For one laptop it is a small irritation. For a smart TV, a games console, an e-reader, a Kindle or a rack of lab devices, it is a wall: those devices either have no browser at all or have one that cannot render a portal built for a phone. The workaround is to put a router in between. Authenticate once from a device that does have a browser, the portal associates the session with the router’s MAC address, and everything behind the router’s NAT rides on that one authenticated connection.

Two caveats before you build it. Many venues’ terms of service explicitly prohibit sharing a connection across multiple devices, and this technique does that — on a corporate or campus network, check before you deploy rather than after. And this is a technique for networks you are authorised to use; the MAC cloning section later is included because it is sometimes needed for legitimate session continuity, not as a way around access controls you were not given.

The Challenge of Captive Portals

Mechanically, a captive portal is a firewall rule plus a redirect. Until your MAC address appears in the allowed set, the gateway drops or rewrites everything you send. DNS queries get answered with the portal’s address regardless of what you asked for. Plain HTTP requests get answered with a 302 to the login page. HTTPS requests get dropped or reset, because the gateway cannot forge a certificate your browser will accept — which is why the portal often simply fails to appear on a modern phone rather than popping up helpfully.

Operating systems know this and probe for it. Apple devices request captive.apple.com, Android hits a Google endpoint, Windows checks msftconnecttest.com — all over plain HTTP, all expecting a specific short response. Get anything else back and the OS concludes a portal is present and opens the sign-in sheet. That probe is the whole reason your phone shows the portal automatically and your smart TV does not.

A router plugged into that network has two problems. The portal sees only the router’s WAN MAC, and the router has no browser to complete the flow. WISP mode (also called Client Router mode) solves both: the router associates with the public network as an ordinary wireless client while continuing to run its own DHCP, NAT and Wi-Fi on the LAN side. Your phone, connected to the router’s network, does the authentication — the traffic exits via the router’s WAN MAC, so it is the router’s MAC that gets allowed, and everything else behind the NAT is now indistinguishable from that one authenticated client.

Why Relay a Captive Network? (A Cybersecurity Perspective)

The convenience is the reason people do this. The security benefit is the reason it is worth doing properly.

Device isolation. On an open hotel network, your laptop shares a broadcast domain with every other guest, and unless client isolation is enabled — it often is not — anything on that segment can scan you, attempt SMB or mDNS discovery, and see the services your devices advertise without being asked. Putting your own NAT in front means inbound connections have nowhere to go. Your kit becomes a single opaque endpoint rather than a set of individually reachable hosts.
Network-wide VPN. A VPN client on the router covers everything behind it, including the devices that have no VPN support at all — consoles, TVs, IoT gadgets, printers. This is the single biggest gain, because it turns the untrusted network into a transport you do not have to trust.
Minimal exposure to the portal itself. You hand your room number, voucher code or email address to one device’s session rather than repeating it from every device you own, and only one MAC address is registered against you.

Be clear about what this does not do. NAT is not a firewall and it is not encryption: everything you send still traverses the venue’s network in the clear unless you add a VPN, and the operator can still see every destination you contact and every unencrypted byte. The relay improves your inbound exposure. Only the VPN improves your outbound privacy, which is why the two belong together rather than as alternatives.

Prerequisites

Before you start:

A router with WISP or Client Router mode. GL.iNet’s travel routers ship OpenWrt with this configured out of the box and are the least painful option; anything running OpenWrt or DD-WRT will do it. The distinction that matters, and the one people get wrong: do not use Access Point or bridge mode. A bridge puts your devices directly onto the host network with their own MAC addresses, so each one hits the portal separately and the whole exercise fails. You need a mode that terminates the wireless client connection and NATs your own subnet behind it. If the mode names are ambiguous, the test is whether the router hands out its own DHCP range — if your laptop gets a 192.168.8.x address from the router rather than a hotel address, you are routing.
Single-radio versus dual-radio. A single-radio router relaying will use the same radio to talk to the host network and serve your devices, roughly halving throughput and adding latency. A dual-band router that uplinks on 5 GHz and serves clients on 2.4 GHz avoids this. On a slow hotel connection you will not notice; on a decent one you very much will.
Portal credentials. The room number, voucher, password or checkbox the venue expects.
A device with a working browser. A phone or laptop to run the setup and complete the portal flow. Bear in mind that some portals are built for mobile browsers and behave badly elsewhere — if one method fails, try the other before assuming the relay is broken.

Step-by-Step Configuration Guide

1. Connect and Access the Router’s Admin Interface

Do this part before you leave, or at least before you need the connection. Configuring a travel router for the first time in a hotel lobby while your meeting starts is how people end up giving up and tethering.

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, or 10.0.0.1 depending on the model.
Log in with your admin credentials.

If the router still has its factory admin password, change it now. You are about to attach this device to a network full of strangers, and travel router default credentials are printed on the underside of the case and in every manual online. Also disable remote/WAN administration if the firmware offers it — on a relay, the WAN side is the hostile network.

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.

Expect the router to report the uplink as “connected” while you still have no internet. That is correct and it is the portal doing its job — the router has an IP address and a DHCP lease, it simply is not allowed past the gateway yet. Some firmware will show this as a connectivity failure and retry the association in a loop, which is noise rather than a fault. Move on to the authentication step.

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 adds your router’s MAC address to the allowed set. Because all your devices are behind the router’s NAT, they get internet access immediately — no further action needed.

Why neverssl.com rather than any other site: it serves plain HTTP and sets no HSTS policy, so your browser will genuinely send an unencrypted request the gateway can intercept and redirect. Almost every popular site now redirects to HTTPS and, having been visited before, is pinned by HSTS in your browser — the request never leaves as plain HTTP, so the portal has nothing to hijack and you get a connection error instead of a login page. If neverssl.com is unavailable, the OS probe endpoints work for the same reason: http://captive.apple.com or http://connectivitycheck.gstatic.com/generate_204.

Advanced Tactics: MAC Cloning & Evading Detection

Some hospitality and campus networks actively look for relayed connections, usually to enforce a per-device charging model. The two common detection methods are TTL analysis and passive OS fingerprinting via DPI — one host emitting traffic that looks like four different operating systems is not subtle.

Both techniques below are ordinary networking, and both have legitimate uses: keeping a paid session alive across a device change, or presenting a stable identity on a network where you are entitled to be. Neither is a way past an access control you were never granted, and on a network you do not own, check the acceptable use policy first. “It was technically possible” is not a defence anyone has ever found persuasive.

MAC Address Cloning

Some portals bind the session to the MAC that authenticated it, which is a problem if you authenticated on your phone first, or if the venue’s system recognises router OUIs and treats them differently. Cloning presents the router’s WAN interface with the MAC that already holds the session:

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.

Step 2 is not optional. If both the phone and the router present the same MAC on the same segment simultaneously, the gateway’s ARP table flips between two ports and connectivity becomes intermittent for both — a failure that looks like a flaky access point rather than a duplicate address, which is why it wastes so much time. Keep the phone’s Wi-Fi off for that network, or forget the network on the phone entirely.

Adjusting TTL Values (OpenWrt / Custom Firmware)

Every router that forwards a packet decrements its TTL by one. Because operating systems use recognisable initial values — 64 on Linux, macOS and iOS, 128 on Windows — traffic arriving at the gateway with a TTL of 63 or 127 has passed through exactly one extra hop, and that is the simplest possible relay detector. Setting a fixed outgoing TTL removes the tell.

The exact value to set depends on where in the packet path your firmware applies the rule relative to the forwarding decrement, which varies between kernels and rule placements. The rule below uses 65, which is the conventional choice; verify rather than assume, by capturing on a second device on the host network and checking what TTL actually arrives. Note also that Windows clients start at 128, so a mixed set of devices behind the relay will still emit two distinct TTL families unless you normalise them all.

On OpenWrt with iptables:

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 — on OpenWrt in WISP mode this is frequently wlan0 but can be wlan1 or a sta interface, and applying the rule to the wrong one silently does nothing. Check with ip link first.

Worth knowing what this does and does not achieve. TTL normalisation defeats the crudest hop-count check. It does nothing about passive OS fingerprinting, where the gateway infers device types from TCP options, window sizes and User-Agent strings, and a single “device” generating iOS, Android and Windows signatures simultaneously remains obvious to anything doing DPI. If you are running a VPN on the relay — which you should be — that fingerprinting surface largely disappears anyway, since the venue sees one encrypted tunnel rather than a mix of client traffic. The VPN is the better answer to this problem, and the TTL rule is a supplement to it.

Securing Your Relayed Network

Getting connected is the easy half. The relay gives you an inbound boundary; it gives you nothing outbound, and the venue’s network still carries every packet you send.

Run a VPN on the router. WireGuard is the right default — it handles roaming and interruption far better than OpenVPN, which matters on hotel Wi-Fi that drops constantly, and it is light enough for travel router hardware where OpenVPN can saturate the CPU and cap you at a few megabits. Configure the tunnel before you travel; setting up keys over an unauthenticated network is exactly the wrong order.
Turn on the kill switch, or accept that there isn’t one. This is the failure mode that catches people. When the VPN drops — and on a portal network it will, at every session timeout — most router configurations quietly fall back to routing traffic in the clear. Nothing alerts you, the connection appears to keep working, and your devices carry on transmitting over the venue’s network unencrypted. OpenWrt-based firmware can enforce this with a firewall rule that only permits WAN-bound traffic through the tunnel interface. Set it, then test it by stopping the tunnel and confirming that traffic actually stops.
Use encrypted DNS. DoH or DoT on the router — Cloudflare’s 1.1.1.1 and Quad9’s 9.9.9.9 both support it — stops the venue logging or redirecting your lookups. One sequencing catch: the captive portal itself depends on hijacking DNS, so encrypted DNS configured before authentication will prevent the portal from ever appearing. Authenticate first, then enable it, or configure the router to fall back to the venue’s resolver until the portal is satisfied.
Isolate the guest devices. If the reason for the relay is a console or a smart TV, put those on a separate SSID or VLAN from your laptop. You have built a trust boundary against the hotel; there is little sense in leaving your work machine sharing a flat segment with an IoT device that has not had a firmware update since 2021.

Troubleshooting Common Issues

1. The Captive Portal Won’t Load

Cause: Almost always one of three things, and they compound. Your browser is enforcing HTTPS-only mode or has the site pinned by HSTS, so no plain HTTP request ever leaves. Encrypted DNS — DoH in the browser, or DoT configured on the router — is bypassing the resolver the portal needs to hijack. Or the router itself is set to a public DNS server, so the portal’s redirect never fires.

Fix: Work through them in order. Turn off DoH in the browser (Firefox and Chrome both enable it in some configurations by default) and any custom DNS on the router, so DNS goes to whatever the venue’s DHCP handed out. Then request something guaranteed to be plain HTTP: http://neverssl.com, or an OS probe endpoint like http://captive.apple.com. If that still fails, browse to the WAN-side gateway address directly — you can find it in the router’s status page as the address its WAN interface received by DHCP. Failing all of that, connect a phone to the venue network directly, complete the portal there, and then clone that phone’s MAC onto the router.

One more thing worth checking before you conclude the portal is broken: private or randomised MAC addresses. iOS and Android randomise per-SSID by default, and if you authenticate with a randomised MAC and then the device rotates it, the session detaches and the portal reappears as though you had never logged in.

2. Devices Keep Disconnecting

Cause: Portal sessions expire — commonly at 24 hours, sometimes after a much shorter idle period. The symptom is confusing because the Wi-Fi association stays up: your devices remain connected to the router, the router remains associated to the venue, and only the internet stops working.

Fix: Re-authentication is unavoidable when the session genuinely expires, and worth planning around if you rely on this for anything overnight. Idle timeouts are easier to defeat: a small cron job on a connected device pinging 8.8.8.8 every few minutes keeps the session marked active. Note the interaction with a router-based VPN — when the portal session drops, the tunnel drops with it, and unless you have configured the kill switch described above, traffic silently resumes in the clear at that moment rather than stopping. That is the specific scenario the kill switch exists for.

3. IP Subnet Conflicts

Cause: Your relay router’s LAN subnet overlaps the venue’s — both on 192.168.1.x is overwhelmingly the common case, since it is the factory default of nearly every consumer router ever sold. The router then cannot tell which side of itself an address belongs to, and traffic for the overlapping range never leaves.

Fix: Move your LAN to something nobody else uses: 10.50.50.1/24 or similar. Avoid 192.168.0.x, 192.168.1.x and 192.168.8.x entirely, since they are the defaults of consumer gear, GL.iNet travel routers and a large share of hotel systems. Change this once, before you travel, and you will never see the problem again. Also check that your VPN’s tunnel subnet does not collide with either network — that variant produces a connection that works for everything except the specific resources you needed the VPN for, which is a considerably more confusing afternoon.

Conclusion

The relay solves two problems that look like one. It gets browser-less devices onto a portal network, and it puts a NAT boundary between your kit and everyone else in the building. Only the second of those is a security control, and on its own it is a partial one — it stops inbound scanning and does nothing whatever about the venue seeing your traffic.

The configuration that actually holds up has four parts, and three of them are the ones people skip: WISP mode with your own DHCP; a LAN subnet chosen so it will never collide; WireGuard on the router with an enforced kill switch that you have tested by stopping the tunnel; and encrypted DNS enabled after the portal is satisfied rather than before. Build it at home, where a mistake costs you an evening rather than a working day, and it becomes something you plug in and forget.

The failure mode to keep in mind is the quiet one. Portal sessions expire, tunnels drop with them, and unless something is enforcing the boundary your devices carry on transmitting in the clear across a network full of strangers — with no error, no warning, and a connection that appears to be working fine.