My Commercial VPN Could Hide the Airport—It Couldn’t Take Me Home to My NAS

The client’s message arrived while I was waiting to board: “We need the original master, not the compressed preview. Can you send it before the presentation?” The 3.8-gigabyte file was sitting on my NAS at home. I joined the airport Wi-Fi, opened the address I used in my study and watched the browser time out. I blamed the public network, turned on my commercial VPN and selected a server near home. The page still did not open.

The client’s presentation began in forty-two minutes.

My laptop contained the edited preview. The full-resolution master remained on a box six hundred miles away.

The VPN showed Connected.

The NAS remained unreachable.

I changed servers twice, then selected the country where my house was located. Nothing changed.

That was when I realised I had been treating every VPN as though it led to the same place.

It did not.

The address worked only inside my house

At home, I reached the NAS through an address beginning with 192.168.

That address felt permanent because I used it every week. From the airport, however, it had no route back to my study. Addresses in the 192.168 range are reserved for private networks and can be reused inside millions of unrelated homes and offices. They are not unique destinations on the public internet. (IETF)

My commercial VPN had encrypted the laptop’s connection and sent it to the provider’s server.

It had not joined the laptop to my home network.

Selecting a server near my house changed where my ordinary internet traffic emerged. It did not turn the provider’s data centre into my router or make the private NAS address available.

The same misunderstanding appears in public user discussions: a paid VPN may protect browsing, but it does not automatically create a route into a home NAS. (Reddit)

The word VPN described both tools.

The destination separated them.

That distinction led me back to a decision I had made months earlier.

I had deliberately stopped exposing the NAS

I used to reach the NAS through a public web address.

It was convenient. It also meant leaving a login page exposed to the internet, which became harder to justify as new NAS security advisories appeared.

QNAP’s current guidance advises owners not to connect a NAS directly to the internet. It recommends disabling UPnP, DMZ and ordinary port forwarding, then using protected remote-access methods instead. (Qnap) A February 2026 advisory covering several File Station vulnerabilities reinforced my decision to update the system and close the old public route. (Qnap)

I had not removed remote access.

I had replaced the exposed login page with a VPN server running at home.

That server had one specific job: accept an authorised connection from my laptop and place it inside the private network where the NAS lived. QNAP’s own QVPN service is built for that purpose—remote access to the NAS and other resources on the home network. (Qnap)

The setup was safer and more deliberate.

It was also useless if I opened the wrong VPN application.

The NAS VPN finally put the files in front of me

I searched the laptop for the remote-access profile I had created after closing the public port.

There it was, named with all the imagination of someone configuring network software after midnight:

HOME-NAS-FINAL

I disconnected the commercial service and opened the home VPN client.

The profile connected.

I returned to the same 192.168 address that had failed moments earlier.

The NAS login page appeared.

After authentication, the familiar folders opened: projects, invoices, camera archives and the client directory I needed.

The master file was inside a folder marked DELIVERY, beside two versions I had promised myself I would rename later.

I checked the modification date, selected the newest file and began downloading it to the laptop.

Twelve percent.

Twenty-eight.

Fifty-one.

The transfer continued because the NAS VPN was doing what the commercial VPN could not: extending my home network to the laptop at the airport.

When the download finished, I opened the file and checked the first and final frames.

It was the correct master.

I had reached home.

Now I had to send the file in the opposite direction.

Leaving the NAS VPN on created a long detour

I opened the client’s delivery portal and began uploading.

The estimate immediately climbed past an hour.

My home VPN profile sent all laptop traffic through the house. That meant the upload was travelling from the airport to my home and then back out to the client.

That route was necessary while I needed the private NAS.

It made no sense after the file was already on the laptop.

So I disconnected the NAS VPN.

The private folders disappeared.

The downloaded master remained.

The two jobs were finally clear:

The NAS VPN had retrieved a private file from a private network.

A commercial VPN now needed to protect the upload across the airport’s public Wi-Fi.

I returned to the established provider and selected its automatic route.

The estimated upload time fell to eighteen minutes.

For a moment, the problem seemed solved.

Then the airport Wi-Fi disappeared.

Protection was not enough when the transfer restarted

My phone still had a mobile signal, so I enabled its hotspot.

The laptop switched networks.

The established VPN displayed Reconnecting, and the client portal froze at 43 percent.

When the connection returned, the portal reported that the transfer had failed.

I restarted it.

At 19 percent, the laptop noticed the airport Wi-Fi again and switched back. The VPN reconnected. The upload stopped for a second time.

The provider had years of public history, a mature application and a large server network.

None of those strengths changed the progress bar.

Each network switch created a fresh protected connection.

The client needed one upload that stayed alive.

A gate announcement called my boarding group.

I had fourteen minutes before the presentation and considerably less time before the laptop had to go back into my bag.

That was when I stopped thinking about server locations and opened the smaller backup.

The smaller app followed the transfer

The app did not begin with a country map. It asked what kind of connection I was dealing with.

I selected the preset for weak or changing networks.

The VPN connected, and I restarted the upload.

The progress bar reached 23 percent.

Then 43—the point where the previous attempt had failed.

I turned off the phone hotspot and let the laptop return to airport Wi-Fi.

The progress paused.

It continued from 43.

At 67 percent, the public Wi-Fi weakened again. I switched the hotspot back on rather than waiting for the laptop to decide.

The transfer paused a second time.

Then it resumed from 67.

Eighty-one.

Ninety-four.

Complete.

The client portal generated a thumbnail and displayed the full file size. I opened the preview, checked the final frame and pressed Deliver.

The client replied:

“Got it. Loading it into the deck now.”

The smaller app’s HTTP/3-based connection was designed to recover when a device changed network paths. In practice, the explanation was even simpler:

The laptop changed networks.

The upload did not return to zero. (IETF)

I could not inspect the client portal’s internal session rules or every routing decision made during the handoffs. I could verify the result: the established connection lost the upload twice, while the smaller app carried the same transfer across both network changes and completed it.

That was the difference the deadline exposed.

The phone joined after the real problem was solved

The client then asked whether the master matched the version approved on my phone the previous evening.

I had the approval message in the mobile project app, but the phone was not protected by the laptop’s connection.

With a conventional account-based VPN, I would have needed to retrieve another password, sign in and approve the device through email.

The smaller service displayed a verification code instead.

I entered it on the phone, connected and opened the project thread. The approved filename matched. I sent the confirmation.

That did not deliver the 3.8-gigabyte file. The network-recovery preset had already solved the urgent problem.

The code simply removed the next piece of friction once a second device became part of the task.

A minute later, boarding began.

I closed the laptop with the delivery receipt still visible.

The two VPNs were never substitutes

I kept the NAS VPN.

It remained the correct tool for reaching storage, backups and other private resources inside my home network. A commercial provider could not replace that route because its servers did not sit inside my house.

I also kept the smaller app.

Once the file left the NAS, the problem changed. I no longer needed a tunnel home. I needed a protected public connection that could survive the airport Wi-Fi dropping and the laptop moving onto mobile data.

The established provider protected the traffic but lost the active upload during both transitions.

The smaller app kept the transfer moving.

It has fewer server locations, fewer independent ratings and a shorter public history than the established service. That is its clearest limitation. At the gate, however, location count was not the useful comparison.

The NAS VPN ended at my home and retrieved the file.

The smaller commercial VPN stayed with the upload and delivered it.

At the airport, I needed both kinds of VPN—but only one had to follow the master all the way into the client’s presentation.