Why My Travel Router Failed at the Hotel Login—and Why the VPN Had to Come Second

The travel router said it was connected.

My laptop said it had Wi-Fi.

The browser said there was no internet.

I had arrived at a hotel in Boston with twenty-eight minutes before a client presentation. The router was supposed to make the evening simple: connect it once to the hotel network, and my laptop and phone would automatically rejoin the private Wi-Fi name they already knew.

Instead, every page timed out.

I blamed the router first.

I rebooted it.

I rescanned for the hotel network.

I entered the Wi-Fi password again.

The router’s admin page showed a strong signal and a successful repeater connection. My devices could reach the router, but the router could not reach the internet.

My established VPN profile had also started automatically on the router. It cycled through Connecting, Reconnecting, then Connecting again.

I changed the VPN server.

Nothing improved.

With twenty-three minutes remaining, I disconnected my phone from the travel router and joined the hotel Wi-Fi directly.

A login page appeared immediately.

It asked for my surname and room number.

That was the first useful clue: the hotel network was working. It simply had not authenticated the travel router.

The router had joined the Wi-Fi, not the internet

Hotel Wi-Fi often uses a captive portal. A device can connect to the wireless network and receive a local address while general internet access remains blocked until the guest accepts terms or enters room details. (RFC 8952)

That creates two different meanings of “connected.”

The travel router had joined the hotel’s access point.

The hotel had not yet allowed it onto the internet.

My always-on VPN made that distinction harder to see. It was trying to build an encrypted tunnel before the portal had authorized ordinary traffic. Custom DNS and router-level ad blocking were active too, so the hotel’s login redirect never reached my browser cleanly.

Travel-router vendors now include public-hotspot login modes for exactly this situation. These modes temporarily pause services such as VPN connections and custom DNS so the portal can appear.

I had reversed the required order.

I was trying to build the tunnel before opening the hotel’s gate.

Pausing the VPN exposed the portal

I opened the router’s admin panel.

First, I disabled the router-level VPN.

Then I paused ad blocking and returned DNS to automatic.

Finally, I enabled the public-hotspot login mode.

The router stayed connected to the hotel Wi-Fi, but stopped forcing every request through services that needed full internet access.

On the laptop, I opened a new browser window.

The hotel portal appeared.

I entered my surname and room number.

The page responded:

Unable to authorize this device

That felt like another failure, but it was progress. The hotel could now see the router’s request. It was rejecting the identity attached to it.

My phone, meanwhile, was already online because I had authenticated it directly. The hotel had recorded the phone as an authorized device.

The travel router had a different MAC address, so the network treated it as another device.

Some hotels authorize access by remembering the MAC address used during login. The router may place several personal devices behind one connection, but the hotel still sees the router’s upstream MAC as the device asking for access.

The portal was no longer hidden.

It was waiting for the right identity.

The hotel had authorized my phone, not the router

This is the part that makes travel-router troubleshooting feel irrational.

I had entered the correct surname.

I had entered the correct room number.

The hotel had already accepted both on my phone.

Yet the same details failed through the router.

The portal had not remembered only the credentials. It had associated the authorized session with the device that submitted them.

Travelers often solve this by authenticating a phone first, disconnecting it and then cloning that phone’s hotel-specific MAC address to the travel router. (Reddit: r/GlInet)

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

Then I disconnected the phone from the hotel Wi-Fi. I did not want the phone and router presenting the same address at the same time.

In the router’s repeater settings, I changed the upstream MAC from its factory address to the address the phone had used.

The router reconnected.

This time, the portal accepted the session.

A normal webpage loaded on the laptop.

Then another.

The router had not become more powerful. It was now presenting the identity the hotel had already authorized.

If that had failed, the next step would have been asking the front desk to whitelist the router’s own WAN MAC. But the urgent problem had moved forward.

The router finally had internet.

The presentation was now twelve minutes away.

Turning the large VPN back on created a new failure

My established VPN provider had years of public history, extensive documentation and many server locations.

I re-enabled its profile on the router and selected a nearby server.

The tunnel connected.

My laptop and phone both had protected internet through the router.

For a moment, the setup looked exactly as I had imagined it at home:

One hotel login.

One private Wi-Fi network.

One VPN connection covering every device behind it.

I entered the video meeting with four minutes to spare.

The client joined.

I shared the presentation and began explaining the revised launch schedule.

Seven minutes into the call, the hotel Wi-Fi weakened.

The router remained connected to the hotel, but its VPN tunnel entered Reconnecting.

Because the VPN was running at the router, every device behind it lost access at once.

The video froze.

The shared presentation disappeared.

My phone’s meeting chat stopped updating.

