What is a VPN?
A virtual private network (VPN) creates an authenticated, protected connection between devices or networks across another network. A VPN can connect an employee to company systems, join two sites, or route selected internet traffic through a provider gateway. The word “private” describes the controlled tunnel and access policy. It does not mean the user becomes anonymous.
A VPN can protect traffic while it travels between its tunnel endpoints and can change the public source IP address seen by destinations. Its exact effect depends on the protocol, route policy, DNS design, IPv4 and IPv6 coverage, endpoint security, and what happens after traffic leaves the VPN gateway.
How does a VPN work?
- The client authenticates the VPN peer. Depending on the design, the peers may use certificates, keys, credentials, or multiple factors to establish trust.
- They negotiate protection. The VPN protocol establishes keys, algorithms, tunnel parameters, and the traffic selectors or routes that belong in the tunnel.
- The device sends matching traffic into a virtual interface. A full tunnel usually captures most internet-bound traffic. A split tunnel sends only selected destinations through the VPN.
- The VPN encapsulates and protects the packet. An outer packet carries the protected inner traffic across the intervening network to the other tunnel endpoint.
- The remote endpoint verifies and forwards it. A gateway removes the tunnel protection and routes the original traffic toward a private network or the public internet. Replies follow the corresponding return path.
IPsec is one widely used network-layer VPN framework. IKEv2 can mutually authenticate peers and establish the Security Associations used by IPsec. Other VPN designs use different protocols and transports. “AES-256” alone does not identify a complete VPN design or prove that its authentication, key management, routing, software, and operations are secure.
What changes when you connect to a VPN?
| Property | Typical full-tunnel effect | Important limit |
|---|---|---|
| Traffic on the local or access network | Selected packets are protected between the device and VPN gateway | Traffic outside the tunnel and activity on a compromised endpoint remain exposed |
| Public source IP seen by a destination | The destination commonly sees an address used by the VPN exit | Split routes, direct connections, embedded identifiers, and application behavior can reveal other information |
| DNS requests | They may use a resolver reached through the tunnel | Resolver policy and route configuration decide this; a VPN label does not prevent DNS leaks |
| Local private IP address | The device can receive an additional tunnel address | The existing Wi-Fi or Ethernet address normally still exists on the local network |
| Protection after the VPN gateway | HTTPS or another end-to-end protocol can continue protecting application data | The VPN tunnel itself normally ends at the gateway, so application encryption is still necessary |
Common VPN types
| Type | Connects | Typical task | Key design question |
|---|---|---|---|
| Remote-access VPN | A user device to an organization gateway | Reach internal applications from another network | Which users, devices, routes, and applications are authorized? |
| Site-to-site VPN | One network gateway to another | Join offices, data centers, or partner networks | How are overlapping routes, failover, and traffic selectors handled? |
| Consumer or commercial privacy VPN | A device to a provider exit | Protect access-network traffic and change the visible exit IP | What can the provider observe, retain, and disclose? |
| Application-specific tunnel | One application or managed workload to a service | Protect only a defined workflow | What traffic remains outside the tunnel? |
These categories can overlap. A product name does not establish the route scope, security boundary, or privacy outcome. Inspect the actual configuration and test both expected and excluded traffic.
How does a VPN change your IP address?
For traffic that leaves through an internet VPN gateway, a website generally sees the gateway’s public source address instead of the client network’s public address. For example, a client behind documentation address 198.51.100.25 could send a tunneled request that reaches a site from exit address 203.0.113.40. The VPN has changed source-address visibility for that flow, not the user’s identity.
An exit can use a shared address, a dedicated address, or a routed prefix. Shared exits provide less stable attribution to one customer but can encounter noisy-neighbor reputation and rate limits. Dedicated exits make allowlisting and reverse DNS easier, but they are more consistently associated with one organization. Neither arrangement guarantees a particular geolocation, reputation score, or acceptance by a destination.
IPv4 and IPv6 need separate attention. A tunnel that carries IPv4 but leaves IPv6 on the local path can expose a different public source address. Test route tables, DNS, IPv6, browser behavior, reconnects, captive portals, and tunnel failure instead of relying on an “IP changed” indicator alone.
What a VPN does not protect
- Account identity: Signing in still tells a service which account is active.
- Cookies and device signals: Cookies, browser storage, application identifiers, and fingerprinting can link sessions across IP changes.
- The endpoint: Malware, unsafe extensions, stolen credentials, and unpatched software can expose data before encryption or after decryption.
- All traffic by default: Split tunneling, excluded applications, DNS, IPv6, or a failed tunnel may use another path.
- The provider relationship: A VPN operator can be in a position to observe connection metadata and, depending on the design, traffic leaving its gateway. A no-logs statement is a policy claim, not technical proof that no records exist.
- Authorization or legal permission: A different exit location does not grant a right to bypass service terms, access controls, censorship law, licensing restrictions, or destination policy.
- End-to-end application security: Use HTTPS, SSH, or another appropriate application protocol because the VPN protection normally stops at its peer.
A VPN can reduce exposure to an access network and create controlled network reachability. It cannot guarantee anonymity, total privacy, clean traffic, or immunity from tracking.
VPN vs proxy, private network, and HTTPS
| Control | Typical scope | What it can change | What it does not prove |
|---|---|---|---|
| VPN | Selected device or network traffic between VPN peers | Path, protected tunnel, and often the public source IP seen after an exit | Anonymity, endpoint safety, or protection beyond the gateway |
| Forward proxy | Configured application protocols or requests | Application path and source address seen by the destination | Protection for every device flow; some proxy transports are encrypted and some are not |
| Private network | A network with controlled routing and addressing | Which systems can reach one another | Encryption; a private network can exist without a VPN |
| HTTPS | Application data between a client and web origin or terminating intermediary | Confidentiality and integrity for the protected web session | Concealment of the destination IP from the network path |
See the proxy IP guide for protocol and logging differences, and the public versus private IP guide for address scope and reachability.
VPN selection and deployment checklist
- Define the task and threat model. State whether the goal is remote access, site connectivity, access-network protection, a stable egress IP, or another specific outcome.
- Confirm protocol and update support. Review maintained implementations, authentication, key management, algorithm negotiation, security advisories, and retirement of obsolete options.
- Design identity and authorization. Use appropriate user and device authentication, least-privilege routes, short-lived access where practical, and a tested revocation path.
- Document the route model. Record full or split tunnel behavior, allowed prefixes, default routes, overlapping networks, NAT, MTU, and return-path requirements.
- Test DNS and both IP versions. Verify resolver paths, IPv4 and IPv6 source addresses, reconnect behavior, kill-switch or fail-open policy, and captive-portal handling.
- Assess endpoints and gateways. Patch software, protect keys, restrict administration, monitor capacity, and test high availability. Tunnel encryption does not compensate for a compromised peer.
- Verify provider claims with dated evidence. Review the legal entity, ownership, jurisdictions, retention policy, incident history, independent assessment scope and date, and how requests for data are handled.
- Measure the real workload. Test latency, throughput, packet size, roaming, loss, failover, and application compatibility from the regions and networks that matter.
- Plan operations and exit. Assign alerting, abuse handling, log access, address changes, certificate and key rotation, provider outage, migration, and service termination.
IPv4 planning for VPN gateways
A business VPN gateway may need stable public IPv4 capacity for partner allowlists, customer access, reverse DNS, monitoring, or regional egress. Before using an address or prefix, verify the party authorized to provide it, the route origin and upstream acceptance, RPKI and IRR responsibilities, geolocation evidence, reverse DNS control, reputation observations, abuse contacts, DDoS handling, failover, renewal, and return terms.
IP reputation and geolocation are time-sensitive observations, not permanent properties. Record the provider, result, and timestamp, then retest after activation or route changes. The IP reputation guide explains the evidence limits, while IP address information covers what an address can and cannot reveal.
If you operate VPN infrastructure, review the responsibilities in the VPN and privacy network solution and managed IPv4 leasing. Availability, authority, routing, and suitability still require case-specific confirmation.
VPN FAQ
Does a VPN make you anonymous?
No. A VPN can hide the client network’s public IP from destinations for tunneled traffic, but the VPN operator, account logins, cookies, browser or device identifiers, traffic patterns, and activity outside the tunnel can still link actions to a user or organization.
Does a VPN change your IP address?
Usually for traffic routed through an internet exit. The destination commonly sees the exit’s public source IP rather than the client network’s public IP. Split-tunneled traffic, IPv6, peer-to-peer connections, or excluded applications may behave differently.
Does a VPN encrypt all internet traffic?
Not necessarily. A full-tunnel policy can protect most routed device traffic between the VPN peers. Split routes, unsupported protocols, DNS or IPv6 misconfiguration, local-network traffic, and tunnel failure can leave traffic outside. HTTPS is still needed beyond the VPN gateway.
What is the difference between a VPN and a proxy?
A VPN commonly routes selected device or network traffic through a protected tunnel. A proxy relays requests for configured applications or protocols. Either can change the source IP seen by a destination, and either may use encrypted or unencrypted transports depending on the implementation.
Is a virtual private network the same as a private network?
No. A private network is a routing and access domain. A virtual private network is a mechanism for creating protected connectivity between defined peers across another network. The phrase “private virtual network” is often an informal reversal of the standard term “virtual private network.”
Does a VPN slow down internet speed?
It can add encryption work, packet overhead, and a longer route, so latency may rise and throughput may fall. A better path or relief from network-specific traffic shaping can sometimes improve one workload, but higher speed is not guaranteed. Measure from the actual client, gateway, and destination.
Are free VPNs always unsafe?
No single price category proves safety. Free and paid services both require review. Check the operator, funding model, permissions, software updates, data handling, retention, independent assessment, incident response, and whether the service meets the defined threat model.
