defguard
  • Introduction
  • User documentation (help)
    • Configuring VPN
      • Defguard Desktop Client
        • Update instance
      • Other WireGuard® Clients
        • Configuring a device for new VPN Location manually
    • Password change / Reset
    • Enrollment & Onboarding
      • With internal Defguard SSO
      • With external SSO (Google/Microsoft/Custom)
    • Setting up 2FA/MFA
    • Desktop Client
    • CLI Client
  • Admin & features
    • Deploying your instance
      • One-line install script
      • Standalone package based installation
      • Docker images and tags
      • Docker Compose
      • Kubernetes
      • Upgrading
      • Gateway
        • Running gateway on MikroTik routers
      • Securing gRPC communication
      • OpenID RSA key
      • Configuration
      • Pre-production and development releases
      • High Availability and Failover
      • Health check
    • Features & configuration
      • Zero-Trust VPN with 2FA/MFA
        • Create/manage VPN Location
        • Network overview
        • Executing custom gateway commands
        • Multi-Factor Authentication (MFA/2FA)
          • MFA Architecture
        • Remote desktop client configuration
        • DNS and domains
      • Remote user enrollment
        • User onboarding after enrollment
      • SSO (OpenID Connect)
        • Portainer
        • Grafana setup
        • Proxmox
        • Matrix / Synapse
        • Django
        • MinIO
        • Vault
      • SMTP for email notifications
      • YubiKey Provisioning
      • Webhooks
      • Forward auth
      • SSH Authentication
      • Network devices
      • Gateway notifications
      • New version notifications
  • Troubleshooting Guide
    • Sending support information
    • Client Windows installer exit codes
    • Client "All traffic" connection issues
    • WebAuthn security keys
  • Enterprise Features
    • License
    • Enteprise features
      • Automatic (real time) desktop client configuration & sync
      • External OpenID providers
        • Google
        • Microsoft
        • Zitadel
        • Keycloak
        • JumpCloud
        • Okta
        • Custom
      • External OIDC secure enrollment
      • VPN & Client behavior customization
      • REST API
      • Access Control List
        • ACL Aliases
      • LDAP and Active Directory integration
        • Configuration
        • Settings table
        • Two-way LDAP and Active Directory synchronization
  • Tutorials
    • Step by step setting up a VPN server
      • Adding additional VPN locations
  • In depth
    • Roadmap
    • Architecture
      • How do VPN statistics work
      • Security concepts
  • For Developers
    • Contributing
    • Environment setup
    • Translations (core/web)
      • Switching language
      • Adding translations
  • Translations (client)
    • Adding translations
  • Contact us
    • Community & Support
Powered by GitBook
On this page
  • Gateway - High Availability
  • Determining if multiple gateways are running
  • What is the gateway peers persistence (if core/proxy services fail)
  • Core / Proxy - Failover

Was this helpful?

Edit on GitHub
  1. Admin & features
  2. Deploying your instance

High Availability and Failover

PreviousPre-production and development releasesNextHealth check

Last updated 2 months ago

Was this helpful?

Gateway - High Availability

We support running multiple gateways for a single VPN instance or location, enabling active-passive configurations. Active-active configurations should also be possible but come with some caveats. Since our gateway uses a vanilla kernel WireGuard®, there are multiple approaches for implementation.

Please also see documentation of where each .

Deploying multiple gateways for one location

To have a multi-gateway setup for a given location, you will need to under the same location.

If you already have a gateway deployed and want to add another one for the location, go to VPN Overview -> Click: Edit Location Settings (in the top right corner), then choose the location you want to add the new gateway to, and follow the deployment instructions:

Each gateway deployed for a given location will receive the same network configuration and will bind to the defined port in the location's Gateway Port.

The only thing left to do is to point your traffic to those gateways, which can be accomplished in several ways:

  • Floating public IP - if you choose this scenario, please remember that the IP must be the IP specified in the Location Gateway Address. In this scenario, the floating IP switches between your gateway servers, directing the traffic to one of the two gateways.

  • Proxy/load balancing - also remember that the proxy must be configured with the Gateway Address and Gateway Port. In this scenario, your clients connect to the proxy/load balancer, which direct the VPN traffic (UDP) to one of your gateway backends.

Active-active setups

Active-active setups should also be possible but come with some caveats. Here are the currently known issues with such configurations:

Determining if multiple gateways are running

All gateways that are successfully connected for the location are displayed under the Location in VPN Overview, here is an example for two gateways:

What is the gateway peers persistence (if core/proxy services fail)

  1. For VPN Locations without MFA - it's persistent until the system reboot - even if the gateway will not work - as the gateway configures WireGuard "in kernel".

  2. For VPN Locations with MFA, this depends on the Peer Disconnect Threshold (seconds) setting in the VPN Location settings. This setting specifies that if the peer is inactive for (defined seconds), the gateway should remove it from the configuration. Therefore, if the proxy/core is not operational, MFA authentication will fail, and the peer will not be added if it is disconnected.

Core / Proxy - Failover

The core service handles gateway states as well as core connects to the proxy. Since proxy serves HTTP based protocol communication and should be in the public Internet, it needs to be secure, thus core connects to the proxy.

This way core can be in an Intranet network segment and proxy can be in DMZ, making Core completely cut-off on firewall from the Internet (you only can have only outgoing firewall rules from Intranet allowing only for core to connect to proxy).

So High Availability for core and proxy gets complicated, with multiple proxies core needs to manage those connections. We already have most of the code for that ready, but it's not yet production ready.

How to bullet-proof proxy & core with failover?

We recommend to deploy them on a failover solution - like on a kubernetes cluster (even small one - like mini-kube) . This way, kubernetes manages: healthchecks and does failover. You can have cluster N-nodes and if any VM/node with Core/Proxy goes offline or health checks fail - it's migrated to a new node.

Multiple running gateways bound to one location with network traffic distributed between them may produce invalid network usage statistics, making the network usage graphs and displays on the dashboard unreliable. Related issue:

https://github.com/DefGuard/defguard/issues/1022
Creating a New VPN location
deploy the gateway on each one of your servers
location setting has information regarding high-availability