When the tunnel returned, the meeting application had removed me from the call.

I rejoined and apologized.

Three minutes later, another brief interruption forced the tunnel to rebuild again.

The client wrote:

Should we move this to tomorrow?

Tomorrow meant missing the approval window for the launch.

I had solved the portal problem, but now the entire room depended on one slow recovery point.

That changed the comparison.

“One VPN for every device” sounded efficient. For this meeting, keeping the presentation alive mattered more.

The smaller app let the router do one job

I had OnlydogVPN installed on the laptop as a backup.

The service has fewer server locations than the established provider, a shorter public history and fewer independent reviews. That limitation matters when someone needs an address in a specific city.

I did not need another city.

I needed the client call to continue.

I disabled the large VPN profile on the router and left the router doing the job it had finally learned: maintaining the hotel’s authenticated connection and providing my private local Wi-Fi.

Then I opened the smaller app directly on the laptop.

Its options were organized around situations rather than server geography. I selected the preset for a shared, unstable hotel network.

The protected connection came up.

I rejoined the meeting.

The client was still there.

I restored the presentation and continued from the approval slide.

A few minutes later, the hotel Wi-Fi dipped again.

The image softened.

My cursor stopped briefly.

Then the call continued.

The meeting application did not return to its home screen.

The presentation remained shared.

I reached the final budget page, answered two questions and uploaded the revised file.

The progress bar paused once, then continued from the same point.

The client opened the document and said:

Approved. We can launch in the morning.

The task that had made the hotel login urgent was complete.

The router maintained the authenticated hotel connection.

The endpoint VPN protected the laptop and recovered quickly enough to preserve the work happening on it.

The technical difference was a session that stayed alive

The service uses an HTTP/3-based transport with additional traffic obfuscation. Its QUIC foundation helps the connection recover when the underlying network path changes. (RFC 9000)

In the hotel room, the result was simple:

The upstream Wi-Fi hesitated.

The protected route recovered.

The meeting remained open.

The upload continued.

I could not observe the hotel’s internal portal policies or every routing decision between its access points and internet provider. I could observe what happened on the laptop.

The router-level VPN turned a short upstream interruption into an outage for every connected device.

The smaller app kept the interruption inside the existing laptop session.

For that presentation, recovery on the device doing the work mattered more than forcing the entire room through one tunnel.

Adding the phone did not require rebuilding the router

After the meeting, I wanted the approved-document chat available on my phone while I went downstairs for dinner.

The smaller service let me link the phone through a verification code.

I approved the code from the laptop and connected the phone without creating another conventional account or searching for a password.

This feature had not fixed the captive portal or completed the presentation. Those tasks were already done.

It solved the next friction naturally: the router could remain logged into the hotel while each important device received its own protected connection.

When I left the room, the phone moved between the floor’s access point and the lobby Wi-Fi.

The protected route recovered.

The client’s final message arrived:

Launch is scheduled. Thanks for getting this through tonight.

The hotel-login sequence that now works

I no longer start by changing VPN servers.

First, I confirm the hotel’s exact Wi-Fi name with the front desk.

Then I connect the travel router to that network in repeater mode.

If the router reports Wi-Fi but no internet, I assume a captive portal is waiting.

Before opening it, I temporarily disable:

• the router-level VPN; - custom or encrypted DNS; - router-level ad blocking; - any kill switch blocking ordinary traffic.

If the router has a public-hotspot login mode, I enable it. This gives the captive portal a clean path to the browser.

Next, I connect the laptop or phone to the router’s private Wi-Fi and open a browser.

If the portal appears, I complete it through the router.

If the hotel has already authorized my phone but rejects the router, I disconnect the phone and clone its network-specific MAC address to the router. Alternatively, I ask hotel staff to whitelist the router’s WAN MAC.

Once an ordinary webpage loads, the router has internet rather than merely a Wi-Fi association.

Only then do I activate the VPN.

For time-sensitive hotel work, I now protect the devices carrying important sessions instead of automatically placing the entire router behind one tunnel. That keeps portal authentication separate and prevents a single router-level reconnection from taking everything offline.

Finally, I test the task that matters.

I start the call.

I keep the shared document open.

I upload a file for several minutes.

A successful speed test does not prove that the session will survive the hotel’s next interruption.

My established provider still offered more countries, a longer track record and a larger support operation.

But running it before authentication hid the portal, while running it at the router afterward made every device depend on the same recovery process.

The smaller service offered fewer locations, yet its hotel-network preset kept the presentation and upload alive while the router maintained the hotel’s authorized connection.

My travel router had not failed because it lacked another VPN server. It failed because I asked it to build the tunnel before the hotel had opened the door.