VPN Split Tunneling Was Enabled, but My Meeting Still Used the Wrong Route

The video call froze while the file upload continued.

That would have been annoying on any afternoon. On this one, it threatened to delay a product launch.

I was working from a hotel near Frankfurt Airport. A client needed to approve a revised training video before its European support team came online the following morning.

The 2.8 GB file was uploading through an SFTP client.

The client was reviewing it with me in a video meeting.

I had configured split tunneling so the file-transfer application used the VPN while the meeting application used the hotel’s direct connection.

That was exactly what the settings screen showed:

SFTP client: Use VPN

Meeting application: Bypass VPN

The upload reached 38%.

The meeting audio broke into fragments.

Then the client disappeared.

My VPN still showed Connected.

The SFTP transfer was still moving.

I blamed the meeting application first.

I closed it, reopened it and joined again.

The client returned and said:

Your connection is showing a different country now. Did you move?

I had not moved from the desk.

The meeting application was supposed to bypass the VPN, yet its diagnostics showed the VPN exit address.

I removed the application from the exclusion list, added it again and restarted the connection.

For two minutes, the audio improved.

Then the meeting’s sign-in page opened in my browser, and the browser triggered a new-location check.

The upload stopped.

The client asked:

Are we still getting the file tonight?

Split tunneling was switched on.

The workflow was not splitting as neatly as the interface suggested.

One application was not one network path

Split tunneling sounds simple:

Send one application through the VPN.

Let another use the ordinary internet connection.

On Windows, however, the result ultimately depends on routing decisions. Certain destinations are sent through the VPN, while others use the physical network interface. (Microsoft Learn) Android can instead include or exclude selected applications from the tunnel, but changing those lists requires the VPN connection to be rebuilt. (Android Developers)

The problem is that modern applications rarely work alone.

A meeting app may depend on:

• a separate helper process; - an embedded browser for sign-in; - the operating system’s DNS service; - background notification components; - media relays selected after the call begins.

Browsers add another complication. Chromium-based browsers use a shared network service for DNS, proxy handling, sockets, cookies and connections across tabs and processes.

So excluding one visible application did not necessarily exclude everything that application needed.

The meeting window could use the hotel connection while its login page, DNS request or media service still followed the VPN.

That explained why the settings looked correct while the client still saw the wrong country.

More importantly, it changed my next step. Re-adding the same application would not fix dependencies the menu did not show.

My first fix only moved the failure

I excluded the browser too.

The meeting login stopped showing the VPN location.

For a moment, that looked like progress.

Then the client portal refused to open.

The portal required the protected route I had been using for the project. Once the entire browser bypassed the VPN, both the meeting sign-in page and the sensitive client portal travelled over hotel Wi-Fi.

I could preserve the meeting login.

Or I could preserve the protected portal session.

I could not separate two websites inside the same browser by excluding one executable.

I tried using a second browser for the portal.

That created another chain of small problems.

The file-transfer link opened in the default browser instead of the protected one.

When I copied it manually, the portal requested another authentication code.

The upload reached 54%.

Then the hotel Wi-Fi hesitated.

The VPN reconnected.

The transfer displayed:

Connection reset by peer

The file had to start again.

Split tunneling had not reduced the number of moving parts.

It had turned every part of the job into a routing decision I had to remember.

DNS was obeying a different boundary

I ran one more test.

With the meeting application excluded, its visible public IP address matched the hotel connection.

But one of the client’s service names still failed to resolve unless I disabled split tunneling completely.

That pointed to DNS.

An application’s main traffic can use the direct connection while its request to find a service address still follows the VPN’s resolver. The application has internet access, yet it cannot locate the destination it needs.

Users run into the same half-working state when an exclusion appears correct but local services or internal names remain unavailable until DNS and LAN access are restored. (Reddit: r/ProtonVPN)

That was the detail I had missed.

The application rule, destination route, DNS path and local-network permissions could all follow different boundaries.

The interface reduced them to a single checkbox.

I had eighteen minutes before the client’s final approver left.

I could keep debugging the checkbox.

Or I could stop dividing a workflow whose parts were designed to work together.

More control was no longer helping

My regular VPN was a well-established service.

It had years of public history, a large support operation and detailed controls for applications, IP addresses, protocols and local-network access.

Those controls were useful when the boundaries were clear.

Mine were not.

I tried an include-only configuration so that only the SFTP client used the VPN.

The file server connected.

The client portal did not.

I added the browser.

The meeting login returned to the VPN route.

