Production engineering guide for vpn architecture patterns covering patterns, implementation strategies, and operational best practices.
VPNs are not just a network layer; they are architectural choices that shape how systems, users, and services interact across boundaries. This reference page details the most effective and widely applicable patterns for designing and deploying virtual private networks, from single-site setups to globally distributed, multi-tenant architectures. These patterns are grounded in real-world engineering decisions, not theoretical abstractions. They apply when you need secure, reliable, and scalable connectivity between endpoints that span data centers, cloud regions, remote offices, and mobile users—whether for access to internal services, cross-environment orchestration, or hybrid cloud integration.
When multiple physical or virtual locations must share a private network across the public internet, site-to-site VPNs become the foundation. The core pattern involves two or more network gateways (often routers or firewalls) that establish encrypted tunnels between their subnets.
Each site advertises its local network ranges via the tunnel, enabling automatic routing. The key configuration is on the gateway device: a pair of IP addresses (one for each end of the tunnel), pre-shared keys or certificates for authentication, and a list of remote subnets to include in the routing table.
For a site using OpenVPN, the configuration for a site-to-site setup includes:
server 10.10.0.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
push "route 10.20.0.0 255.255.255.0"
remote 203.0.113.10 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
auth SHA256
tls-server
cipher AES-256-CBC
comp-lzo
keepalive 10 60On the peer site, the client configuration mirrors this:
# /etc/openvpn/client.conf
client
remote 203.0.113.10 1194
proto udp
dev tun
ca ca.crt
cert client.crt
key client.key
auth SHA256
tls-client
cipher AES-256-CBC
comp-lzo
route 10.10.0.0 255.255.255.0
route 192.168.1.0 255.255.255.0The tunnel comes up automatically when either gateway starts. The primary failure mode is asymmetric routing: packets from Site A to Site B may traverse the tunnel, but return traffic may use the public internet directly, bypassing the tunnel. This is often due to mismatched push route entries or missing static routes on the gateway.
A subtle but critical point: the push route directive must include all subnets that the remote site needs to reach, not just the local one. Missing a push route for a critical service subnet causes intermittent connectivity until the routing table is manually updated.
When one central site (the hub) serves as the network core, and multiple remote sites (spokes) connect to it, the hub-and-spoke pattern provides centralized control over routing, policy, and security. The hub maintains a routing table for all spoke subnets and advertises them to the entire network.
In this pattern, the hub runs a routing daemon—such as FRRouting (FRR) or Quagga—that dynamically advertises routes via BGP. Each spoke establishes a tunnel to the hub, and the hub announces all spoke subnets to the others.
Example BGP configuration on the hub using FRR:
# /etc/frr/frr.conf
hostname hub-router
log file /var/log/frr/frr.log
router bgp 65000
bgp router-id 192.168.1.1
neighbor 10.10.0.2 remote-as 65001
neighbor 10.10.0.2 update-source tun0
neighbor 10.10.0.2 next-hop-self
address-family ipv4 unicast
network 192.168.1.0/24
network 10.10.0.0/24
network 10.20.0.0/24
exit-address-family
!Each spoke configures BGP to connect to the hub:
# /etc/frr/frr.conf (spoke)
hostname spoke-router
log file /var/log/frr/frr.log
router bgp 65001
bgp router-id 192.168.1.10
neighbor 192.168.1.1 remote-as 65000
neighbor 192.168.1.1 update-source tun0
neighbor 192.168.1.1 next-hop-self
address-family ipv4 unicast
network 10.20.0.0/24
exit-address-family
!The key benefit is automatic route propagation: when a new spoke joins, it announces its subnet, and all other spokes immediately learn how to reach it. The failure mode is route flapping: if a spoke’s tunnel fails and recovers, the BGP session may drop, causing temporary loss of reachability.
A common mistake is not setting next-hop-self on both hub and spokes. Without this, packets from the hub to a spoke may have a next-hop IP that is unreachable from the spoke’s perspective, causing suboptimal routing and packet loss.
When individual users or mobile devices need secure access to the private network, IPsec-based remote access VPNs are the standard. This pattern establishes a point-to-site tunnel between each client and the central gateway.
The client connects using IKEv2 (Internet Key Exchange version 2), which negotiates security associations (SAs) and establishes an encrypted tunnel. The client receives an IP address from the gateway’s pool and can reach all internal subnets.
On Linux, the strongswan daemon manages the IPsec tunnel. Configuration for the gateway (/etc/ipsec.conf) includes:
conn ikev2
keyexchange=ikev2
ike=aes256-sha256-modp2048!
esp=aes256-sha256!
auto=route
left=203.0.113.10
leftsubnet=192.168.1.0/24
leftauth=psk
[email protected]
right=%any
rightauth=psk
rightsourceip=10.10.0.100-200
rightdns=192.168.1.10
rightsendcert=neverThe rightsourceip directive assigns dynamic IP addresses from a pool to connecting clients. The rightdns entry pushes DNS settings, so users can resolve internal services without additional configuration.
Clients use standard tools to connect. On macOS, networksetup -setvpnstate "VPN" on triggers a connection, and the system automatically negotiates the IPsec tunnel. On Windows, rasdial can be used:
rasdial "Corporate VPN" [email protected] passwordA silent failure occurs when the client’s network interface is not properly configured to handle the tunnel. The default route is not updated, so external traffic (e.g., web browsing) does not traverse the tunnel. The fix is to ensure the gateway pushes route and default-route in the IPsec proposal.
Another common issue: the leftauth and rightauth values must match exactly. If the gateway uses psk but the client sends eap, the tunnel fails silently. The error is visible in ipsec status output:
# ipsec status
Security Associations (1):
ikev2[1]: ESTABLISHED 5 minutes ago, 203.0.113.10[vpn.example.com]...192.168.1.10[10.10.0.1]
ikev2{1}: INSTALLED, TUNNEL, ESP in UDP SPIs: c2938b4a_i 5b1c3a8f_o, conn 1
ikev2{1}: last packet received 12 seconds ago
ikev2{1}: IKEv2 SA not established: AUTHENTICATION_FAILEDThe AUTHENTICATION_FAILED message indicates a mismatch in authentication methods or keys.
When multiple tenants (e.g., departments, customers, or projects) share a single physical or virtual network, the challenge is isolation: ensuring that each tenant’s traffic remains private and does not interfere with others.
This pattern uses Virtual Routing and Forwarding (VRF) to create isolated routing domains. Each tenant has its own VRF, with its own IP subnets, routing tables, and default gateways.
On a router running FRR, this is configured with:
vrf tenant-a
table 100
ip route 10.10.1.0/24 192.168.1.1
ip route 0.0.0.0/0 192.168.1.1
!
vrf tenant-b
table 200
ip route 10.20.1.0/24 192.168.1.10
ip route 0.0.0.0/0 192.168.1.10
!Tunnels are established between gateways using VXLAN (Virtual Extensible LAN) to create an overlay network. Each tenant’s traffic is encapsulated in a VXLAN header, with the VNI (VXLAN Network Identifier) identifying the tenant.
The control plane for VXLAN is often based on BGP EVPN (Ethernet VPN). The gateway advertises MAC addresses and IP prefixes using BGP, allowing multi-tenancy across multiple physical sites.
Example BGP EVPN configuration:
router bgp 65000
neighbor 203.0.113.11 remote-as 65001
neighbor 203.0.113.11 update-source eth0
address-family l2vpn evpn
neighbor 203.0.113.11 activate
neighbor 203.0.113.11 advertise-all-vni
advertise-all-vni
exit-address-family
!Each tenant’s VNI is assigned a unique value. Traffic from tenant A (VNI 1000) is encapsulated in VXLAN with VNI 1000, and the outer IP header uses the gateway’s IP.
The sharp edge here is the mapping between VRF and VNI. If a tenant’s VRF is not correctly bound to its VNI, packets may arrive but be delivered to the wrong tenant. The failure mode is “silent misrouting”: services respond, but data is from the wrong tenant.
A subtle failure is when BGP EVPN is not configured to advertise both MAC and IP routes. Without advertise-all-vni, only MAC addresses are shared, but IP reachability is missing. This causes ARP storms and slow convergence.
In modern architectures, the network is no longer trusted. The zero trust pattern assumes that every connection—whether from a user, device, or service—must be authenticated and encrypted from end to end.
This pattern layers multiple technologies: a primary IPsec or WireGuard tunnel for core connectivity, combined with certificate-based authentication, mutual TLS (mTLS), and policy enforcement.
Clients authenticate using X.509 certificates issued by a trusted CA. The server validates the client certificate and then establishes a session using mTLS over the tunnel.
On a WireGuard client, the configuration includes:
[Interface]
PrivateKey = 123456789abcdef123456789abcdef123456789abcdef123456789
Address = 10.10.0.10/24
DNS = 192.168.1.10
[Peer]
PublicKey = abcdef123456789abcdef123456789abcdef123456789abcdef123456789
PresharedKey = 987654321abcdef987654321abcdef987654321abcdef987654321
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.10.0.0/24, 192.168.1.0/24
PersistentKeepalive = 25The server runs wg and manages peers via wg set, wg show, and wg add peer.
A key failure mode is certificate expiration. If the client certificate expires and is not renewed, the connection fails with a TLS alert:
TLS alert: fatal: certificate expiredThe server logs show that the client presented a certificate valid until 2023-10-15, but the current date is 2023-10-20.
Another critical element is the use of AllowedIPs. Without proper AllowedIPs, the client can reach the internal network, but services outside the tunnel are inaccessible. A common mistake is using 10.0.0.0/8 instead of 10.0.0.0/16, causing suboptimal routing and increased latency.
The pattern also includes identity-based access control. The gateway uses the client’s certificate to query an identity provider (IdP) via OAuth or SAML. The IdP returns claims (e.g., department=engineering, role=developer), which are used to apply dynamic firewall rules, VLAN assignments, and service access policies.
This results in a seamless, secure, and policy-driven network where every connection is verified and every packet is protected.
This page was rewritten on 18 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.
We use cookies for analytics (Google Analytics) and advertising (Google AdSense) to improve your experience and support free content. Privacy Policy