VPN deployment: a practical guide

A VPN rollout is scheduled for a Saturday. The tunnels come up, authentication works, and the engineers go home. On Monday morning a third of remote staff cannot reach the file server, because their home routers use the same address range as the office network and the routing table has no way to choose. Nothing was misconfigured. The addressing was decided years earlier by whoever set up the office, and nobody checked what it would collide with.

This is the shape of most VPN deployment problems. The cryptography works, the vendor documentation is accurate, and the failures come from decisions made outside the VPN — addressing, DNS, certificate lifetimes, and the assumption that everyone's home network looks like the office.

This article covers deployment mechanics. The prior question — which topology, and whether a VPN is the right answer at all — is covered in the secure remote access article, and is worth settling before any of what follows.

Choosing a protocol

The realistic choice for a business deployment is between IPsec and WireGuard, with SSL/TLS-based options where client flexibility matters more than performance.

WireGuard describes itself as an extremely simple yet fast and modern VPN that utilises state-of-the-art cryptography, and its design has a property worth understanding before deployment. Cryptokey routing associates each peer's public key with a set of allowed IP addresses, which means the routing table and the access control list are the same object. There is no separate step where you decide what a peer may reach — configuring the tunnel is that decision.

IPsec has an equivalent concept that businesses routinely ignore. RFC 4301 defines a Security Policy Database that classifies traffic crossing the boundary as PROTECT, BYPASS or DISCARD, using selectors on addresses, protocols and ports. The standard assumes you will decide what may cross; most deployments configure a tunnel that carries everything and never revisit it.

Addressing: the decision that causes Monday morning

This is the single most common deployment failure and it is entirely avoidable at the planning stage.

Home routers overwhelmingly default to 192.168.0.0/24 or 192.168.1.0/24. If the office network uses either, every remote user whose home network matches has an unresolvable conflict: their machine has two plausible routes to the same address range, and the local one usually wins. The user can connect to the VPN and reach nothing.

• Choose an internal range that home equipment will not use. Somewhere in 10.0.0.0/8 or the less common parts of 172.16.0.0/12 is far safer than 192.168.0.x.
• Allocate a separate range for VPN clients, distinct from any office LAN. This makes remote users identifiable in firewall rules and logs, which is what allows policy to differ for them.
• Plan the site-to-site ranges so no two sites overlap. Two branches both using 192.168.1.0/24 cannot be joined without translation, and translation is a permanent complication.
• Leave room. An address plan that exactly fits today's device count will be renumbered within three years, and renumbering is more disruptive than the original deployment.
• Write it down. An addressing plan that exists only in the running configuration will be contradicted by the next person who needs a subnet in a hurry.

Certificates and the renewal nobody scheduled

Certificate-based authentication is the right default for remote access, because it proves something about the device rather than only about the person. It also introduces a lifecycle that must be managed, and the failure mode is unusual: everything works perfectly until a date, and then nothing does.

1. 1

   Decide the certificate authority before issuing anything

   An internal CA is normal for VPN client certificates and its own root has a lifetime. Businesses that issue client certificates from an ad hoc CA created during the rollout inherit a root expiry nobody recorded.

2. 2

   Choose lifetimes deliberately

   Short client-certificate lifetimes limit the value of a stolen device and increase renewal load. One year is a common balance. What matters more is that the figure was chosen rather than inherited from a default.

3. 3

   Build revocation in from the start

   A certificate revocation list or OCSP responder that the gateway actually checks. Revocation configured but unchecked is the state most deployments are in, and it means a revoked certificate still authenticates.

4. 4

   Monitor expiry, for clients and for the CA

   With weeks of warning rather than days. Certificate expiry is a total outage with a known date, which makes it the most avoidable incident there is.

5. 5

   Document issuance and revocation

   Who can issue a certificate, on what basis, and what triggers revocation. Offboarding depends on this being written down.

The third step is the one that connects to offboarding. Disabling a user's account does not invalidate a certificate already installed on their device unless that certificate is revoked and the gateway checks revocation. A deployment without working revocation has an offboarding gap built into it from day one.

DNS, and why internal names stop resolving

After addressing, DNS is the second most common source of post-deployment support tickets. A user connects successfully, can reach internal systems by address, and cannot reach them by name.

The cause is that the VPN client did not take over DNS resolution, so queries for internal names went to the user's home router, which has no idea what they are. The fix is to push internal DNS servers to the client as part of the tunnel configuration, and to decide explicitly whether all queries or only internal-domain queries are sent there.