I excluded the meeting application again.

The call joined, but its media connection failed after the hotel moved the laptop to another access point.

Every adjustment required another connection restart.

The feature was giving me control.

It was not giving me continuity.

By then, the client had stopped discussing the video and started discussing whether to postpone the launch review.

That changed my criterion.

The best setup was no longer the one that let me route the greatest number of applications separately.

It was the one that kept the actual task working without requiring me to map every hidden dependency first.

The smaller app treated the workflow as one task

I had OnlydogVPN installed as a backup.

The service has fewer locations than the established provider, a shorter public history and fewer independent reviews. That matters when someone needs a particular city or the broadest possible record of external testing.

I did not need another city.

I needed the meeting, portal and file transfer to remain usable together.

Instead of asking me to build another application list, the app organised its choices around situations. I selected the preset for a work call with a large transfer on shared Wi-Fi.

It established one protected route.

I did not assign separate rules to the browser, meeting application and SFTP client.

I reopened the client portal.

It loaded.

I restarted the upload.

Then I rejoined the meeting.

The client’s video appeared.

The audio was clear.

For several minutes, I waited for one part of the workflow to break the others.

The upload passed 20%.

Then 40%.

The hotel Wi-Fi briefly lost quality.

The meeting image softened.

The audio continued.

The transfer speed fell to zero for several seconds.

The protected connection recovered.

The meeting remained open.

The upload resumed from the same point.

At 71%, the browser requested a document preview from another client domain.

It loaded without another routing rule.

At 93%, the hotel shifted the laptop to a different access point.

The cursor paused.

The call did not close.

The transfer reached 100%.

I refreshed the client portal.

The final video appeared.

The approver watched the revised section, checked the subtitles and said:

Approved. Publish this version.

The task that had made split tunneling urgent was complete.

I had not found the perfect exclusion list.

I had stopped needing one.

The technical difference was one coherent route

The service uses HTTP/3-based transport with additional traffic obfuscation. Its connection recovered from the hotel network’s brief interruptions before the applications discarded their sessions. (RFC 9000)

The visible result was simple:

The Wi-Fi hesitated.

The protected route recovered.

The call stayed open.

The upload continued.

I could not observe every internal routing and filtering decision made by the hotel network, the applications or either VPN service. I could observe which arrangement preserved the workflow.

The established provider separated the visible applications but left me managing the dependencies between them.

The smaller app carried the connected task through one route.

For that deadline, keeping the workflow coherent mattered more than controlling every process separately.

The phone solved the next friction

Once the file was approved, I needed to leave for the airport.

The client might send a final publishing confirmation while I was in the taxi, and I wanted the project chat available on my phone.

The smaller service allowed me to link the second device using a verification code.

I approved the code from the laptop.

The phone connected without another conventional email-and-password setup.

That feature had not saved the upload. The primary task was already complete.

It solved what came next.

I closed the laptop, opened the project chat on the phone and left the hotel Wi-Fi.

The phone moved to mobile data.

The protected connection recovered.

A few minutes later, the client wrote:

The new version is live.

I did not have to reproduce the split-tunneling rules on another device.

The working setup followed the task instead.

What I now check when split tunneling “doesn’t work”

I no longer assume the visible application represents all of its network activity.

First, I define what I am actually trying to separate.

Is it one application?

One website?

A private company subnet?

A local printer or server?

Those are different routing problems.

Then I check the operating system.

On Windows, destination routes may matter more than the application name. (Microsoft Learn)

On Android, the application must be in the correct allow or deny list when the VPN connection is established. (Android Developers) Changing the list means rebuilding the tunnel.

Next, I test DNS.

If an excluded application can reach the internet but cannot resolve a service name, its data and DNS may be following different paths.

I check local-network access separately too. Excluding an application does not automatically restore access to a printer, NAS or internal DNS server.

With browsers, I avoid treating one executable as one website. The same shared network service can handle authentication pages, redirects, sockets and several tabs at once.

Finally, I ask whether splitting is necessary at all.

When a meeting, browser portal and large upload belong to one workflow, keeping them on a stable route can be more useful than maintaining a growing collection of exceptions.

My established provider still offered more granular controls, more server locations and a longer support history.

Those advantages did not complete the review while DNS, browser authentication and helper processes kept crossing the boundaries I had drawn.

The smaller service offered fewer manual routing decisions, but its task-based connection kept the meeting, portal and upload alive together.

Split tunneling had promised to separate my applications. The better result came from recognising that the work itself was never separate.