Remote access vs site-to-site — the two shapes of VPN traffic

Every VPN deployment fits one of two shapes: remote access (many individual clients connecting to a corporate network) or site-to-site (two or more networks connected as if they were one). The shapes look superficially similar — both encrypt traffic, both authenticate peers, both install routes — but the operational consequences diverge sharply. The addressing scheme that works for site-to-site breaks at scale for remote access. The authentication model that works for remote access is overkill for a two-peer site-to-site link. The capacity planning is different. The failure modes are different.

This lesson covers the architectural difference, the design implications for each pattern, and the operational patterns that fit each.

The two shapes

Site-to-site connects two networks. The corporate headquarters and a branch office. Two data centres. A primary site and a cloud VPC. The tunnels are persistent (always up, or up during business hours), the peers are infrastructure (firewalls, routers), and the traffic is network-to-network — every host on each side can reach every host on the other side, subject to firewall rules.

Remote access connects individual clients to a network. Road warriors, work-from-home staff, contractors, technicians in the field. The tunnels are on-demand (the client connects when it needs to), the peers are endpoints (laptops, phones, occasionally servers), and the traffic is host-to-network — the client reaches the corporate network from wherever it happens to be.

Site-to-site design

A typical site-to-site deployment has:

• Two to ten sites, each with its own firewall and its own inside subnet.
• Persistent tunnels, up 24/7 or on a business-hours schedule.
• Per-site authentication — a certificate per firewall, or a unique PSK per pair (rotated periodically).
• Per-peer AllowedIPs (WireGuard) or per-tunnel Phase 2 selectors (IPsec) specifying the local and remote subnets.
• Hub-and-spoke or full-mesh topology:
  • Hub-and-spoke: every branch connects to headquarters; branches do not connect directly to each other. Headquarters routes inter-branch traffic through its firewall. Simpler to configure; headquarters is the bottleneck.
  • Full-mesh: every site connects to every other site directly. More resilient; more tunnels to manage (n*(n-1)/2 for n sites).

For small deployments (2-3 sites), full-mesh is straightforward. For medium deployments (5-10 sites), hub-and-spoke is more practical. For large deployments (10+ sites), dynamic routing (BGP over IPsec, or routing daemons over WireGuard) replaces the static mesh.

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

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

Remote access design

A typical remote-access deployment has:

• Many clients, from a handful to thousands.
• On-demand tunnels — clients connect when they need to, disconnect when they are done.
• Per-user authentication — every user has their own credential (certificate, PSK + MFA, RADIUS/LDAP).
• Per-user AllowedIPs (WireGuard) — each user gets one tunnel address (e.g. 10.99.0.5/32) and routes only that address through the tunnel.
• Dynamic addressing — the firewall assigns tunnel addresses from a pool. WireGuard typically uses static configuration per peer (each peer has a fixed tunnel IP); IPsec with IKEv2 can use configuration payloads to assign addresses from a pool.
• Split-tunnel or full-tunnel routing, pushed to the client.

The addressing scheme for remote access is the most common production mistake. The operator allocates a /24 subnet for the VPN, sets AllowedIPs to that subnet for every user, and finds that 200 users with overlapping /32 AllowedIPs do not all reach the corporate network. The fix: each peer gets its own /32 (a single host address), and the routes are added per-peer.

Capacity and the limits of each shape

Site-to-site capacity is bounded by the number of sites and the bandwidth of the inter-site links. A 100 Mbit/s link between headquarters and a branch carries at most 100 Mbit/s of site-to-site traffic. The encryption adds CPU cost — modern AES-NI handles WireGuard or IPsec AES-GCM at line rate on most CPUs, but a small firewall CPU can become the bottleneck.

Remote access capacity is bounded by concurrent users and per-user bandwidth. A 1 Gbit/s WAN can serve 200 users at 5 Mbit/s each, or 20 users at 50 Mbit/s each. The encryption cost is per-flow, not per-user, so a high number of low-bandwidth users (the typical remote-access pattern) is easier on the CPU than a small number of high-bandwidth users.

The discipline: plan for the worst case. A site-to-site link that carries 80% of available bandwidth at peak is too small. A remote-access deployment where 80% of users are connected at peak is at capacity.

When each pattern fits

Site-to-site is the right answer when:

• Two networks need to behave as one (a branch and headquarters; two data centres; on-prem and cloud).
• The connection is infrastructure-to-infrastructure.
• The traffic is bidirectional and persistent.
• The number of peers is bounded (a handful of sites).

Remote access is the right answer when:

• Users need to reach the corporate network from arbitrary locations.
• The connections are user-initiated and on-demand.
• The number of peers grows over time (more users, more devices).
• Per-user authorisation matters (different users have different access).

A deployment often has both: site-to-site tunnels for inter-office connectivity, plus remote access for travelling staff and work-from-home. The two patterns coexist on the same firewall with separate configuration (different interfaces, different address pools, different rules) but the same underlying encryption and authentication mechanisms.

Summary

• Site-to-site connects networks; remote access connects individual users. The shapes look similar but the operational consequences diverge.
• Site-to-site uses persistent tunnels, per-site authentication, subnet-sized AllowedIPs, and hub-and-spoke or full-mesh topology.
• Remote access uses on-demand tunnels, per-user authentication, host-sized AllowedIPs, and split-tunnel or full-tunnel routing.
• The addressing scheme is the most common production mistake — overlapping AllowedIPs break routing; every remote-access peer needs a unique /32.
• Capacity differs: site-to-site is bounded by inter-site bandwidth; remote access is bounded by concurrent users and per-user bandwidth.