Travel Router Captive Portal Setup: Why the Hotel Login Must Come Before the VPN

The travel router said it was connected.

Every device behind it said it had no Internet.

My daughter’s university interview started in twenty-two minutes. Her laptop was connected to the private Wi-Fi network I had created in our hotel room. My phone and tablet were connected too.

That was why I had packed a travel router: join the hotel network once, then give all our devices a familiar private network instead of connecting each one directly to the hotel.

The router had found the hotel Wi-Fi.

Its signal indicator was green.

The browser displayed No Internet.

I blamed the router first.

I restarted it, scanned for the hotel network again and re-entered the password printed on the room card. The connection returned, but the hotel login page never appeared.

I opened a private browser window.

Nothing.

I changed the DNS setting.

Still nothing.

Then I noticed the two mistakes I had made: the router’s VPN client was already active, and my phone had previously joined the hotel Wi-Fi directly.

The phone could browse.

The router could not.

I had authenticated the wrong device, then asked the VPN to protect a connection the router had not yet been allowed to use.

The hotel sees the router, not the devices behind it

A travel router joins the hotel Wi-Fi and creates a separate private network for the devices in the room. The hotel sees the router as its guest. The laptop, phone and tablet sit behind it.

That arrangement becomes useful after the router has Internet access.

Before that, it can be confusing.

My daughter’s laptop was successfully connected to the travel router, but that did not mean the router had passed the hotel’s captive portal. The hotel still needed the upstream device—the router itself—to accept its terms or complete its login.

Captive portals begin with restricted access. They allow enough local connectivity to display an authentication page, but block normal Internet use until the guest completes it. (RFC 8908)

My VPN profile was trying to reach an external server before the hotel had released the connection. The custom DNS setting made matters worse by avoiding the local route the portal expected.

The setup had trapped itself:

The VPN needed Internet.

The hotel required portal authentication before providing Internet.

The browser could not reach the portal through the unfinished VPN route.

The router was not broken.

I had started with the final step.

Authenticating the phone first made the problem harder to see

I paused the router’s VPN and returned DNS to automatic.

The portal still did not appear.

Then I remembered what I had done immediately after entering the room: I had connected my phone directly to the hotel Wi-Fi and completed the login there.

The hotel had authorised the phone—not the travel router.

Many hotel networks remember the device identity used during authentication. Modern phones may present a private Wi-Fi address rather than their permanent hardware address, so the identity accepted by the hotel can be specific to that network.

I opened the hotel Wi-Fi details on my phone and found the private address it was using.

Then I opened the travel router’s repeater settings and cloned that address.

The router reconnected.

Its Internet indicator turned green almost immediately.

This time, I did not trust the icon. I opened a normal webpage from my daughter’s laptop.

It loaded.

The interview platform loaded too.

The practical lesson was clearer than the networking terminology: either authenticate through a device already connected behind the travel router, or make sure the router presents the identity the hotel has already authorised. Travellers dealing with hotel portals often arrive at the same small but decisive fix. (Reddit: r/GlInet)

We had Internet with fifteen minutes remaining.

Now we needed it to stay usable.

The familiar VPN turned each interruption into a new session

The established VPN I normally used had a long public history, a large support operation and servers across many countries.

On a stable home connection, it was dependable.

I connected its desktop app on the interview laptop and selected the nearest automatic server.

The interview test passed.

The camera worked.

The microphone worked.

Then the hotel Wi-Fi weakened.

The laptop remained connected to the travel router’s private network, but the router briefly lost its upstream connection. The VPN changed to Reconnecting.

When it returned, the interview platform had lost the microphone session.

I refreshed the page.

The browser requested camera and microphone permission again.

I tried another nearby server. It connected, but the test call developed short gaps whenever the hotel Wi-Fi hesitated.

The provider offered several protocols and a long server list. Under ordinary conditions, those options were useful.

With the interview approaching, they became more decisions:

Should I change the server?

Should I change the protocol?

Should I restart the browser?

Would another route survive the next interruption?

The travel router had already solved the captive portal. It had also placed all our devices on one private network.

The remaining problem was recovery. A brief loss of hotel Wi-Fi was still enough to destroy the protected session my daughter needed.

