VPNs fall into two groups. By topology: remote access, where a user device connects to a network, and site to site, where two networks connect. By technology: IPsec, TLS-based, WireGuard, and provider-run MPLS services. The right type depends on who connects, what they need to reach and who manages the link.
By topology: who is connecting?
Remote access. A laptop or phone connects to a gateway and gets access to internal resources. This is the model people usually mean when they say VPN.
Site to site. Two gateways connect networks, such as a branch office and a data center, or a data center and a cloud network. Users do not run VPN software. The gateways carry traffic between subnets all the time.
Provider-run. A carrier delivers a private network service to your sites. RFC 4026 sets out the terminology for provider-provisioned VPNs, and RFC 4364 defines BGP/MPLS layer 3 VPNs.
By technology: how is it built?
| Type | Layer | Typical use | Notes |
|---|---|---|---|
| IPsec | Network | Site to site, remote access | Framework of open standards, usually set up with IKE. See NIST SP 800-77 Rev. 1 and RFC 4301. |
| TLS-based | Transport and above | Remote access, sometimes per application | Runs over TLS, often reachable through web ports and firewalls. |
| WireGuard | Network | Remote access, site to site | Small codebase, fixed modern cryptography, simple configuration. |
| Provider MPLS L3VPN | Provider network | Carrier-managed wide area networks | Separation by routing, not by encryption. |
The WireGuard project describes its design as a simple, fast tunnel with a deliberately small set of cryptographic choices, which limits misconfiguration.
A constructed example
A company has a head office, six branch offices and 80 remote staff. The branches use site to site IPsec tunnels to the head office, because the gateways stay up and need no user action. Staff use a remote access client that signs in with MFA and reaches only the systems each role needs. The head office also uses a provider circuit to one data center for latency-sensitive traffic. Three types, each for one job.
What are the common mistakes?
Treating a VPN as a trust boundary is the largest one. Once connected, a device often sees the whole network. NIST SP 800-207 argues that location on the network should not grant trust, so pair any VPN with per-resource authorization and device checks.
The others are weak authentication, long-lived pre-shared keys that nobody rotates, unpatched gateways exposed to the internet, and lack of logging.
How do you choose?
For fixed networks that should always be linked, use site to site. For individual users, use remote access, and consider whether per-application access would give less exposure than a full network tunnel. For latency or contract needs, add a provider service. Use standard, maintained protocols, and check that your gateway vendor patches quickly.
What about performance?
Performance depends on the path and the cryptography more than the label. Protocols that run in the kernel and use hardware acceleration tend to carry more traffic per gateway. TLS-based VPNs over TCP can suffer when packet loss is high. Measure throughput and latency with your own traffic, from a real remote location, before standardizing on one type.
How to check or apply this
- List what connects: users, sites, cloud networks, partners.
- Pick topology first, then protocol. Match the protocol to the devices and the support you have.
- Require MFA and device checks on remote access.
- Replace shared keys with certificates or per-peer keys, and set a rotation schedule.
- Limit each tunnel to the subnets it needs.
- Patch gateways promptly and restrict their management interfaces.
- Log connections and review unusual sign-ins or new peers.
Quick check
Is a VPN the same as encryption?
A VPN encrypts traffic between its endpoints, in most designs. Some provider VPNs separate traffic without encrypting it. Check which you have.
Which VPN type is the most secure?
No type is secure on its own. Security depends on authentication, key handling, patching and what the tunnel is allowed to reach.
Sources
- NIST SP 800-77 Rev. 1, Guide to IPsec VPNs
- RFC 4301, Security Architecture for the Internet Protocol
- RFC 4026, Provider Provisioned VPN Terminology
- RFC 4364, BGP/MPLS IP Virtual Private Networks
- WireGuard
- NIST SP 800-207, Zero Trust Architecture
Last reviewed: 18 October 2026.
