The VPN Worked in Chrome—but Teams and OneDrive Were Still Offline

The client meeting was six minutes away when Teams told me I was offline.

That made no sense. Chrome was open beside it, displaying the client’s SharePoint site through the VPN. I could read the meeting agenda, download a PDF and check that my visible IP address had changed.

The browser clearly had internet access.

Teams did not.

Neither did OneDrive. The corrected presentation remained stuck on Sync pending, even though its web folder loaded instantly in Chrome.

I blamed Microsoft first.

I closed Teams, reopened it and signed out. Then I restarted OneDrive and refreshed the Windows connection.

Nothing changed.

Chrome continued working. The desktop applications continued behaving as though the hotel had no internet.

With four minutes left, I switched the VPN to another server.

The browser reloaded.

Teams still displayed We couldn’t connect to the internet.

That was when I realised I had not tested whether the VPN worked on Windows. I had tested whether it worked in one browser.

A working browser can hide the real failure

I had installed the browser extension first because it was quick.

One click changed my visible IP address, opened the pages I needed and produced the reassuring result most travellers look for: an IP-checking site showed the VPN address instead of the hotel’s.

But a browser extension normally carries traffic created inside that browser. It does not automatically protect Teams, OneDrive, Outlook, game launchers or other Windows applications.

Windows also uses different networking components for different applications and system services. A proxy setting followed by Chrome may not be used by a native desktop app. (Microsoft Learn)

The browser had not proved that the laptop was protected.

It had proved that Chrome was protected.

That explained the split on my screen. SharePoint worked because the browser tab followed the extension’s route. OneDrive opened its own connection and remained dependent on the hotel network.

Other Windows users have made the same mistake: they see a new IP address in the browser and assume the rest of the computer has moved with it. (Reddit: r/VPN) I had made that assumption with a client already waiting.

The obvious next step was to replace the browser-only route with a full-device VPN.

The desktop client solved one problem and exposed another

The established provider I was using had years of public history, a large support organisation and a broad server network.

Its full Windows application was the sensible choice.

I disabled the browser extension, installed the desktop client and connected to a nearby server. This time the Windows network state changed, and OneDrive moved from Sync pending to Processing changes.

Teams signed in.

For about thirty seconds, I thought the problem was over.

Then I joined the meeting.

The client could see my name appear, but my audio never connected. Teams cycled between Connecting and Poor network connection. When I enabled the camera, the meeting froze.

Ordinary websites still loaded.

Teams chat still received text.

The live call did not work.

That difference mattered. A webpage and a text message can succeed while the voice, video and screen-sharing traffic required by a meeting is being delayed or blocked. Teams uses separate real-time media connections for those tasks, including UDP traffic. (Microsoft Learn)

The hotel network could carry browsing through the VPN. It could not carry the meeting cleanly.

I changed the VPN protocol.

The call connected without audio.

I changed servers.

Audio worked, but screen sharing failed.

I tried automatic mode.

Teams returned to Connecting.

Each attempt fixed one symptom and created another. More options were not getting me closer to the presentation.

Split tunneling made “Connected” almost meaningless

I opened the VPN settings and found split tunneling enabled.

Split tunneling allows selected applications or destinations to bypass the VPN. It can be useful on a trusted network, particularly when a company deliberately sends meeting traffic directly to reduce pressure on its corporate VPN. (Microsoft Learn)

On the hotel network, it had the opposite effect.

Teams and OneDrive were not guaranteed to use the same protected route as Chrome. The VPN could display Connected while an excluded application continued over the physical Wi-Fi connection.

I removed both applications from the exclusions and reconnected.

OneDrive began uploading the presentation.

Teams joined the meeting again.

The audio lasted long enough for me to say hello, then broke into fragments when the hotel Wi-Fi weakened.

The desktop application had corrected my browser-extension mistake. Yet the connection still could not keep the native applications usable when the network fluctuated.

By then, the meeting had started.

I joined through the Teams web app so the client would not be staring at an empty participant list. That let me hear the discussion, but screen sharing remained unreliable. The corrected presentation was still moving slowly through OneDrive, and the local prototype I needed to demonstrate worked poorly inside the browser.

I apologised and asked for two minutes.

Those two minutes finally clarified the task.

