What Is a VPN? What the 'Secure Tunnel' Actually Protects
Learn what a VPN is, how a virtual private network routes traffic through an encrypted tunnel, what it protects, and what a VPN does not hide or secure.
Using the internet normally means your device connects through a local network and an internet service provider before reaching websites and online services. That connection exposes certain information along the way, including the public IP address your connection uses to reach the internet.
A VPN, or Virtual Private Network, changes that route. Instead of sending traffic directly toward its destination, your device establishes an encrypted connection to a VPN server. Traffic covered by that connection travels through the VPN first and then continues toward the wider internet or a private network, the same basic routing shift explained from another angle in VPN vs proxy.
This encrypted connection is commonly described as a VPN tunnel.
Without VPN
Device ────────► Internet ────────► Website
With VPN
Device ═════ encrypted tunnel ════► VPN server ───► Website
This architecture can protect traffic on untrusted networks, hide your normal public IP address from destination websites, and allow remote users to securely reach private company resources. But a VPN does not make someone anonymous or automatically secure everything they do online. It changes where trust and visibility sit in the connection.
A Virtual Private Network Creates a Private Connection Over Another Network
The name becomes easier to understand when separated into its three parts.
Virtual means the network connection is created in software rather than requiring a dedicated physical cable between the two locations. Private refers to the protected communication established between authorized endpoints, while network reflects the fact that the connection can carry network traffic just like another network interface.
Imagine an employee working from home who needs to reach an internal application that is not exposed directly to the public internet. The employee still uses their ordinary home internet connection, but VPN software can create a protected route across it to the organization’s network.
The public internet provides the underlying transport. The VPN creates the protected logical connection on top of it, which is the same broader model behind IPsec VPNs.
That same principle is used by consumer VPN services, although the destination is usually a provider-operated VPN server rather than an employer’s private network.
The VPN Server Becomes an Intermediate Point
Suppose your normal connection looks like this:
Your device
│
▼
Local network
│
▼
Internet provider
│
▼
Website
When you connect through a VPN, the route changes:
Your device
│
║ encrypted VPN connection
▼
VPN server
│
▼
Website
From the website’s perspective, the network connection now appears to originate from the VPN server rather than directly from your normal public internet connection.
That explains several VPN features at once. Your device has a protected connection to the VPN server, the destination sees the VPN server’s public IP address, and the VPN provider becomes an important intermediary in the traffic path.
A VPN is therefore not simply an encryption switch. It changes the network route.
The “Tunnel” Is a Useful Mental Model
VPN documentation frequently describes traffic as moving through a secure or encrypted tunnel. There is no literal tunnel through the internet; the term describes how traffic is encapsulated and protected between VPN endpoints, a concept also summarized in Cloudflare’s VPN explainer.
At a simplified level, your device has some network data it wants to send. VPN software protects that traffic according to the VPN protocol and sends it across the existing network to the VPN server. The server processes the protected traffic and forwards the appropriate communication toward its destination.
The return path works in reverse.
This creates a protected section of the journey:
Device VPN server Destination
│ │ │
├════════════►│ │
│ encrypted ├──────────────────────────►│
│ tunnel │ │
│ │◄──────────────────────────┤
│◄════════════┤ │
The distinction between those sections matters. The VPN tunnel normally protects traffic between your device and the VPN server. It should not be interpreted as a magical encrypted pipe extending unchanged from your device through the VPN provider and all the way into every destination system.
Encryption Protects Traffic Across the VPN Connection
One of the central functions of a VPN is encryption.
Before traffic covered by the VPN is sent across the local network, the VPN software encrypts it using the protocol’s cryptographic mechanisms. Someone observing that portion of the network should not be able to casually read the original contents, which is the same confidentiality goal discussed in SSL certificate chains.
The VPN server has the necessary cryptographic state to process the protected traffic and forward it appropriately.
This is especially useful when the network between the user and VPN server should not be trusted. Instead of relying on every intermediate network to keep the traffic private, the VPN creates its own protected layer.
Modern websites already use HTTPS to encrypt web traffic, so a VPN is not the only encryption protecting typical browsing. The two operate at different layers and solve overlapping but different problems.
A VPN Hides Your Normal Public IP Address From Websites
Every internet connection needs addressing so responses can get back to the correct destination.
Without a VPN, a website normally sees the public IP address associated with the network from which your connection reaches it.
With a VPN, the destination generally sees the public IP address of the VPN server instead.
For example:
Without VPN:
Website sees → your network's public IP
With VPN:
Website sees → VPN server's public IP
This is what people usually mean when they say a VPN hides your IP address.
More precisely, it hides your ordinary public IP address from destinations reached through the VPN and replaces it with an address associated with the VPN exit point.
That is useful for privacy, but it should not be confused with complete anonymity.
An IP Address Is Only One Way You Can Be Recognized Online
Changing the visible IP address does not erase every other identifier.
A website may still know who you are because you logged into an account. Cookies can recognize a returning browser, while applications may send identifiers associated with an existing session. Browser and device characteristics can also contribute to tracking techniques.
Consider someone who connects to a VPN and then signs into the same personal account they use every day. The service may no longer see their normal public IP address, but it still knows which account has logged in.
So:
VPN ≠ anonymity.
A more accurate statement is that a VPN can reduce some forms of network-level visibility and prevent destination sites from directly seeing your ordinary public IP address.
Privacy is broader than IP masking.
Untrusted Networks Are an Important VPN Use Case
Public networks create an obvious trust problem.
When you connect through Wi-Fi at an airport, hotel, café, or conference, you do not necessarily know who operates every part of the network or how well it has been configured.
A VPN can create an encrypted connection through that local network to a trusted VPN server.
Laptop
│
▼
Untrusted Wi-Fi
│
║ encrypted VPN traffic
▼
VPN server
Someone observing the local network may be able to tell that your device is communicating with a VPN server, but the VPN is intended to prevent them from simply inspecting the original traffic carried inside the tunnel.
This was particularly valuable when much more web traffic traveled without HTTPS. Today, HTTPS already provides substantial protection for normal web browsing, but VPNs can still add network-level protection and cover traffic according to the VPN’s routing configuration.
HTTPS and VPNs Protect Different Parts of the Journey
It is easy to treat HTTPS and VPN encryption as interchangeable, but their endpoints are different.
HTTPS generally protects communication between an application such as your browser and the HTTPS service it is contacting. A VPN protects network traffic between the VPN client and VPN endpoint.
That can result in encryption being layered:
Your device
│
│ VPN protection
▼
VPN server
│
│ HTTPS remains protected
▼
HTTPS website
The VPN provider may be able to observe destination-related information and other network metadata depending on the protocol and traffic, but properly configured HTTPS still protects the web session’s contents between the browser and website, a boundary also emphasized in MDN’s HTTPS overview.
This is one reason HTTPS remains essential even when a VPN is active. A VPN should not be used as a substitute for normal application-level encryption.
A VPN Changes Who You Need to Trust
Without a VPN, your internet provider occupies an important position in your network path. When you add a consumer VPN, some of that visibility and trust moves toward the VPN provider.
Your ISP can see that you are communicating with the VPN service, but traffic inside the tunnel is protected from ordinary inspection by the ISP. The VPN server, meanwhile, is responsible for forwarding your traffic toward its destinations.
This creates an important question that VPN marketing sometimes glosses over:
Do you trust the VPN provider?
A VPN provider can potentially have substantial visibility into connection metadata, and the exact information available depends on protocols, encryption at other layers, DNS configuration, service architecture, and logging practices.
Using an unknown VPN does not eliminate trust. It can simply transfer trust from one intermediary to another.
DNS Requests Matter Too
When you enter a domain such as example.com, your device usually needs the Domain Name System to determine where that domain can be reached.
A VPN configuration may send DNS queries through the VPN to DNS infrastructure chosen by the VPN service or organization. This helps prevent those lookups from bypassing the protected route.
A poorly configured system can experience a DNS leak, where ordinary traffic uses the VPN but DNS requests still go somewhere outside the intended tunnel, which matters because the same domain-resolution step is covered in what a URL is.
That can reveal information about which domains the device is attempting to resolve.
Good VPN implementations therefore need to think about more than simply routing browser packets. DNS behavior, IPv6 routing, local-network access, and other networking details can all affect what actually travels through the VPN.
A Kill Switch Can Reduce Exposure When the VPN Disconnects
VPN connections occasionally fail.
The device may change networks, enter sleep mode, lose Wi-Fi, or temporarily lose contact with the VPN server. Without additional controls, network traffic might fall back to the ordinary internet connection during that interruption.
Some VPN applications provide a kill switch to prevent this, a feature category also described in Proton VPN’s kill switch guide.
Its basic purpose is:
VPN connected
│
▼
Traffic allowed through VPN
VPN disconnected
│
▼
Traffic blocked
rather than sent normally
This is useful when maintaining the VPN route matters more than maintaining uninterrupted connectivity.
The exact behavior varies between products and operating systems, so users relying on such a feature need to understand what it actually blocks and under which failure conditions.
Consumer VPNs and Corporate VPNs Often Solve Different Problems
When people hear “VPN,” they often think of consumer privacy services. But VPN technology has long been used to connect employees and private networks.
A corporate VPN might allow a remote employee to reach:
Internal dashboard
Private database tools
Company file services
Development systems
Administrative interfaces
without exposing all of those resources directly to the public internet.
The employee first establishes an authenticated VPN connection. Once connected, the device can receive routes that allow it to communicate with approved private network resources.
The goal here is not primarily to hide the employee’s IP address from public websites. It is to extend controlled access to a private network across an untrusted network such as the internet.
Remote Access Is Why the “Private Network” Part Matters
Imagine a company has an internal application available only at a private network address. Employees in the office can reach it because their computers are already connected to the corporate network.
A remote employee cannot normally route directly to that private address from home.
A remote-access VPN creates a path:
Remote employee
│
║ VPN
▼
Company VPN gateway
│
▼
Private company network
│
▼
Internal application
After authentication, the employee’s device can communicate with permitted internal systems through the VPN.
This creates the experience of being connected to part of the organization’s private network even though the physical connection crosses the public internet.
Authentication and authorization still matter. Being connected to a VPN should not automatically mean a user has unrestricted access to every internal system.
VPNs Can Connect Entire Networks, Not Just Individual Devices
VPNs are also used for site-to-site connections.
Suppose a company has offices in Auckland and Singapore. Each location has its own private network, but systems in both offices need to communicate securely.
Rather than requiring every employee to start a VPN client manually, network gateways can establish a protected connection between the sites.
Traffic can then travel:
Office A network
│
║ encrypted site-to-site VPN
▼
Office B network
This allows private networks in different physical locations to communicate across public infrastructure.
The same principle is common in cloud environments, where organizations may create VPN connections between on-premises networks and virtual private networks hosted by cloud providers.
VPN Protocols Define How the Tunnel Works
“VPN” describes the general networking concept rather than one single protocol.
Different VPN technologies define how endpoints establish connections, authenticate, exchange keys, encrypt traffic, and encapsulate packets. Examples encountered in modern environments include WireGuard, IPsec-based VPNs, and OpenVPN, with the WireGuard documentation providing one concise example of a modern protocol design.
The technical differences can affect performance, compatibility, configuration complexity, and security properties.
For an ordinary user, the provider or operating system often handles those details automatically. For network administrators, however, protocol choice and configuration are important because a secure concept can still be deployed insecurely.
Strong cryptography does not compensate for stolen credentials, weak authentication, exposed management interfaces, or careless configuration.
Not All Traffic Has to Use the VPN
A VPN can be configured so that all appropriate internet traffic travels through it, but that is not the only option.
With split tunneling, some traffic uses the VPN while other traffic uses the normal connection.
A corporate configuration might look conceptually like this:
Internal company traffic ──► VPN
Public internet traffic ───► Normal connection
This can reduce load on corporate VPN infrastructure and avoid sending unrelated traffic through company systems.
The trade-off is that the device is simultaneously communicating through different network paths. Organizations need to decide whether that fits their security model.
A full-tunnel configuration instead routes much more of the device’s traffic through the VPN endpoint.
Neither approach is universally correct; the appropriate design depends on why the VPN exists.
A VPN Can Make Your Apparent Network Location Different
Because websites generally see the VPN server’s public IP address, IP-based geolocation may associate the user with the location of that server rather than the user’s normal network.
If someone in one country connects to a VPN server in another, a website using IP-based location estimates may believe the connection originates near the VPN server.
This is why VPNs are sometimes used to access services from a different apparent network location.
However, IP addresses are not the only location signal available to applications. A device may expose GPS location with permission, an account may contain a known region, and services can use other signals when determining location or eligibility.
A VPN changes the network exit point. It does not physically move the device.
A VPN Does Not Automatically Make Dangerous Activity Safe
The word “secure tunnel” can create a false sense that everything happening through it is secure.
A VPN cannot make a malicious download harmless. It cannot stop someone from entering credentials into a convincing phishing site, repair an outdated operating system, prevent every browser exploit, or guarantee that an online service handles personal data responsibly.
If you download malware through a VPN, you still downloaded malware.
Likewise, if you visit an attacker-controlled website over an encrypted connection, encryption protects the communication with the attacker-controlled website. It does not make the site trustworthy.
A VPN addresses particular network risks. Endpoint security, authentication, software updates, HTTPS, access control, and safe user behavior continue to matter.
The VPN Server Can Become a Performance Bottleneck
Routing traffic through an additional server has a cost.
Without a VPN, traffic may take a relatively direct route to its destination. With one enabled, packets first have to travel through the VPN endpoint.
The VPN also has cryptographic work to perform.
As a result, VPN performance can be affected by server distance, server load, available bandwidth, protocol overhead, encryption performance, and the quality of the underlying connection.
A nearby well-provisioned VPN server may introduce little noticeable delay. A congested server on another continent can make browsing or downloads substantially slower.
The trade-off is inherent in the architecture: traffic is taking an additional protected route for a reason.
Free VPN Services Still Have to Pay for Infrastructure
Running VPN servers costs money. Providers need bandwidth, compute resources, networking infrastructure, software development, maintenance, and security operations.
That does not mean every free VPN is automatically malicious, but it does mean users should understand the service’s business model.
A provider handling sensitive network traffic is a poor place to make a decision based solely on which app has the biggest “Connect” button.
Important considerations include who operates the service, what information it says it collects, how long data is retained, what security technologies are used, whether claims have been independently examined, and how the service is funded, which is why CISA’s guidance on using public Wi-Fi securely still focuses on the broader security model rather than treating a VPN as magic.
The central issue returns to trust. A VPN provider occupies an important position in the connection, so its incentives and practices matter.
“No Logs” Is More Complicated Than It Sounds
VPN services often advertise a “no logs” policy.
That phrase needs context because services can collect different kinds of information. There is a difference between recording the full browsing activity associated with a customer and retaining operational data needed to manage infrastructure.
Claims can involve connection timestamps, bandwidth usage, account information, server diagnostics, source addresses, destination information, or other metadata.
What matters is precisely what is collected, whether it can be associated with an individual user, how long it is retained, and under what circumstances it can be disclosed.
A marketing phrase by itself does not answer those questions.
For privacy-sensitive use, the provider’s actual architecture and data-handling practices are more meaningful than the word “private” in the product description.
VPNs Improve Privacy, Not Anonymity
This is one of the most important distinctions to keep clear.
A VPN can improve privacy by encrypting traffic between your device and the VPN endpoint and by preventing destination websites from directly seeing your normal public IP address.
But you can still reveal your identity through accounts, cookies, payment information, browser behavior, application data, or information you deliberately submit.
The VPN provider itself also becomes part of the privacy model.
A more realistic comparison is:
| Without a VPN | With a VPN |
|---|---|
| Destination sees your normal public IP | Destination generally sees VPN server IP |
| Local network sees ordinary network connections | Local network sees protected VPN traffic |
| ISP handles traffic without a VPN intermediary | ISP sees connection to VPN; VPN becomes intermediary |
| HTTPS still protects HTTPS websites | HTTPS still matters beyond/within VPN routing |
A VPN changes who can observe particular pieces of the connection. It does not make every participant blind.
The Secure Tunnel Is the Key Idea
Despite all the extra details, the basic VPN model is straightforward.
Your device establishes a protected connection with a VPN endpoint. Traffic assigned to that connection is encrypted before crossing the intervening network, processed by the VPN endpoint, and then routed toward the appropriate destination.
That gives us the essential path:
Your device
│
║
║ encrypted VPN tunnel
║
▼
VPN server
│
├────────► Public internet
│
└────────► Private network
For consumer use, that can hide the user’s normal public IP address from destination sites and provide additional privacy from the local network. For organizations, the same basic technology can provide secure remote access to internal resources or connect private networks across different locations.
The boundaries matter just as much as the benefits. A VPN does not guarantee anonymity, does not replace HTTPS, and does not protect a device from every security threat.
A VPN is best understood as a protected network route: it creates an encrypted tunnel between your device and a VPN server so traffic can cross an untrusted network without being exposed in the same way as an ordinary direct connection.