What a VPN Protects, What It Doesn’t, and When to Use One
For non-engineers deciding whether a VPN is the right security control. This guide explains where a VPN sits in your network, what threats it actually reduces, what it cannot fix, and how to choose between a VPN, HTTPS, zero-trust access, and private networking.
TL;DR — A VPN (virtual private network) creates an encrypted tunnel between your device and a VPN server, which protects traffic from local network snooping and can make your traffic appear to come from the VPN server’s location. It does not automatically make you anonymous, stop malware, secure the website you visit, or protect data after it leaves the VPN server; the single most important takeaway is: use a VPN for network path protection and private access, not as a general-purpose "security blanket." Reading time: ~7 min
What it is and where it sits
A VPN is a service or appliance that sits between your device and the rest of the network. Instead of your laptop or phone sending traffic directly to a website or internal company system, it first sends that traffic through an encrypted tunnel to a VPN server (a machine that accepts VPN connections and forwards traffic).
In plain terms, a VPN changes who can see your traffic on the way out.
Without a VPN:
- your device talks directly to your Wi‑Fi router, ISP (internet service provider), and then the destination service
- people operating the local network can often see which services you connect to, and sometimes more if the traffic itself is not encrypted
With a VPN:
- your device still uses the local Wi‑Fi and ISP
- but the local network mostly sees a connection to the VPN server, not each destination inside the tunnel
- the VPN server then talks to the destination on your behalf
This means a VPN is best understood as a network path control. It does not replace HTTPS (web encryption), app logins, endpoint security, backups, or access control. It sits alongside them.
Where it lives in a typical request flow
There are two common setups:
- Consumer or remote-worker VPN: your device connects to a VPN server on the internet, then out to websites or SaaS tools.
- Site-to-site or private-access VPN: your device or office network connects to a company/cloud VPN gateway, then into private systems like a database, admin panel, or internal API.
View as text
[Your Device] ---- 1. VPN tunnel ----> [VPN Server/Gateway] [Your Device] ---- 2. local Wi-Fi/ISP ----> [Local Network] [VPN Server/Gateway] ---- 3. HTTPS/API ----> [Website or Internal App] [Local Network] ---- sees tunnel only ----> [VPN Server/Gateway]
What it replaces in the flow is the direct path from your device to the destination. What it does not replace is:
- TLS (transport layer security; the lock icon in the browser)
- your app’s login/session controls
- firewall rules on the destination
- antivirus/EDR (endpoint detection and response; device security software)
A useful mental model: a VPN is like using a secure courier bag for the first leg of delivery. It protects the package while it is in that bag. Once the package is handed off, other protections still matter.
How it actually works
A VPN works by creating a virtual network interface on your device and sending selected traffic through an encrypted tunnel to a VPN server. The device and server authenticate each other, agree on encryption keys, and then wrap normal network packets inside protected VPN packets.
Common protocols include:
- WireGuard: modern, simpler, fast
- IPsec/IKEv2: common in enterprise and device operating systems
- OpenVPN: older but still widely used
You do not need to memorize the protocols to make decisions. The important part is what changes in practice:
- your device gets a VPN-assigned IP address (internet address)
- your routing table (the device’s map of where traffic goes) changes
- some or all traffic is sent to the VPN server first
- DNS (the system that turns names like
example.cominto IP addresses) may also be sent through the VPN, if configured correctly
One realistic end-to-end example
Let’s say you are on hotel Wi‑Fi and need to open your company’s internal admin app at https://admin.internal.example, which is only reachable over the company VPN.
Step by step:
- You open the VPN app and click Connect.
- Your device authenticates to the company VPN gateway using a certificate, SSO (single sign-on), or username/password plus MFA (multi-factor authentication).
- The VPN app creates a tunnel and installs routes so traffic for the company private network, such as
10.20.0.0/16, goes into that tunnel. - Your browser requests
admin.internal.example. - DNS resolves that name to a private IP, for example
10.20.5.12. If DNS is not sent through the VPN, this step may fail or leak the internal hostname to the local network. - Your browser sends packets to
10.20.5.12, but your device routes them into the VPN tunnel instead of to the hotel router directly. - The hotel network sees encrypted traffic between your device and the VPN gateway. It does not see the internal app request contents.
- The VPN gateway decrypts the traffic and forwards it inside the company network to the admin app.
- Your browser and the admin app still use HTTPS/TLS. This matters because traffic is now outside the VPN tunnel on the company side and still needs application-level encryption and server identity checks.
- The app responds; the response goes back through the gateway, into the tunnel, and back to your device.
What was protected here:
- the traffic between your device and the VPN gateway from local eavesdropping
- access to a private network that is not exposed to the public internet
What was not magically solved:
- if your laptop is infected with malware, the VPN will happily tunnel the malware’s traffic too
- if you type your password into a fake phishing page, the VPN does not stop that
- if the internal app itself is vulnerable, the VPN does not fix the app
- if DNS is misconfigured and leaks outside the tunnel, names you look up may still be visible to the local network or ISP
When to use it (and when not to)
Use a VPN when the problem is about trusted network paths or private network reachability. Do not use it as a substitute for app security or identity controls.
| Scenario | Recommendation |
|---|---|
| Staff need to reach private admin tools, databases, or internal APIs from outside the office | Yes, a VPN is a good fit, especially with MFA and narrow routing |
| Team members use public Wi‑Fi and you want to reduce local network snooping risk | Yes, a VPN helps, especially if some apps still use non-web protocols |
| You want to hide traffic from the local ISP or network operator | Yes, partially; they will mostly see the VPN connection, not each destination |
| You want websites to stop tracking you | No, not by itself; sites can still track via logins, cookies, browser fingerprinting, and behavior |
| You want to secure access to one web app for contractors | Maybe not; a reverse proxy or zero-trust access product is often simpler than full-network VPN |
| You want to protect data already stored in SaaS tools or databases | No; use encryption at rest, access control, audit logs, and backups |
| You want faster internet | Usually no; a VPN often adds latency and can reduce throughput |
| You need branch office to cloud VPC private connectivity | Yes, site-to-site VPN is common unless you need higher bandwidth/consistency than dedicated links |
You probably don’t need this if...
- all the systems you use are already public SaaS apps over HTTPS, with MFA enforced
- your goal is "be anonymous online" rather than "protect traffic on this network path"
- you only need to publish one internal web app; a tightly controlled application gateway may be easier to operate
- your main risk is stolen passwords, phishing, or compromised laptops; a VPN does little for those compared with MFA, device management, and endpoint security
Trade-offs
Every VPN benefit comes with a cost.
-
Benefit: protects traffic on untrusted local networks
Cost: added latency (extra travel time for packets), possible speed loss, and another service that can fail -
Benefit: lets users reach private systems without exposing them publicly
Cost: client setup, certificate/key management, support burden for remote users, and lockout risk when VPN auth breaks -
Benefit: central egress point (traffic appears from one place)
Cost: the VPN provider or your VPN server becomes a trust bottleneck and a potential single point of failure -
Benefit: can reduce some DNS and destination visibility from local networks
Cost: only if configured correctly; split DNS and DNS leaks are common operational footguns -
Benefit: network segmentation (only connected users can reach private ranges)
Cost: complexity in routing, firewall rules, overlapping IP ranges, and troubleshooting "it works on office Wi‑Fi but not at home" -
Benefit: quick way to connect offices or cloud networks
Cost: bandwidth ceilings, tunnel flaps, and more operational overhead than native private networking or dedicated circuits
A practical warning: VPNs often become a comfort blanket. Teams say "it’s behind the VPN" and then underinvest in app-layer security. That is backwards. Sensitive apps should still have HTTPS, strong auth, least-privilege authorization, logging, and patching.
In practice
Below are two concrete examples you could adapt.
Example 1: WireGuard client config for private app access
[Interface]
PrivateKey = REPLACE_WITH_CLIENT_PRIVATE_KEY
Address = 10.20.0.10/32
DNS = 10.20.0.2
[Peer]
PublicKey = REPLACE_WITH_SERVER_PUBLIC_KEY
Endpoint = vpn.example.com:51820
AllowedIPs = 10.20.0.0/16, 10.30.0.0/16
PersistentKeepalive = 25
This sends only the private company networks 10.20.0.0/16 and 10.30.0.0/16 through the VPN, which is called split tunneling. The gotcha: if you expected all internet traffic to use the VPN, this config does not do that; it only covers those private ranges, so public web browsing still goes out normally.
If your provider gives a UI instead of a file, the path is usually something like: VPN/Networking → Users or Devices → Add client → Download config. Import that file into the WireGuard app and click Activate.
Example 2: Full-tunnel WireGuard config for all traffic
[Interface]
PrivateKey = REPLACE_WITH_CLIENT_PRIVATE_KEY
Address = 10.99.0.10/32
DNS = 1.1.1.1
[Peer]
PublicKey = REPLACE_WITH_SERVER_PUBLIC_KEY
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25
This routes all IPv4 and IPv6 traffic through the VPN. The gotcha: if the VPN server is not configured to forward traffic to the internet and perform NAT (network address translation; rewriting source addresses), users may lose internet access entirely when they connect.
Example 3: Check whether your public IP changes after connecting
curl https://ifconfig.me
Run this before and after connecting to the VPN. If the returned IP does not change when you expected full-tunnel behavior, your traffic is probably not going through the VPN.
Example 4: Check DNS behavior on a typical desktop OS
nslookup admin.internal.example
This checks whether your internal hostname resolves while connected. The gotcha: successful resolution alone does not prove there is no DNS leak; it only shows that some DNS server answered. In a managed setup, ask your IT team which DNS server should answer internal names and compare the result in your OS network details.
⚠️ If you change a live VPN from split tunnel to full tunnel, users can lose access to the internet or to local office/home devices such as printers. Schedule the change, test with one user first, and keep a rollback config file ready.
Further reading
- WireGuard Quick Start
- OpenVPN Community Documentation
- RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2)
- NIST Zero Trust Architecture (SP 800-207)
- The "Secure Contexts" and HTTPS sections of the MDN Web Docs
This article was written by an AI system and published pending human review. Verify anything you intend to act on.
Have a project in mind?
Get an instant AI price estimate for it, or talk directly to our team.
One email a month on what we learn building with AI