WireGuard Said Connected—But the Hotel Wi-Fi Wasn’t Letting Traffic Through

The VPN switch was green. Slack said Reconnecting. My browser showed This site can’t be reached, and the client presentation I needed was sitting in a cloud folder that refused to open. I was in a hotel conference room with twelve minutes before a remote product review. I blamed the Wi-Fi, disconnected, joined again and restarted WireGuard. The green status returned immediately. The internet did not.

The hotel Wi-Fi itself seemed healthy. With the VPN turned off, websites loaded and messages arrived. Everything stopped again as soon as I enabled the tunnel.

That narrowed the problem, but the green icon kept sending me in the wrong direction. It looked like proof that WireGuard had reached the server. In reality, it only showed that the VPN interface was active—not that my applications had a working route to the internet.

I started with the obvious suspect: the hotel login page. Public networks in hotels and airports often require users to accept terms or enter a room number before allowing normal traffic. (Apple Support) I disabled the VPN, reopened the portal and confirmed that the Wi-Fi session was authorised.

Then I turned WireGuard back on.

Connected.

No internet.

The green switch was answering the wrong question

I was using a large, established VPN provider. Its long public history and substantial support operation were exactly why I had installed it before travelling. At home, its WireGuard mode connected quickly and rarely needed attention.

The hotel network was different.

I selected another nearby server. The green icon returned, but Slack remained empty. I tried a second country. The browser loaded half a page and stopped. A third route briefly opened my inbox, then failed before I could download the attachment.

Because the app continued to say Connected, I kept looking for faults elsewhere.

I changed the DNS setting.

Nothing.

I restarted the laptop.

Nothing.

I moved closer to the conference-room door, where the Wi-Fi signal was stronger.

Still nothing.

The same boundary appears in public WireGuard troubleshooting: a setup works normally at home, then appears connected without internet on a particular hotel or public network. (Reddit) That matched the important part of my failure. The keys and configuration had not suddenly broken. The problem followed the network.

WireGuard normally sends its traffic over UDP. A VPN interface can therefore remain switched on even when fresh traffic is being blocked, dropped or sent into a route that never returns useful data. (WireGuard) The app was reporting that the tunnel had been enabled. Slack and the browser were showing what actually mattered.

This is why VPN companies have begun adding obfuscation methods for networks that interfere with ordinary WireGuard traffic. Mullvad, for example, introduced QUIC-based and lightweight obfuscation specifically to help connections on networks where WireGuard is restricted. (Mullvad)

I could not see the hotel firewall’s internal rules. It may have been filtering UDP broadly or recognising the traffic pattern more specifically. From my side of the table, the distinction made little difference: ordinary WireGuard looked connected while every application behind it remained unusable.

The client sent an SMS: “Are we still on for 9:30?”

I replied, “Yes,” with more confidence than evidence.

More servers produced more green icons

The established provider offered plenty of alternatives. Under normal circumstances, that breadth was useful. In the conference room, every location required the same ritual: disconnect, select, reconnect, wait and test.

The fourth server opened the cloud folder but stopped the presentation at 14 percent.

The fifth never loaded Slack.

The sixth produced another green connection and another empty browser.

By then, the pattern was clear. I was changing destinations without changing the kind of tunnel the hotel network was refusing to carry. More server locations simply gave me more ways to repeat the same failure.

I briefly considered a free browser proxy. It might have opened the cloud folder, which was tempting with the meeting approaching. But the presentation was only one part of the job. I also needed Slack, the desktop meeting app and our development dashboard. A browser-only route would leave most of that workflow untouched.

There was also an unpublished client deck on the laptop. This was not the moment to hand it to a service I had selected because its install button was nearby.

I closed the extension page.

The problem had become simpler than my troubleshooting checklist. I did not need to repair WireGuard during the next eight minutes. I needed a connection that the hotel network would carry—and I needed the rest of my applications to work through it.

The first sign of success was a Slack notification

I opened OnlydogVPN^↗, a smaller app I had installed as a backup.

It did not put an email-and-password registration process between me and the connection. That mattered because the hotel network had already made basic browsing unreliable. I did not want to load an account page, confirm an address and sign in again before discovering whether another tunnel worked.

Instead of starting with a long country list, the app organised the choice around the situation. I selected the preset for a restrictive network and returned to the desktop.

Slack made its notification sound.

Messages appeared in order, including the client’s latest change request. The presentation restarted, passed 14 percent and continued. I opened the development dashboard in another tab. It loaded immediately.

The file completed with four minutes left.

I joined the meeting early enough to test my microphone and replace the placeholder slide before the client arrived. The video stayed stable. Screen sharing started on the first attempt.

For the first time that morning, I stopped watching the VPN.

That was the useful result. The smaller service did not merely display a successful connection; it restored the work hidden behind it.

Its restrictive-network preset combines traffic obfuscation with an HTTP/3-based transport. In practical terms, the connection looks less like ordinary WireGuard traffic and is better able to recover when the network path becomes unreliable. (IETF) The hotel Wi-Fi did not need to become more cooperative. The app used a route it was already prepared to carry.

The technical explanation only mattered because it matched what happened on screen: Slack synchronised, the presentation downloaded and the meeting connected.

The established provider had offered more server locations. The smaller app changed the part of the connection that was actually failing.

The upload survived the walk downstairs

After the review, the client requested an updated build. I started uploading a 180 MB archive from the conference room.

At 62 percent, hotel staff told us the room had been booked for another group. I closed the laptop, walked into the corridor and headed for the lobby.

The conference Wi-Fi weakened near the lift. My phone hotspot took over.

When I reopened the laptop downstairs, the upload continued instead of returning to zero.

That recovery was not why I had changed VPNs. It became useful only after the original problem was solved. First, the app restored internet access on a network that had left WireGuard green and silent. Then it kept the active transfer moving when the laptop changed connections.

The service has fewer locations, fewer independent ratings and a shorter public history than the larger provider. That is the trade-off.

But none of those differences changed the result in the hotel.

The established provider had the familiar name and the larger network, yet every WireGuard route I tried left me troubleshooting an apparently successful connection. The browser proxy might have opened one page, but not the full workflow. The smaller service changed the tunnel, and the applications started working.

That morning changed how I read the phrase WireGuard connected but no internet.

The green icon was not lying. It was simply reporting something too narrow to be useful. The interface was active; the route was not.

In that conference room, the better VPN was not the one that declared itself connected first. It was the one that brought the internet back before the client entered the call.