VPN explained: encrypted tunnels, remote access and realistic privacy limits

What is inside the tunnel, and where does it end?

Consider a laptop connecting to a VPN gateway at an office. The laptop first needs a working underlying internet connection. VPN software then establishes the tunnel using the configured protocol and authentication. Traffic selected for the tunnel is carried to the gateway, which forwards it towards its destination according to the network’s rules. Traffic outside that selection can follow another path. The tunnel is a connection carried over the existing network; it is not a replacement for the broadband or mobile service.

For a consumer VPN, the remote endpoint is usually operated by the VPN provider. Internet services can see the provider’s outgoing address for traffic routed that way rather than the home connection’s public address. That does not prevent an account login, browser identifier or application from identifying the user. After traffic leaves the VPN endpoint, the VPN’s tunnel protection ends. HTTPS can separately protect the web connection. Keep HTTPS enabled and do not dismiss certificate warnings because a VPN is connected.

Work access, internet VPNs and site-to-site links are different uses

A remote-access work VPN gives an authorised device a route to specified private resources, such as an internal application or file service. A site-to-site VPN connects networks, normally through gateways, so individual devices may not each run a VPN application. A consumer internet VPN generally routes traffic through a provider’s internet exit. Installing a consumer app does not automatically grant access to an employer’s private systems. The correct server, account, device policy and permissions still come from the organisation.

Define the goal before choosing or troubleshooting a VPN. Is the requirement to open a private office application, connect two authorised sites or change the internet exit used by a personal device? Each needs a different endpoint and policy. Some organisations use application-specific remote access instead of a general network tunnel. That can be appropriate when only particular services should be exposed. Avoid treating a VPN as a way to grant every remote device unrestricted access to everything on a private network.

Split tunnel or full tunnel: which traffic actually uses the VPN?

With split tunnelling, selected routes or applications use the VPN while other traffic uses the ordinary connection. With a full or forced tunnel, the policy normally directs broader internet traffic through the VPN, although specific exceptions and more specific routes can still exist. This choice affects capacity, performance and security expectations. An application saying “connected” does not prove that every packet, DNS query or browser request is going through the intended endpoint.

On a managed device, the organisation should decide the policy. Sending a video meeting outside the tunnel may reduce gateway load, but it can also bypass monitoring or other protections. A local-access exception may permit a home printer while the work application remains tunneled. Neither setting should be enabled by guessing. Ask what is supposed to travel through the tunnel, what is deliberately excluded and how that has been verified. Do not infer the whole routing policy from a single public-IP lookup in one browser.

• Identify the application or destination that must use the VPN.
• Check whether the policy is device-wide, application-specific or route-specific.
• Account for both IPv4 and IPv6 where the network uses them.
• Confirm the intended DNS path as well as the traffic route.
• Keep local-access and split-tunnel exceptions under the responsible administrator’s control.

Why can the VPN connect while files, names or printers still fail?

A tunnel can be established while the destination remains inaccessible. Private names may need the organisation’s DNS server and search configuration. If those queries go to a public resolver, the private service may appear not to exist. Conversely, a full-tunnel policy or local-network block can stop a device reaching its home printer. Discovery methods used by printers and media devices do not automatically cross a routed tunnel. Seeing a VPN status icon therefore confirms only part of the journey.

Overlapping private address ranges are another specific cause. If the home network and remote office both use the same subnet, the device may try to reach a local address when the intended destination is remote. This needs a planned addressing or routing correction, not a random port-forwarding rule. Record the local subnet, the required remote subnet and the failing resource for the administrator. Do not publish those details with credentials. Temporarily comparing another authorised connection can help isolate overlap without redesigning the work network yourself.

Separate connection, authentication and resource-access failures

First establish the stage that fails. Does the device have ordinary internet access? Can it locate the configured VPN endpoint? Does the VPN reject the login, fail during negotiation or report connected? Once connected, does every required resource fail or only one? An authentication error can involve an expired account, an incorrect profile, an unanswered multifactor prompt or a device-compliance rule. A resource error can involve DNS, routes, firewall permissions or the application itself. Different stages call for different evidence.