I stopped making the VPN part of the portal problem

I had OnlydogVPN installed on my laptop as a travel backup.

The service has fewer server locations than major providers, a shorter public history and fewer independent reviews. Those limitations would matter if I needed an address in a particular small city.

I did not need a city.

I needed the interview connection to recover before the browser gave up.

I left the travel router focused on the job it had completed: maintaining our private room network and handling the hotel’s authenticated connection.

On the laptop, I opened the smaller app and selected its preset for weak or changing public networks.

The connection came up without asking me to interpret a map or compare protocol names.

We reopened the interview test.

Audio was clear.

Video was stable.

With four minutes remaining, I moved the travel router from the desk to a shelf closer to the door, where the hotel signal was stronger. During the move, the upstream Wi-Fi disappeared briefly.

The laptop never left the router’s private network.

The protected connection paused.

Then it recovered.

The test call continued without requesting microphone access again.

My daughter joined the real interview.

About twelve minutes in, the hotel signal dipped once more. Her video softened, and the interviewer’s voice paused for less than a second.

The call stayed open.

She answered the final question, thanked the panel and closed the laptop herself.

No reconnection screen.

No repeated portal.

No request to rejoin the meeting.

The travel-router setup had finally done what I had brought it to do: one hotel login, one private network and one protected session that remained usable when the upstream Wi-Fi faltered.

The useful technical difference was recovery

The service uses an HTTP/3-based transport with additional traffic obfuscation.

HTTP/3 runs over QUIC, which is designed to recover efficiently when packets are lost or the network path changes. (RFC 9000)

In the hotel room, the result was straightforward:

The router lost the hotel signal.

The laptop remained connected to the router.

The VPN recovered.

The interview continued.

I could not observe the hotel’s internal portal, filtering or traffic-management rules. I could observe what happened when the same upstream connection failed.

The established service repeatedly rebuilt the protected session.

The smaller app restored it quickly enough that the interview platform remained usable.

That mattered more than which service produced the highest speed while the hotel Wi-Fi was behaving perfectly.

Adding the backup phone took less than a minute

After the interview began, I wanted my phone ready as a backup.

The hotel’s device limit no longer mattered because the phone could join the private Wi-Fi created by the travel router. But it still needed its own protected connection.

The smaller service let me link it using a verification code.

I displayed the code on the laptop, approved it on the phone and connected without retrieving another password or waiting for an account email.

That was not what made the captive portal appear. The router had already solved that problem.

It removed the next piece of friction. Had the laptop failed, my daughter could have moved to the phone without beginning another VPN setup while the interview panel waited.

We never needed the backup.

That was the best possible outcome.

The travel-router captive-portal sequence that worked

The reliable order is simpler than the troubleshooting makes it feel.

First, power on the travel router and connect a phone or laptop to its private Wi-Fi.

Open the router’s admin page and use repeater mode to join the hotel network.

Do not enable the VPN yet.

Keep DNS automatic and pause services that might prevent the local portal from loading. On routers with a public-hotspot login mode, use it while authenticating.

Open an ordinary webpage from a device connected behind the router. Complete the hotel login through that connection.

When the portal does not appear, reconnect the router to the hotel network and open a plain webpage again. If the hotel has already authorised another device, either authenticate the router separately or clone the exact private address used by that authorised device.

Confirm that ordinary Internet access works before activating the VPN.

Then connect the VPN on the devices that need protection.

Finally, test the real task rather than relying on green status indicators:

Can a video call survive a brief loss of hotel Wi-Fi?

Does a file upload continue?

Do messages arrive after the router reconnects?

Can a backup device join without another account-recovery process?

The established provider still offered more locations, a longer history and more conventional configuration choices.

Those strengths did not help while I was authenticating the wrong device or asking the VPN to connect before the portal had released the router.

The smaller service offered fewer geographic options, but once the router had completed its own job, its public-network preset kept the interview session alive and added the backup phone without another login detour.

A travel-router captive portal is not solved when every device shows the new Wi-Fi name. It is solved when the hotel recognises the router, the VPN starts afterward and the work continues when the hotel connection blinks.