VPN design decisions — picking protocol, topology, addressing and authentication

A VPN deployment that works on day one can fall apart by year three — more sites, more users, more protocols, more rules. The cause is rarely the protocol itself; it is the design decisions that were not made deliberately at the start. A pre-shared key that cannot be rotated without breaking every site. An addressing scheme that overlaps when the second cloud VPC is added. A topology that becomes a hub bottleneck at ten sites. A topology that becomes a configuration nightmare at thirty.

This lesson covers the structured design framework: protocol, topology, addressing, authentication, routing policy. Each decision is examined for the operational consequences that surface at scale.

The decision framework

Five decisions shape every VPN deployment. Each one constrains the others:

1. Protocol. IPsec, WireGuard, or OpenVPN. Driven by peer interoperability, throughput, firewall traversal, and operator preference.
2. Topology. Hub-and-spoke, full-mesh, point-to-point. Driven by the number of sites and the traffic patterns between them.
3. Addressing. Which subnets carry VPN traffic, which are remote-access pools, which are reserved for growth. Driven by existing network architecture and growth plans.
4. Authentication. PSK, certificates, or per-peer public keys. Driven by the number of peers and the operational need for per-peer identity.
5. Routing policy. Split-tunnel vs full-tunnel for remote access; static routes vs dynamic routing for site-to-site. Driven by the threat model and the operational complexity the team can sustain.

The discipline is to make each decision deliberately, document the rationale, and revisit only when the constraints change.

Protocol: the peer interoperability constraint

The protocol choice is usually driven by the peers. A site-to-site to a Cisco ASA is an IPsec deployment; a site-to-site to another OPNsense firewall is a WireGuard deployment; a remote-access deployment for staff on customer networks is an OpenVPN-over-TCP-443 deployment. The protocol follows the constraint.

When the peers are flexible — both endpoints run OPNsense, or both run Linux with strongSwan — the choice is operational. WireGuard is the simplest configuration. IPsec with IKEv2 is the most interoperable with third parties. OpenVPN is the most flexible.

The trap: an operator picks a protocol because the GUI shows it first, and the deployment grows around that choice. Six months later, the operator wants to add a peer that only supports IPsec, and the migration is painful. The discipline: name the protocol choice and the reason, and check the reason before adding a new peer.

Topology: hub-and-spoke vs full-mesh vs dynamic

Three topology choices dominate:

Point-to-point. Two sites, one tunnel. The simplest case. Easy to operate. The right answer for the smallest deployments.

Hub-and-spoke. Every site connects to a central hub; branches do not connect directly. Simpler configuration (n-1 tunnels for n sites), centralised policy enforcement, the hub is the bottleneck and the single point of failure. The right answer for 3-15 sites with predictable traffic patterns.

Full-mesh. Every site connects to every other site directly. Maximum resilience (n*(n-1)/2 tunnels), no single point of failure, harder to configure and operate at scale. The right answer for small numbers of sites with high inter-site traffic (5-10 sites) or for compliance regimes that forbid centralised choke points.

Dynamic routing over the tunnels. Sites connect to a hub (or to each other) but use a dynamic routing protocol (BGP, OSPF) over the tunnels to advertise subnets. Adding a new site is a configuration change at the hub and the new site only; the routing protocol propagates the change. The right answer for 10+ sites, for cloud hybrid deployments, and for any deployment where sites come and go.

$ netstat -rn | grep -E 'wg0|wg1|wg2|wg3|wg4'

Destination        Gateway            Flags     Netif
10.1.0.0/24        10.99.0.2          UGS       wg0
10.2.0.0/24        10.99.1.2          UGS       wg1
10.3.0.0/24        10.99.2.2          UGS       wg2
10.4.0.0/24        10.99.3.2          UGS       wg3
10.4.0.0/24        10.99.4.2          UGS       wg4

Addressing: the constraint that never goes away

Addressing is the decision the operator makes once and lives with forever. The wrong choice is expensive to fix: every firewall rule, every route, every DNS entry references the addressing.

Three rules govern VPN addressing:

1. Use RFC 1918 space that does not overlap with any site. A site with 10.0.0.0/16 cannot connect to a site that also uses 10.0.0.0/16 — the routes are ambiguous. A site with 10.5.0.0/16 can connect to any site that does not also use 10.5.0.0/16. The addressing audit is the first step of any VPN integration.
2. Allocate VPN addressing from a dedicated range. Site-to-site tunnel subnets (10.99.0.0/24, 10.99.1.0/24, …) and remote-access pools (10.98.0.0/16) live outside the site subnets. The tunnel subnets are point-to-point (/30 or /31) for site-to-site, larger pools (/24 or /16) for remote access.
3. Plan for growth. The VPN addressing plan should accommodate 5-10x growth before requiring re-numbering. A /24 remote-access pool is 254 addresses — enough for a small deployment but not for a 1,000-user organisation. A /20 is 4,094 addresses — enough for most production deployments.

The trap: the operator allocates VPN addressing ad-hoc, site by site, and finds at site seven that two sites have overlapping tunnel subnets. The fix is the renumbering project no operator wants.

Authentication: per-peer identity at scale

The authentication decision follows the number of peers and the operational requirement for per-peer visibility:

For remote access at scale, the authentication system should integrate with the corporate identity provider (RADIUS, LDAP, Active Directory). A remote-access VPN that does not integrate with central identity is an operational liability — user offboarding does not propagate to the VPN, and former employees retain access.

Routing policy: the threat model constraint

The routing policy decision follows the threat model. The choice is between:

• Split-tunnel: the VPN carries only corporate traffic. The client uses its own Internet connection for non-corporate traffic. The right answer when the client endpoint is trusted (managed laptop, corporate phone) and the bandwidth savings are significant.
• Full-tunnel: the VPN carries all the client’s traffic. The firewall sees every byte the client sends. The right answer when the client endpoint is untrusted (BYOD, contractor laptop) or when compliance requires all traffic to be inspected.

For site-to-site, the routing policy is usually simple — every site has a route to every other site through the topology. The complexity arises when policy routing on the firewall (multi-WAN) interacts with VPN traffic: the LAN-to-any rule with a gateway group will steal VPN traffic unless a before-rule is added for the VPN subnet.

The design antipatterns

Six design antipatterns surface repeatedly in production:

1. PSK for site-to-site with more than two peers. The PSK is shared; per-peer rules are impossible; revocation requires rotating every site.
2. Overlapping tunnel subnets. Two sites using 10.99.0.0/24 for their tunnel endpoints produce ambiguous routing.
3. Hub-and-spoke without hub HA. The hub is a SPOF for inter-site traffic.
4. Default AllowedIPs of 0.0.0.0/0 for site-to-site peers. A site-to-site peer should be authorised for its site subnet, not for all traffic.
5. No certificate expiry monitoring. A certificate expires; the tunnel stops working; users notice before the operator does.
6. VPN addressing in the same range as site addressing. A VPN pool of 10.0.0.0/24 collides with a site of 10.0.0.0/24; routing is ambiguous; the deployment is broken.

Summary

• Five decisions shape every VPN deployment: protocol, topology, addressing, authentication, routing policy.
• The protocol follows peer interoperability constraints; the topology follows the number of sites and traffic patterns; the addressing follows the existing network and growth plans.
• Per-peer identity at scale requires certificates or per-peer keys; PSK does not scale beyond one or two peers.
• Routing policy (split-tunnel vs full-tunnel) is a threat-model decision, not a technical one.
• The six design antipatterns — shared PSK, overlapping subnets, hub SPOF, default AllowedIPs, no expiry monitoring, addressing collisions — surface as chronic incidents at scale.