Choosing between a client VPN and a site-to-site VPN is a network design decision, not simply a choice between two products. This guide explains how each model works, where it fits, what to monitor, and when to use both. It also provides a planning worksheet and review routine for businesses adding users, offices, cloud networks, contractors, or new applications.
Overview
A client VPN creates a user-based connection between an individual device and a private network. A VPN application on a laptop, phone, or managed workstation authenticates the user and usually the device, then provides access to approved internal systems. This is the familiar remote access VPN design for employees working from home, travelling, or connecting from an untrusted network.
A site-to-site VPN connects two networks rather than one user device to a network. VPN gateways, firewalls, or cloud network appliances establish an encrypted tunnel between locations, such as a head office and a branch office, a data centre and a cloud virtual network, or two business environments. Devices on each side can communicate according to the routes and firewall policies configured by the network team.
In simple terms, use a client VPN when the identity of the individual and device is central to the access decision. Use a site-to-site VPN when trusted network-to-network connectivity is required. Many businesses use a combination: site-to-site tunnels for offices and cloud infrastructure, plus client VPN or a zero-trust access model for employees and contractors.
Neither design automatically makes every connected resource safe. Both require careful authentication, routing, segmentation, logging, patching, and access review. A tunnel encrypts traffic in transit between its endpoints, but it does not replace application security, endpoint protection, least-privilege permissions, or monitoring.
Quick decision matrix
| Requirement | Usually the better starting point | Why |
|---|---|---|
| Employees need access from home or while travelling | Client VPN | Access can be linked to a person, device posture, and session policy. |
| Two permanent offices need shared internal services | Site-to-site VPN | It connects networks without requiring every user to start a separate tunnel. |
| A cloud network must connect to an office | Site-to-site VPN | It provides private routing between selected network ranges. |
| Short-term contractors need limited access | Client VPN or ZTNA | Individual identities and narrow application scope are easier to control than broad network access. |
| Many remote users access different applications | Client VPN, ZTNA, or a combination | The best option depends on application compatibility, device management, and required network reach. |
| Two locations have overlapping IP ranges | Neither without redesign | Address conflicts can make routing unreliable and may require renumbering or translation. |
For a broader comparison of application-level access and traditional network access, see our guide to ZTNA versus VPN for secure remote access.
What to track
1. Users, devices, and identity controls
For a client VPN, record who can connect, which devices are allowed, how multifactor authentication is enforced, and what happens when an account or device is disabled. Track inactive accounts, unmanaged devices, repeated authentication failures, and users whose access no longer matches their role.
Document whether the VPN authenticates against a central identity provider, directory service, certificates, or a combination. A password-only design deserves particular scrutiny. Also record session duration, idle timeout, reauthentication requirements, and the process for revoking a lost device. The VPN account security checklist can support this review.
2. Routes and access scope
List every local and remote network range advertised through each site-to-site tunnel. For client VPN users, record whether they receive full internal routing or only selected subnets. Avoid treating a successful tunnel as proof that access is appropriately limited.
For each route, identify the systems it exposes, its business owner, and the firewall rules that govern traffic. Pay attention to administrative interfaces, backup systems, databases, and management networks. If split tunnelling is enabled, document which traffic uses the VPN and which traffic goes directly to the internet. Our split tunnelling guide explains the practical trade-offs.
3. Tunnel health and performance
Monitor tunnel availability, negotiation failures, unexpected disconnects, latency, packet loss, and throughput during normal and peak periods. A tunnel can appear established while an important route, firewall rule, or dependent service is unavailable, so test representative applications rather than only checking gateway status.
For client VPNs, compare connection failures by operating system, client version, network type, and location. For site-to-site VPNs, track both ends of the tunnel and any dependencies such as public IP addresses, certificates, DNS, cloud routes, and firewall policies.
4. Resilience and dependency risk
Document whether each connection has a second internet link, redundant gateway, alternate tunnel, or tested failover path. Record the failure mode: does traffic stop safely, fail over automatically, or continue through an unexpected route?
Include renewal dates for certificates, credentials, and licences where relevant, but do not rely on calendar reminders alone. A failover design that has never been tested may not work when needed. Record the last test, result, observed disruption, and corrective action.
5. Logging and operational ownership
Identify where connection events, authentication logs, gateway alerts, and firewall decisions are stored. Confirm that someone reviews them and knows which events require escalation. Useful signals include logins at unusual times, connections from unexpected countries or networks, repeated failures, configuration changes, and large transfers across a tunnel.
Every tunnel should have an owner, a documented purpose, an approved change record, and a removal process. Unowned connections tend to survive long after the original business requirement has changed.
Cadence and checkpoints
Before deployment or expansion
Start with an inventory rather than a product comparison. List users, offices, cloud networks, applications, address ranges, identity sources, internet links, and security boundaries. Then decide whether each requirement needs user-based access, network connectivity, or application-specific access.
Use this planning worksheet for every proposed connection:
- Purpose: What business function requires the connection?
- Endpoints: Which users, devices, offices, cloud networks, or applications are involved?
- Identity: How are users, devices, gateways, and services authenticated?
- Routes: Which exact address ranges or applications are reachable?
- Access scope: What is explicitly allowed, and what is denied?
- Dependencies: Which DNS, certificates, identity services, firewalls, providers, or links must work?
- Monitoring: Which logs, alerts, health checks, and owners are assigned?
- Resilience: What happens if the tunnel, gateway, link, or identity provider fails?
- Review date: When will the connection be checked again?
Test with ordinary user access and administrative scenarios. Confirm that an authorised user can reach the required service, an unauthorised user cannot, and a disconnected or expired credential is rejected. Test DNS resolution, routing, application behaviour, and logging.
Monthly checks
Review failed logins, inactive accounts, newly enrolled devices, unusual connection locations, tunnel interruptions, and recent configuration changes. Check that alerts reached the correct person and that critical logs are still being retained. For a small environment, a short documented review is more useful than an elaborate process nobody completes.
Quarterly checks
Reconcile the VPN configuration with the current network diagram and asset inventory. Remove unused users, routes, firewall rules, tunnels, and client profiles. Review whether contractors, leavers, and role changes were handled correctly. Examine capacity, latency, and recurring incidents to determine whether the design is still appropriate.
Run a failover exercise where the business can tolerate it. Test the loss of a primary internet connection, gateway, tunnel, certificate, or identity dependency. Record the recovery steps and update them after the exercise.
Annual or major-change review
Perform a deeper architecture review at least annually and whenever the business opens or closes an office, migrates workloads to the cloud, changes identity providers, replaces a firewall, adopts a new VPN protocol, or materially changes its application estate. Technology terminology and provider capabilities change, so confirm that current documentation matches the deployed design.
How to interpret changes
A rise in client VPN failures does not always mean the VPN gateway is overloaded. It may indicate an expired certificate, a client update, an identity-provider issue, a change in home networks, or a device compliance problem. Group events by time, user population, device type, and dependency before changing the architecture.
Repeated site-to-site tunnel renegotiations may point to unstable links, mismatched settings, clock problems, certificate issues, or an appliance resource limit. If the tunnel remains up but applications slow down, investigate routes, MTU, packet loss, DNS, and firewall inspection rather than assuming encryption is the cause.
Increasing access requests can be a sign that the original network scope is too broad or that applications need a more targeted access model. If users only need a small number of services, consider whether application-aware access or ZTNA would reduce exposure compared with placing them on a large internal network. Conversely, offices that need dependable access to many shared services may still be better served by a carefully segmented site-to-site design.
Do not interpret fewer alerts as proof of better security. Logging gaps, disabled monitoring, or an expired integration can make an environment appear quieter. Compare operational data with configuration changes and verify that expected test events are visible.
When to revisit
Use a monthly review for operational health, a quarterly review for access and configuration hygiene, and an annual review for architecture. Revisit sooner after a security incident, major outage, office move, cloud migration, identity change, provider replacement, or significant workforce change.
At each review, ask five practical questions:
- Does every tunnel and client access policy still have a current business purpose?
- Are users, devices, routes, and applications limited to what they require?
- Can the organisation identify and revoke access quickly?
- Are monitoring, alerting, and ownership working in practice?
- Has failover been tested since the last material change?
Finish by updating the network diagram, route inventory, access matrix, and recovery notes. Link each change to an owner and a review date. If the answers show that a client VPN is granting broad network access where only a single application is needed, assess a narrower model. If separate offices are relying on individual user connections for routine shared work, assess a site-to-site design. If both patterns exist, document how they interact and keep their trust boundaries distinct.
A sound business VPN architecture is not defined by choosing one tunnel type. It is defined by clear identity, limited reachability, observable behaviour, tested resilience, and a review process that keeps the design aligned with the business.