Use the official client and the profile supplied by the responsible organisation or provider. Check the device’s clock and install supported updates through the normal trusted channel. Record the exact error, time, client version, endpoint name and connection used. Share logs through an authorised support channel after removing secrets and private data. Do not approve an unexpected multifactor request, accept an unverified certificate or disable security controls merely to make a connection indicator turn green. Repeated login attempts can also obscure the original failure.

• Internet works, VPN does not connect: inspect endpoint reachability, the approved profile and the exact negotiation error.
• Login rejected: inspect account status and the expected authentication process through the authorised administrator.
• VPN connected, private names fail: inspect the intended DNS server and suffix or name policy.
• VPN connected, one resource fails: inspect that resource’s route, permissions and service status.
• Only one underlying network fails: compare its addressing, filtering and connection stability.

Why a VPN may feel slow without being broken

Traffic may travel farther through a VPN endpoint before reaching the destination. Gateway load, the endpoint’s capacity, encryption processing and the underlying connection can all matter. A distant exit can increase latency even when download throughput looks acceptable. Weak Wi-Fi, packet loss or a busy upload link remains a problem beneath the tunnel. More encryption is not a substitute for a stable connection. There is no universal percentage by which every VPN must reduce speed.

Compare the same activity at similar times using the configuration that is authorised for your task. A public speed test may not measure access to the office application and, under split tunnelling, may not travel through the tunnel at all. If practical, compare a wired connection to the same router and record latency, dropouts and the affected activity. On a personal service, an approved alternative endpoint may help isolate distance or load. On a work VPN, do not change routes or protocols without the administrator’s guidance.

Using a VPN on hotel Wi-Fi or another shared connection

A shared network may require a captive-portal sign-in before it provides ordinary internet access. A VPN that blocks traffic outside its tunnel can interfere with that sign-in. Follow the approved portal procedure and confirm that you are joining the intended network. If the managed VPN prevents login, ask the organisation for its documented process rather than disabling protections at random. A VPN cannot authenticate an unexpected portal page for you. Do not enter unrelated account credentials into a page simply because the network requests them.

After access is established, confirm the VPN is connected before using resources that require it. Keep the operating system and applications updated and use the organisation’s approved authentication. A sudden disconnect, laptop sleep or a change from Wi-Fi to mobile data can require reconnection; behaviour depends on the client. Check the expected response rather than assuming protection continues. A personal VPN can add tunnel protection on a shared connection, but a secure website and a safe device remain necessary. Avoid leaving the device unattended with a session unlocked.

Choosing and maintaining a VPN without unrealistic privacy claims

A consumer VPN changes the parties involved in carrying your traffic. Read the provider’s ownership information, privacy policy, logging explanation, app permissions and update support. A claim such as “no logs” needs context: which data, which services and what retention? A subscription price or a reassuring badge alone does not demonstrate the policy. Obtain software from a trusted source and avoid profiles or root certificates from an unknown page. Do not hand a stranger account access to “optimise” the connection.

For private remote access, protect the gateway as a maintained system. Supported software, prompt security updates, individual accounts and appropriately configured multifactor authentication matter. Remove access for people and devices that no longer need it. Grant the minimum resources required and keep an authorised recovery method. A poorly maintained VPN gateway can become an entry point into the private network. The sensible question is whether the complete access arrangement is secure and supportable, not whether the tunnel uses a fashionable protocol name.

• Define the resources and users permitted to use remote access.
• Protect configuration files, private keys, recovery codes and account passwords.
• Retest required services after approved client or gateway changes.
• Keep a documented owner for access removal, updates and recovery.

Example: a work laptop connects, but the office file service is unreachable

Imagine a worker whose VPN client reports connected at home. Public websites work, but the office file service does not. The laptop can resolve a public name, while the private office name is being sent to a public DNS resolver and returns no answer. This is an illustrative scenario, not a claimed customer outcome. The tunnel exists; the name-resolution path needed by the private service is wrong. Reinstalling the router or opening broad firewall access would not address that particular cause.

The useful evidence is the exact private name, the configured resolver while connected, the client profile and whether another authorised device can reach the service. The organisation’s administrator can correct the approved DNS policy and confirm the route and resource permissions. The worker then retests the original file service as well as public browsing and any permitted local printer. The lesson is to verify the whole path from name resolution to application access. A successful tunnel handshake is only one checkpoint.