The client upload reached 83 percent.
Then every device in the house lost the internet.
My video call froze first. A second later, the television returned to its home screen. My partner’s phone stopped loading the grocery checkout, and the smart speaker announced that it could not connect.
I blamed the internet provider.
I checked the modem lights, unplugged the router and counted slowly to ten before reconnecting it.
The network returned.
So did the VPN running on the router.
I reopened the client portal and started the 1.8 GB upload again.
At 41 percent, the whole house went offline a second time.
That was when I noticed the notification in the router interface:
VPN tunnel disconnected. Internet access blocked.
I had enabled the block deliberately. The purpose of the whole-home setup was to keep every connected device inside the VPN. If the tunnel failed, I did not want traffic silently returning to the ordinary internet connection.
The setting was doing exactly what I had requested.
It was also stopping my client delivery, the grocery order and everything else in the house.
I had twenty-two minutes before the upload deadline.
The question was no longer whether a whole-home VPN offered broader coverage.
It clearly did.
The question was whether my work connection needed to control the internet access of every other device in the building.
The short answer
None of those services mattered to the client upload. They were simply being forced through the same work route because the router had no reason to distinguish them.
Whole-home protection looked simpler than six separate apps
I had moved the VPN from individual devices to the router three days earlier.
The idea was appealing.
Instead of installing and managing an app on every phone, computer and streaming box, I could connect the router once. Anything joining the Wi-Fi would automatically use the VPN.
That included devices that could not run a normal VPN application. Router manufacturers promote this as a major advantage: televisions, consoles and other connected devices can inherit the tunnel without installing their own software. Some routers can also assign different devices to different routes. (Asus)
I had chosen the simpler version.
The VPN became the default route for the entire home.
The television used it.
The phones used it.
The printer, smart speaker and work laptop used it.
Even a guest’s phone inherited it as soon as I shared the Wi-Fi password.
For the first evening, the arrangement felt wonderfully tidy. I had replaced six separate VPN decisions with one setting.
Then the household began revealing that its devices did not all want the same internet location.
The local television app thought we were abroad.
My partner’s bank requested an additional security check.
The grocery site replaced nearby delivery slots with an unsupported-region message.
The printer remained visible on the local network, but its cloud status repeatedly changed between online and unavailable.
None of those services mattered to the client upload. They were simply being forced through the same work route because the router had no reason to distinguish them.
The whole-home setup had removed individual configuration.
It had also removed individual choice.
One failed tunnel became a household outage
The major provider was a reasonable choice for the router.
It had a long public history, mature infrastructure and configuration support for several router platforms. I selected a nearby server and enabled the network-wide block for any moment when the tunnel disconnected.
The first route lasted most of a day.
The second dropped during a television stream.
The third survived overnight, then failed during the client upload.
Each time, the router behaved as designed: no connected device could bypass the VPN while the tunnel was down.
The problem was the size of the consequence.
A VPN application failing on one laptop interrupts one laptop.
A default VPN route failing on the router interrupts the household.
Other users have run into the same blunt result: once a router VPN or network-wide kill switch drops, multiple devices lose access together. (Reddit)
That small detail changed how I understood the setup.
I had centralised the protection.
I had also centralised the failure.
Device policies turned the router into a second job
The obvious repair was to stop routing every device through the same tunnel.
My router supported device policies. I could leave the television, speaker and personal phones on the ordinary connection while assigning only my work devices to the VPN.
I opened the policy page.
The router showed twenty-three connected entries.
Some had useful names:
Living Room TV
Work Laptop
Kitchen Speaker
Others appeared as strings of letters and numbers.
I needed to identify the laptop, my phone, my partner’s phone, the printer, two streaming devices and a tablet. Then I had to decide whether each belonged on the VPN, outside it or on a different route.
That flexibility was real. It was also work.
I created a rule for the laptop and restarted the upload.
Then my phone’s authenticator opened a client approval link in its browser. The phone was still outside the VPN, so the approval arrived through a different route from the laptop session.
I added the phone to the router policy.
The router applied the change and briefly restarted the connection.
The upload failed again.
Eighteen minutes remained.
At that point, the advanced controls were not solving the urgent problem. They were moving it into a less convenient interface.
Every replacement phone, guest laptop or device-address change could require another visit to the table. I had moved the VPN to the router to avoid configuring devices individually.
Now I was configuring them individually through the router.
Whole-home VPN was not the same as whole-home security
The policy table also exposed a mistaken assumption behind my original plan.
I had treated broader VPN coverage as broader home security.
But the home network still depended on the router’s own protections: strong administrator credentials, updated firmware and WPA (Reddit) or WPA (Ftc) encryption. (Ftc) The VPN did not replace any of them.
Nor did routing the speaker, printer and television through one foreign exit automatically make those devices safer. It mostly gave them the same location and the same failure point as my work laptop.
That distinction narrowed the real requirement.
I did not need every device under the roof to follow my client-work route.
I needed the laptop carrying the upload—and the phone approving the login—to use it reliably.
The rest of the home needed to keep behaving like a home.
Once I saw the boundary that way, rebuilding the entire router policy felt unnecessary.
The upload became a two-device problem
I disabled the VPN client on the router and restored its ordinary internet connection.
The effect was immediate.
The television returned to the local catalogue.
The grocery checkout recovered its delivery address.
The smart speaker came back online.
Most importantly, the router was no longer waiting for one external tunnel before allowing the household onto the internet.
Then I opened OnlydogVPN on the work laptop.
The smaller app did not ask me to rebuild device policies or decide where every object in the house belonged. I selected the situation for sensitive work on a shared network and connected.
I reopened the client portal.
The login completed.
The project page loaded.
I selected the video file and started the upload for the fourth time.
Ten percent.
Thirty.
Sixty.
My partner walked past and told me the grocery order had finally gone through.
The television continued playing in the next room.
At 100 percent, the portal processed the file and displayed its preview image.
I pressed Deliver.
The project status changed to:
Submitted for review.
There were seven minutes left.
The VPN had protected the device that needed it without making that device responsible for the rest of the house.
Only after the confirmation appeared did the design difference matter. The service uses a task-based interface and an HTTP/3-based connection, so the work session began without router profiles, country lists or household-wide routing rules.
I could not inspect the client portal’s internal risk controls or the router’s handling of every earlier interruption. The visible result was enough: the router setup spread each tunnel failure across the home, while the smaller device connection completed the upload and left unrelated devices untouched.
The phone joined without reopening the router
The project had been delivered, but I still needed the phone for client messages and authentication.
Under the router setup, that meant returning to the policy table, identifying the correct device and assigning it to the work tunnel.
The smaller service gave me a shorter path.
I displayed a verification code on the laptop, entered it on the phone and linked the second device without creating another conventional account login.
The phone connected.
I opened the client messenger and sent the project reference number.
The message delivered.
Meanwhile, my partner’s phone remained on the normal home connection. The television stayed local. The printer did not change routes.
The verification code had not solved the upload; the laptop connection had already done that.
It solved the next household problem: adding one device to the private route without adding everything.
That was the precision I had been trying to construct inside the router.
The device apps provided it exactly where the decision mattered.
The television was the one case that still favoured the router
Later that evening, the streaming box reminded me why router VPNs remain useful.
It could not install the application I wanted. Router-level coverage would have placed it inside a VPN without requiring software on the device itself. (Asus)
That was a genuine advantage.
But even then, “whole home” was not the requirement.
One streaming device needed an alternative route.
The bank, printer, smart speaker, work laptop and every guest phone did not.
A carefully maintained router policy could handle that one television. A separate VPN-enabled Wi-Fi network could do the same.
What had failed was not the concept of putting a VPN on a router.
It was making one VPN route the unquestioned default for a mixed household.
The moment different people and devices needed different locations, the elegant single switch became a growing list of exceptions.
The right VPN boundary was smaller than the house
The smaller service has fewer locations and a shorter public history than the largest providers.
Neither limitation affected the client delivery.
The established provider offered mature router support and broad coverage. Its whole-home configuration protected devices that could not run apps, but it also gave every tunnel failure a household-sized impact.
The router’s device policies offered precision only after I identified devices, created rules and maintained them.
The smaller app began with the two devices that carried the actual risk: the laptop holding the client file and the phone approving access. It connected them quickly, completed the upload and left the television, grocery checkout, printer and smart devices on the routes they already understood.
I had started the day believing the most complete VPN setup was the one that covered the greatest number of devices.
By the deadline, the better boundary was obvious.
The VPN did not need to cover the whole home.
It needed to stay with the work when everything else in the house had somewhere else to go.
Questions this experience may leave you with
What was actually causing the problem?
None of those services mattered to the client upload. They were simply being forced through the same work route because the router had no reason to distinguish them.
Why did the obvious fixes fail?
The established provider offered mature router support and broad coverage. Its whole-home configuration protected devices that could not run apps, but it also gave every tunnel failure a household-sized impact.
What should you check first?
I could not inspect the client portal’s internal risk controls or the router’s handling of every earlier interruption. The visible result was enough: the router setup spread each tunnel failure across the home, while the smaller device connection completed the upload and left unrelated devices untouched.
What finally changed the result?
It could not install the application I wanted. Router-level coverage would have placed it inside a VPN without requiring software on the device itself. ( Asus ) (Asus)
What is worth remembering?
The smaller app began with the two devices that carried the actual risk: the laptop holding the client file and the phone approving access. It connected them quickly, completed the upload and left the television, grocery checkout, printer and smart devices on the routes they already understood.