VPN architecture patterns and when VPN is the wrong answer

The tunnel is the easy part

I run a VPN service in production — Veilock, under Nubinity — and the operator’s view is clarifying: encryption is the solved part of VPN architecture. WireGuard, IKEv2, and modern TLS all encrypt traffic competently. Nearly every VPN failure I have seen, in my own infrastructure and in enterprises I have assessed, is architectural: the tunnel terminated in the wrong place, carried the wrong scope of traffic, or granted network reachability where the actual requirement was access to three applications.

The most dangerous tunnel is the one that works perfectly.

So the design order matters. Decide the topology and the authorization model first; pick the protocol last. This article follows that order.

Two problems that look alike: site-to-site and remote access

Site-to-site connects networks — branch to datacenter, datacenter to cloud VPC, your network to a partner’s. The peers are routers, the tunnels are long-lived, and the design questions are routing questions:

• Route-based over policy-based, always. A tunnel interface that participates in routing behaves like any other link: you can run BGP or OSPF across it, apply normal redundancy, and troubleshoot with normal tools. Policy-based crypto maps — “interesting traffic” ACLs triggering encryption — are a legacy pattern whose failure modes (mismatched ACLs, one-way SAs) waste days of engineering time. Reach for them only when a partner’s equipment forces it.
• Topology follows traffic. Hub-and-spoke suits branches that mostly talk to the datacenter; a mesh (or dynamic mesh, DMVPN/ADVPN-style) earns its complexity only when branch-to-branch traffic is real — voice between offices is the classic justifier.
• Failover is a routing problem. Tunnels over each WAN path, dynamic routing inside the tunnels, and failover becomes reconvergence you can test, not a runbook someone executes at 2 a.m. Watch the MTU: tunnel overhead plus PMTUD breakage is the most common “VPN is up but the app hangs” cause, so clamp TCP MSS on the tunnel interfaces and be done with it.

Remote access connects people, and the hard problems are identity and scope, not routing. The concentrator is an internet-facing asset that terminates authentication for your whole workforce — patch it like the crown-jewel target it has repeatedly proven to be, front it with MFA, and prefer certificate- or key-based machine identity plus user SSO over anything password-shaped. The scope question — what a connected user can reach — is the split-tunnel and ZTNA discussion below, and it is the one that determines whether your VPN is an access tool or a liability.

Protocol tradeoffs without the religion

Dimension	WireGuard	IPsec/IKEv2 (RFC 7296)	TLS-based (OpenVPN, SSL VPN)
Codebase & auditability	~thousands of lines, formally analyzed	Large, decades of accretion	Large (full TLS stack)
Crypto agility	Fixed modern suite (Noise, ChaCha20-Poly1305)	Negotiated; strong or weak as configured	Negotiated via TLS
Interop with vendors/partners	Growing, not universal	The lingua franca	Vendor-specific mostly
NAT / restrictive network traversal	UDP only; usually fine	Needs NAT-T (UDP 4500); sometimes blocked	Best — TCP 443 passes almost anywhere
Roaming (IP changes)	Seamless by design	Good with MOBIKE	Reconnect-dependent
Identity model	Static public keys	Certificates/PKI, EAP	Certificates + user auth
FIPS / compliance regimes	Not FIPS-validated	Mature validated implementations	Depends on TLS module

My operating experience: WireGuard when I control both ends — the configuration is small enough to review at a glance, performance is excellent in-kernel, and roaming just works. Its fixed cryptography is a feature, not a limitation: negotiation is where IPsec deployments historically rotted, with twenty-year-old proposals still enabled because nobody dared remove them. WireGuard’s honest gaps are key distribution (static keys mean you must build or buy rotation and revocation around it) and the lack of FIPS validation where regulation demands it.

IPsec/IKEv2 for interop and PKI scale — third parties, network vendor gear, certificate-based identity for hundreds of sites, compliance regimes. NIST SP 800-77r1 is the reference for configuring it without the legacy footguns. TLS-based when the network fights you — the ability to look like ordinary HTTPS on TCP 443 is the whole value proposition, and it is a real one for remote access from hostile hotel and guest networks.

Split versus full tunnel is a monitoring question

Split tunnel routes only corporate prefixes through the VPN; full tunnel carries everything. The table is short but the deciding question is usually skipped:

	Split tunnel	Full tunnel
Concentrator load & user latency	Low	High — all traffic hairpins
Egress control & inspection of user traffic	None for internet traffic	Complete
Blast radius of a compromised endpoint	Same either way — scope is set by authorization, not tunneling

The deciding question: does anything actually consume the visibility full tunnel buys? If your security stack genuinely inspects and acts on tunneled internet traffic, full tunnel is a defensible control. If not, you are paying concentrator capacity and user latency to backhaul streaming video, and users will experience the VPN as punishment — which is how shadow-IT workarounds get born. The COVID-era remote work surge settled this argument in most shops: organizations split-tunneled at least their collaboration suites within weeks because the capacity math left no choice.

One warning either way: split tunnel decides where packets go, not what the endpoint may reach. A split-tunnel client with reachability to every internal subnet has the same blast radius as a full-tunnel one. Scope comes from the authorization layer — per-group route pushes at minimum, real segmentation behind the concentrator in any serious design.

When VPN is the wrong answer

The remote-access VPN’s defining property — placing a device on the network — is exactly what modern access design tries to avoid. If the requirement is “these users need these applications,” network reachability is over-delivery, and NIST SP 800-207’s zero-trust model names the alternative: broker each application session individually, with identity and device posture evaluated per request. That is ZTNA, whether delivered as an identity-aware proxy for web apps or a broker-based connector mesh for the rest.

The honest decision split:

• ZTNA fits: workforce access to defined applications, contractors and third parties (the strongest case — a vendor who needs one dashboard should never receive a subnet), M&A transition access, unmanaged-device scenarios where a clientless portal beats shipping VPN profiles.
• VPN remains right: site-to-site (ZTNA does not connect networks), non-HTTP and infrastructure protocols, network and OT administration where the network layer itself is the thing being managed, and environments where a broker’s cloud dependency is unacceptable.

Two candid caveats from the operator’s side. First, ZTNA moves trust to the identity provider and the broker — it concentrates rather than eliminates critical dependencies, and an identity-first security posture is a prerequisite, not a nice-to-have. Second, a privacy-oriented consumer VPN like the one I run solves a different problem entirely — encrypting transit on untrusted networks and shifting your egress point. It is not an enterprise access control, and vendors who blur that line are selling the word “VPN,” not an architecture.

Decisions to write down

For whichever pattern you land on, record: where every tunnel terminates and who owns those devices; the authentication chain (machine identity, user identity, MFA point) for each access path; what each class of peer can reach and which control enforces it; the split/full decision and what consumes the visibility if full; MTU/MSS values on every tunnel; and the failover behavior you have actually tested, not the one the diagram implies. A VPN estate documented to that standard can be audited, migrated, or incident-responded. One that isn’t becomes the reason the network design review takes three weeks instead of three days.

Tunneling protocols churn — WireGuard was the insurgent option not long ago, and something will eventually make it look legacy. The durable part of a VPN architecture is the authorization decision: who reaches what, enforced where. Get that decision right and the protocol underneath becomes what it should have been all along — a detail you can swap.