Highly Available VPN: How to Remove the Single Point of Failure

A highly available VPN keeps remote access working when a server, a data center, or a network path fails without an admin manually intervening and without every connected user getting dropped and having to reconnect from scratch.

That is a higher bar than it sounds like. Most self-hosted VPNs, including plenty of "production" WireGuard and OpenVPN deployments, are a single Linux box with a public IP. It's reliable right up until it isn't, and when it isn't, every tunnel through it goes down at once.

The short version:

• A VPN gateway with no redundancy is a single point of failure, no matter how good the encryption is.
• Classic HA techniques for VPNs (VRRP/keepalived, DNS round robin) give you a live standby, but they don't preserve active sessions and they don't make the control plane like auth, config, or certificates highly available.
• Real HA means no single layer can take the whole system down: not the gateway, not the auth server, not DNS, not certificates.
• Pangolin gives you three different paths to this depending on how much infrastructure you want to run yourself, from free built-in failover to a fully self-hosted, clustered control plane.

What "Highly Available" Actually Means for a VPN

"Highly available" gets used loosely, so it's worth being specific about what it needs to cover. A VPN is a stack of things that can fail:

• The tunnel endpoint. The box terminating WireGuard or IPsec sessions. If it's one instance, it's one thing that can crash, get OOM-killed, or lose its NIC.
• Authentication and authorization. If your VPN checks users against an identity provider or a local policy store, that check has to keep working during a failure, not just the tunnel itself.
• DNS. If clients resolve your VPN endpoint by hostname, DNS has to be able to point them somewhere healthy and update fast enough that a dead record doesn't strand everyone.

A setup is only as available as its weakest layer. Plenty of "HA VPN" deployments solve the first bullet and quietly ignore the other three.

Why Most Self-Hosted VPNs Aren't Actually Highly Available

The default self-hosted VPN is a single instance: one process, one config file, one public IP, maybe a cron job renewing a certificate. It works well and it's easy to reason about, which is exactly why it's so common and it's a single point of failure. There's no failover because there's nothing to fail over to.

The next step up is usually active-passive failover with something like keepalived and VRRP: a floating IP moves from the primary to a standby when a health check fails. This genuinely helps - the VPN endpoint comes back online without a human - but it comes with limits:

• Session state doesn't move with the IP. Every established WireGuard or IPsec tunnel on the dead primary is gone. Clients have to notice and reconnect, which for many VPN clients means a manual nudge or a timeout.
• The standby is idle capacity. You're paying for a second box that does nothing until the first one dies.

The other common pattern, DNS round robin across multiple gateways, spreads new connections across healthy nodes but has the opposite problem: DNS doesn't know a node is unhealthy until you tell it. There likely is still no shared session or policy state between the nodes because they're independent islands that happen to share a hostname.

What Real VPN High Availability Requires

Getting past both of those failure modes takes three things working together:

1. Multiple active nodes, not one primary and an idle spare - so failover is "pick another already-running node" instead of "wait for a cold one to take over."
2. Shared state for anything that isn't the raw tunnel - user accounts, access policy, and certificates need to live somewhere every node can read, so a node coming up cold isn't starting from zero.
3. Fast, automatic rerouting at the layer clients actually use to find the VPN.

This is a meaningfully harder problem than clustering a stateless web server, because a VPN gateway is holding open, stateful, encrypted sessions - you can't just round-robin new TCP connections and call it a day.

How Pangolin Gets You There

Pangolin combines a reverse proxy and a WireGuard-based VPN in one platform, and it gives you three different levels of high availability depending on how much of the infrastructure you want to own.

Free: multi-site routing and health-checked failover

Every Pangolin deployment - including the free, self-hosted edition - supports attaching more than one site (Pangolin's lightweight connector) to the same resource. Pangolin health-checks each site and routes client traffic through whichever one is fastest and actually online. If a site goes down, clients start using the next best one automatically, no DNS change and no manual failover required.

This solves the most common real-world case: redundant paths to the same backend, whether that's two Newt connectors in the same data center for hardware redundancy or two offices that can both reach the same internal service. It doesn't make your control plane redundant, but it removes a large category of "one server died and now nobody can reach the app" incidents at no extra infrastructure cost.

Managed: Remote Nodes on Pangolin Cloud

If you don't want to run the control plane yourself at all, Pangolin Cloud's Remote Nodes let you self-host just the traffic edge which is the piece that terminates WireGuard tunnels and serves traffic. You can decide where your egress and relay capacity physically live without taking on a database, a DNS service, or an ACME client yourself.

Fully self-hosted: Enterprise clustering

For teams that want everything on their own infrastructure with no single point of failure anywhere, Pangolin's self-hosted clustering runs multiple full Pangolin nodes each with its own Gerbil tunnel manager and Traefik proxy behind a load balancer you control, sharing state through PostgreSQL and Redis-compatible Valkey. Any node can authenticate a user, resolve DNS, or serve a tunnel. If one goes down, sites automatically reconnect to a healthy node in seconds, DNS updates to point at it, and traffic keeps flowing. We wrote up exactly how this works - the certificate handoff, the cross-node relay, the failover logic - in how we built high availability into Pangolin.

What to Look for in a Highly Available VPN

If you're evaluating options, not just Pangolin, these are the questions worth asking:

• Does failover preserve active sessions, or does every client have to reconnect from scratch?
• Is the control plane - auth, policy, config - redundant, or just the tunnel endpoint?
• How does DNS or load balancing know a node is unhealthy, and how fast does it react?
• Who issues and renews TLS certificates, and what happens if that node is the one that's down?
• Can you add capacity by adding a node, or does scaling mean re-architecting?
• Does the solution require sending your traffic through a third party's cloud to get HA, or can it run entirely on infrastructure you control?

FAQ

Is a VPN with a hot standby the same as a highly available VPN?

Not quite. A hot standby (active-passive with VRRP or similar) gets your gateway back online automatically, but it usually drops existing sessions and doesn't make auth, DNS, or certificate issuance redundant on its own. True HA needs those layers covered too.

Do I need Kubernetes to run a highly available VPN?

No. Pangolin's clustering runs as plain Docker Compose services across multiple hosts, coordinating through PostgreSQL and Redis rather than a container orchestrator.

Can I get VPN high availability without running my own database and load balancer?

Yes - Pangolin Cloud's Remote Nodes let you self-host the traffic edge while the control plane, DNS, and failover coordination run in Pangolin Cloud.

What's the minimum setup for a fully self-hosted HA VPN with Pangolin?

Two Pangolin nodes plus a shared PostgreSQL and Redis-compatible server, behind a load balancer you provide. See the clustering requirements and deployment guide.

Related reading

• How We Built High Availability Into Pangolin
• Understanding Clustering
• Pangolin vs. Tailscale
• What is an Identity-Aware Proxy (IAP)?
• Pangolin Remote Nodes: Cloud Control Plane & Failover

Learn more

Want to see it running? Self-host Pangolin to try free multi-site failover today, or get started on Pangolin Cloud for a managed control plane. For a fully self-hosted, clustered deployment, reach out to our team.