That second decision has a privacy dimension worth being deliberate about. Sending all DNS queries through the corporate resolver means the business sees every name a user's machine looks up, including on a personal device. Split DNS — internal domains to the internal resolver, everything else to the user's own — is usually the better balance, and it is worth stating in the acceptable-use documentation rather than leaving implicit.

Split tunnel or full tunnel, in deployment terms

The strategic trade is covered in the remote access article. What matters at deployment time is that the choice has consequences for capacity, and those are quantifiable in advance.

A full tunnel routes all user traffic through the gateway, which means the gateway needs encryption throughput for everything those users do — including video calls and streaming that have nothing to do with the business. Sizing a concentrator against the internal traffic alone and then enabling full tunnel is a reliable way to produce a slow VPN that users disable.

The practical measure is to size against realistic concurrency at peak, multiplied by expected per-user throughput, and to remember that encryption throughput rather than raw interface speed is the ceiling on most appliances. Where the specification quotes both, the encrypted figure is the one that applies.

Rolling out without a bad Monday

The deployment sequence matters more than any individual setting, because it determines whether a problem is discovered by two people or by everyone.

1. 1

   Build alongside, not instead of

   Where an existing remote access method is in place, stand the new one up in parallel. A migration with no fallback turns any surprise into an outage.

2. 2

   Pilot with people who can absorb friction

   IT first, then a small group deliberately chosen to include varied home setups — different ISPs, different routers, at least one person on a restrictive corporate guest network.

3. 3

   Test what the policy is supposed to prevent

   From a connected client, attempt to reach a system the design says should be unreachable, and confirm it fails and the denial is logged. Untested segmentation is a hypothesis.

4. 4

   Document the client setup as a user would experience it

   Screenshots and exact steps for each platform in use. Support load during a rollout is dominated by client configuration, not by the gateway.

5. 5

   Migrate in groups, with the old path live

   By team or by site, with a defined rollback for each group. Retire the old method only after the last group has been stable for a period.

6. 6

   Keep a break-glass path

   A documented way for an administrator to reach the environment if the VPN itself fails. A gateway that requires the VPN to fix it is a trap that gets sprung eventually.

Common mistakes

A representative scenario

A composite of situations we see repeatedly; no client detail is included.

A business replaces an ageing remote access setup with a new gateway over a weekend, decommissioning the old one to avoid running two. Monday produces a substantial support queue.

Roughly a quarter of users could connect and reach nothing, because the office LAN and their home networks shared 192.168.1.0/24. Another group could reach systems by address but not by name, because internal DNS was never pushed to clients. Full tunnel had been enabled without resizing, so those who did connect found everything slow. The old method was gone, so there was no fallback.

Recovery took most of a week. The durable fix was renumbering the office network onto a range in 10.0.0.0/8 — disruptive, and the only clean answer — with a separate range allocated to VPN clients so that policy could distinguish them. Internal DNS was pushed with split resolution. Split tunnel was adopted, since almost all of the business's applications were cloud-hosted and full tunnel was routing personal traffic through the office for no benefit.

Every one of those problems was visible in advance. None was a configuration error; all were planning decisions taken by default.

Deployment checklist

• Protocol chosen deliberately, with interoperability requirements known where equipment differs between ends.
• Internal addressing avoids ranges common on home routers.
• VPN clients have their own address range, distinct from any office LAN, so policy and logs can distinguish them.
• No two sites overlap in addressing, and the plan is documented outside the running configuration.
• Certificate authority, certificate lifetimes and renewal process are decided and recorded.
• Revocation is configured and has been tested by revoking a certificate and confirming it is refused.
• Certificate expiry is monitored with weeks of warning, including the CA root.
• Internal DNS is pushed to clients, and split versus full DNS was a deliberate decision.
• The concentrator is sized on encrypted throughput at realistic peak concurrency, with full-tunnel load accounted for if enabled.
• Remote users land in their own segment, not the server segment.
• Policy has been tested from a connected client by attempting what should be refused.
• Client setup is documented per platform as a user would experience it.
• Migration runs in parallel with the old method, in groups, with a rollback per group.
• A break-glass administrative path exists for when the VPN itself is unavailable.

Frequently asked questions

Conclusion

VPN deployments rarely fail on cryptography. They fail on addressing chosen years earlier, on DNS that was never pushed because address-based testing worked, on certificates whose expiry nobody recorded, and on migrations that removed the fallback before proving the replacement.

All four are visible during planning and invisible during a Saturday build, which is why the useful work happens before anyone touches a gateway. The topology question that precedes all of this — and whether a VPN is the right mechanism at all — is settled in the remote access article.