How to set up a travel router behind a hotel captive portal
Authorize the venue first, then start the tunnel. Check client mode, DNS and what a downstream device gets, rather than trusting the router's status light.
Open the travel router's admin page and the temptation is to start the VPN immediately. The hotel network has other plans: your router is a client of the venue's Wi-Fi, and until that upstream connection is authorized, no tunnel can reach anything. Walk the two stages in order, and the router stops looking broken.
First, check the router can do both jobs
You need an upstream client mode, usually labelled repeater, client or WISP, and an outbound VPN client. Those are different features from a VPN server, and plenty of inexpensive routers ship the second and not the first.
In the admin page, find the WAN or internet section and switch it to the wireless client mode. Scan for the venue's SSID, join it, and let the router take an address before you configure anything else.
Confirm the firmware version while you are there. Menu names move between releases, and an old guide's path may no longer exist even though the feature does. Note the model and version with your travel kit. When a documented step does not match the screen in front of you, the version difference is almost always the reason.
Second, authorize the upstream connection
Connect a laptop to the router and open any HTTP page. The portal should redirect, and the venue's own procedure applies from there. Some portals work better from a phone than from a headless router, which is why doing this from a connected device is usually faster.
Strict VPN blocking can complicate this bootstrap. If the venue drops tunnel traffic before authorization, the VPN client on the router will fail while the portal is pending, and that failure is expected rather than a misconfiguration.
Use a supported method to get through it. Removing several controls at once, or installing a certificate a portal page offers as a repair, trades a temporary inconvenience for a permanent problem.
Third, start the VPN with a profile it supports
Once ordinary access works, start the router's VPN client with the profile it actually supports. A WireGuard configuration and an OpenVPN profile are not interchangeable, and neither can be imported into a native IPsec field.
Check three things before you trust it: the endpoint is reachable, the resolver answers with the expected value, and the egress address is the one you expect. The egress check is the only one that proves the tunnel is carrying traffic rather than merely being configured.
curl -sS https://ifconfig.me
cat /etc/resolv.confIf the router reports connected and the egress address is still the venue's, the tunnel is not carrying the traffic you think it is. Fix that before adding downstream devices to the picture.
Fourth, test from a downstream device
The router's status page describes the router's own connection. Make a fresh request from the laptop that is supposed to be covered, and check IPv4, IPv6 and the resolver separately, because a device can be covered for one family and not the other.
| Stage | What to verify | Where |
|---|---|---|
| Upstream join | Router has an address from the venue | Router WAN status |
| Portal authorization | A fresh request loads a public page | Connected laptop |
| Tunnel | Egress address changed | Router or laptop |
| Downstream coverage | Laptop resolves and reaches the private resource | Laptop |
If the laptop fails while the router succeeds, the problem is in the downstream path: NAT, DHCP, or a tunnel policy that only covers the router's own traffic. Check that the laptop holds an address from the router's pool, then check that its default gateway is the router. A device still holding a lease from the venue's DHCP server is on the wrong network entirely.
Fifth, decide the fallback and keep the login
Test what happens when the portal expires or the tunnel drops. The policy you chose has to cover forwarded traffic, not only requests the router makes itself, or a downstream device will quietly fall back to the venue's connection.
Keep the verified upstream login process with the router, on paper or in a local note. A restart at the next hotel becomes a two-minute task instead of another improvised setup. Keep a copy off the router as well, because a note stored only on the device is unavailable exactly when the device is the thing that failed. Paper still wins for this one.
Then write down the four values that made it work: upstream mode, portal procedure, VPN profile type, and egress check. Those four are what you will need next time, and they are the four that are hardest to reconstruct from memory.