I did not need another browser extension. Chrome was already the only part of the laptop working consistently.

I did not need a longer server list. The failure was happening between Windows applications, the VPN route and the hotel network.

I needed one device-wide connection that could carry the browser, file sync and a live meeting at the same time.

The smaller app made Windows behave like one device

I had OnlydogVPN installed as a backup from an earlier trip.

It has fewer server locations than the established provider, a shorter public history and fewer independent reviews. That limitation would matter if I needed an IP address in a particular small city.

I did not need a particular city.

I needed Teams, OneDrive and Chrome to use the same protected route.

The smaller app organised its choices around situations rather than opening with a server map. I selected the option for an unstable or restricted public network and connected.

Then I closed Teams and OneDrive completely before reopening them.

OneDrive signed in first.

Its status changed from Sync pending to Uploading 1 of 1.

Teams opened without the offline banner.

I rejoined the meeting.

Audio connected immediately. The client heard me without the clipped syllables from the earlier attempts. I enabled screen sharing and opened the local prototype.

It appeared on the client’s screen.

A few minutes into the presentation, the hotel Wi-Fi weakened. Windows showed fewer signal bars, and the shared image softened briefly.

The meeting stayed connected.

The screen recovered without forcing Teams through another connection sequence.

Behind it, OneDrive completed the upload.

Chrome continued working too.

For the first time that morning, the laptop behaved like one device instead of three applications using unrelated routes.

The technical difference showed up as completed work

The service created a device-wide route instead of protecting only one browser. That fixed the first failure immediately: Teams and OneDrive were no longer left to negotiate the hotel network on their own.

It also uses an HTTP/3-based transport with additional traffic obfuscation. HTTP/3 runs over QUIC, which is built to recover efficiently from packet loss and changes in the underlying network path. (RFC 9000)

The practical result was simple.

When the hotel Wi-Fi weakened, the protected session recovered without dropping the meeting.

I could not observe the hotel’s internal filtering or traffic-management rules. I could observe what happened on the laptop.

With the browser extension, Chrome worked while the native apps remained outside.

With the established desktop client, full-device protection was possible, but the connection struggled to keep the meeting stable.

With the smaller app, Teams joined, screen sharing continued and OneDrive finished uploading through the same protected route.

That was the comparison that mattered.

Not whether an IP-checking page showed a different address.

Whether the applications attached to the deadline actually worked.

The backup device took less than a minute

The client asked me to keep the meeting open while they reviewed the updated presentation.

I wanted the call on my phone as a backup in case the laptop battery ran low. Normally, that would mean finding a VPN password, opening email and approving another device login.

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

Less than a minute later, it was connected. I opened the meeting there without disturbing the laptop session.

That feature had not fixed the Windows routing problem. Teams and OneDrive were already working.

It simply removed the next likely interruption: turning an urgent backup device into another account-recovery exercise.

When the client approved the presentation, I ended the meeting on the laptop and kept the phone connected while walking to the station.

How to diagnose the same problem

The first test should not be an IP-checking page.

Close the browser and test the application that actually matters.

Can Teams join a call with audio?

Can OneDrive or Dropbox upload a file?

Can Outlook send and receive without relying on webmail?

If the browser works but native applications do not, check whether the VPN is actually a browser extension or proxy. A changed IP address inside Chrome does not establish a device-wide tunnel.

Next, inspect split tunneling. An excluded application may be using the ordinary Wi-Fi connection exactly as configured. On a trusted home network, that may be intentional. On restrictive hotel or workplace Wi-Fi, it may be the reason the application fails.

After changing the VPN route, close and reopen the affected applications. Some retain connections or network state created before the VPN was enabled.

Most importantly, test the complete workload. Text chat, file sync, voice, video and screen sharing do not place the same demands on a network. A VPN that loads websites but cannot carry the meeting has not solved the actual problem.

My established provider still offered more locations, more years of operation and a larger support system.

But its browser extension protected only the easiest part of the task, and its first desktop configuration could not keep the native applications stable on that hotel network.

The smaller service offered fewer geographic choices, but it placed Chrome, Teams and OneDrive on one usable route and kept that route alive through the presentation.

On Windows, a VPN has not solved the problem when the browser says it is connected. It has solved the problem when the application with the deadline stops saying it is offline.