VOIDPN / GUIDE
What is a VPN?
A VPN changes the route between a device and the internet. Understanding that route makes its protections and limits easier to evaluate.
A virtual private network, or VPN, creates an encrypted path between a device and a VPN gateway. It changes how selected network traffic leaves the device and which public IP address internet services see. It does not remove every source of identity, and it does not replace the security provided by HTTPS.
That definition is more useful when the route is made explicit. A VPN is not a privacy switch applied to all activity. It is a routing system with a protected first segment, a gateway that forwards traffic, and operational limits that depend on the device, protocol and service.
The route without a VPN
On a typical home network, a device sends packets to a Wi-Fi access point or router. The router forwards them to the internet service provider, which carries them toward their destination. On a mobile network, the radio and carrier infrastructure differ, but the broad relationship is similar: the access provider sits between the device and the wider internet.
The operating system uses a routing table to decide where packets go. A default route normally points ordinary internet traffic toward the local network gateway. Domain names are resolved through DNS, and the resulting destination IP address is used to route the connection.
HTTPS protects the content exchanged with most modern websites. An observer on the local network or at the ISP should not be able to read a properly secured HTTPS page simply by inspecting packets. The observer can still learn useful network metadata, including the IP addresses contacted, connection timing, duration and approximate volume. DNS queries may expose requested domain names when the resolver traffic itself is not encrypted.
The ISP carries traffic toward each destination. HTTPS can protect application content while routing metadata remains visible.
What changes when a VPN connects
A VPN application creates or controls a virtual network interface. It then installs routes that send selected traffic to that interface. The tunnel protocol wraps each original IP packet inside another packet addressed to the VPN gateway.
The outer packet travels across the local network and ISP to the gateway. The gateway authenticates and decrypts the tunnel packet, recovers the original packet, and forwards it toward its actual destination. Return traffic follows the reverse process.
This creates two distinct network segments:
- Device to VPN gateway. The VPN tunnel protects the packet contents and original destination information carried inside it.
- VPN gateway to destination. The gateway forwards traffic over the internet. Application encryption such as HTTPS remains responsible for end-to-end confidentiality on this segment.
The marked first segment is the encrypted tunnel. The connection beyond the gateway still depends on protocols such as HTTPS.
The exact routes matter. A full-tunnel configuration directs the ordinary default route through the VPN. A split-tunnel configuration sends only selected addresses or applications through it. Some operating systems also maintain separate IPv4 and IPv6 routes. A VPN that handles only one protocol family can leave the other using the normal connection unless the client blocks or routes it deliberately.
What the encrypted tunnel protects
The tunnel prevents parties between the device and gateway from reading the original packets or changing them without detection, assuming the protocol and implementation are working correctly. The local network and ISP see an encrypted connection to the VPN gateway rather than separate connections to every final destination.
They can still observe the gateway IP address, when the tunnel is active, and how much data crosses it. Packet sizes and timing are also visible. Encryption protects packet contents; it does not make the existence of communication invisible.
The VPN provider operates the gateway and therefore occupies a privileged point in the route. It can observe information needed to receive and forward traffic. What the provider actually records depends on its software, infrastructure and operational policy. A VPN moves some network visibility from the access provider to the VPN provider, so trust is changed rather than eliminated.
How a VPN changes the public IP address
Without a VPN, an internet service usually sees the public IP address used by the home router, office network or mobile carrier. With a VPN, the destination normally sees the public address of the VPN gateway.
This separates the destination from the address of the local access network. It can also make the connection appear to originate from the gateway’s network or region. It does not guarantee anonymity. Many people may share a gateway address, but a website can still recognize a signed-in account, a long-lived cookie or a distinctive browser.
An IP address is one signal among many. Replacing it changes network-level visibility without deleting identity established at the application layer.
What different parties can see
The details vary by protocol and application, but the following model is a useful starting point.
| Observer | Without a VPN | With a VPN |
|---|---|---|
| Local network | Destination IPs, timing and volume; unencrypted content | VPN gateway IP, timing and tunnel volume |
| Internet provider | Destination IPs, timing and volume; exposed DNS | VPN gateway IP, timing and tunnel volume |
| VPN provider | No position in the route | Source connection, gateway session and forwarded destinations needed to operate the route |
| Destination website | Access-network public IP plus application data | VPN gateway public IP plus the same application data |
This table describes network position, not a promise about collection or retention. A provider’s privacy policy and deployed systems are required to answer what it stores.
DNS still matters
DNS translates names such as example.com into IP addresses. If DNS queries continue to use a resolver outside the tunnel, the resolver or access provider may learn the requested names even while other traffic uses the VPN. This is commonly described as a DNS leak.
A VPN client can assign a resolver reachable through the tunnel and install system DNS settings while connected. Correct behavior depends on the operating system, browser features such as encrypted DNS, multiple network interfaces and failure recovery. Testing should consider both IPv4 and IPv6, because a correct IPv4 path does not prove the IPv6 path is also protected.
DNS protection does not hide the destination from every party. The VPN gateway still needs to forward traffic to destination IP addresses, and the chosen DNS resolver processes the queries it receives.
Why HTTPS remains necessary
VPN encryption ends at the VPN gateway. HTTPS is designed to protect the connection between an application and the website or API endpoint. The two layers solve different problems and should normally be used together.
If a site uses plain HTTP, the VPN protects that traffic only until the gateway. Beyond the gateway, content may be readable or modifiable by parties on the remaining path. With HTTPS, the gateway forwards encrypted application data and cannot read the protected HTTP content merely because it carries the packets.
Certificate validation is also essential. A VPN does not repair an application that ignores certificate errors, trusts an unsafe certificate authority or sends sensitive data through an insecure protocol.
What a VPN does not hide
A VPN does not automatically hide information deliberately or indirectly supplied by applications:
- Accounts. Signing in tells the service which account is active regardless of the public IP address.
- Cookies and storage. Existing identifiers remain available to websites until they are cleared or expire.
- Browser fingerprinting. Screen dimensions, browser features, fonts, time zone and other signals can contribute to recognition.
- Device and application telemetry. Applications may transmit identifiers, crash reports or analytics through the tunnel.
- Payment and subscription records. Commercial relationships exist outside packet routing.
- Malware or compromised devices. A tunnel cannot make an unsafe endpoint trustworthy.
- Information published by the user. Messages, uploads and profile data remain visible to their intended services and recipients.
For the same reason, claims such as “untraceable” or “complete privacy” do not describe what a VPN can technically provide.
Common limitations and failure modes
The tunnel is only one part of a working VPN client. Routes, DNS settings, IPv6 behavior and cleanup all affect the result. A connection can fail before completion, or a device can move between Wi-Fi and cellular networks while the tunnel is active. Good clients make those states explicit and restore previous network settings when setup fails.
Performance is constrained by more than cryptography. Distance to the gateway, congestion, packet loss, path maximum transmission unit, device CPU capacity and the quality of both networks can affect throughput and latency. A benchmark is useful only when its environment, versions, method and limitations are recorded.
Blocking behavior also matters. Some clients intentionally prevent traffic from leaving outside the tunnel during reconnection. Others allow the normal route to resume. Neither behavior should be assumed without inspecting the product settings and testing the actual platform.
WireGuard as a VPN protocol
WireGuard is one protocol that can carry the encrypted tunnel. It identifies peers with public keys and uses configured allowed IP ranges both to select routes and constrain which addresses belong to a peer. The protocol is intentionally compact, but a complete VPN product still needs device enrollment, key storage, endpoint discovery, DNS handling, route changes, updates and recovery logic.
WireGuard does not define a commercial VPN service or its privacy policy. It defines a secure tunnel between configured peers. The surrounding system determines who provisions those peers, how gateways are operated and what happens when the network changes.
A practical way to evaluate a VPN
Start with observable behavior rather than broad promises:
- Confirm which IPv4 and IPv6 routes change when the connection starts.
- Check which DNS resolver is used while connected.
- Verify the public IP address seen by destinations.
- Test what happens during Wi-Fi changes, sleep and failed connections.
- Read the provider’s operational and privacy documentation.
- Treat claims about speed, locations or retention as unproven unless they are supported by current evidence.
A VPN is useful because it creates a controlled route and protects the path to a gateway. Its value becomes clearer, and its limits easier to respect, when those mechanics stay visible.