How to Set Up the Rublon Authentication Proxy in High Availability Mode

Last updated on August 3, 2026

Overview

Modern organizations depend on strong, always-available multi-factor authentication (MFA). If the server hosting the Auth Proxy instance becomes unavailable, VPN connections drop, corporate logons fail, and administrators can be locked out of critical systems.

This guide describes how to run the Rublon Authentication Proxy in High-Availability (HA) mode by deploying two identical Auth Proxy instances behind a Network Load Balancer. The Load Balancer actively monitors each proxy and automatically routes LDAP or RADIUS traffic to a healthy node. Should an instance (or its underlying host) be restarted, patched, or experience an unexpected outage, Rublon MFA authentication continues without user impact.

By the end of this procedure, you will have a resilient, horizontally scalable authentication layer that protects your organization from single-point-of-failure outages while keeping the configuration simple and repeatable.

Rublon Authentication Proxy High Availability Architecture Diagram

Diagram showing Rublon Authentication Proxy High Availability (HA) Architecture

Required Components

Two Rublon Authentication Proxy instances installed and configured on two separate servers.
One Network Load Balancer.
One Identity Provider (IdP), such as Active Directory, OpenLDAP, or FreeRADIUS.

Load Balancer – Initial Configuration (HA)

The Network Load Balancer needs to be placed in front of the two Rublon Auth Proxy instances:

Assign a public or private IPv4 address to the Load Balancer that your authenticators (VPNs, applications) will use as their RADIUS / LDAP endpoint.
Ensure network access to both Rublon Auth Proxy instances. Instances can be placed in two different networks as long as the Load Balancer has access to both of them and the routing allows communication.

Load Balancer – Load-Balancing Target Group & Health Checks Configuration (HA)

Configure a load-balancing target group that contains both Rublon Authentication Proxy instances. The Load Balancer must be able to reach each Auth Proxy on the following default ports (adjust them if you changed their values in the Auth Proxy config file):

Protocol	Port	Purpose
UDP	1812	RADIUS Proxy
TCP	389	LDAP Proxy & health-checks

Most Load Balancers perform a health check based on the TCP port. So, there are two possibilities regarding the Rublon Auth Proxy setup:

LDAP Proxy
RADIUS Proxy

LDAP Proxy

The Health Checks setup for LDAP Proxy is simple because no additional configuration is required apart from the standard LDAP Proxy setup.

LDAP is already using TCP packets, so you can use the LDAP Proxy’s TCP port for production traffic, as the Load Balancer target member, and for Health Checks.

Load Balancer Config for LDAP Proxy

Members of the target group specified as TCP 389 (or any other port you specified in the Auth Proxy config)
Health Checks specified as TCP 389 (or any other port you specified in the Auth Proxy config)

Example of Rublon Auth Proxy Config for LDAP Proxy

log:
  debug: true

rublon:
  api_server: https://core.rublon.net
  system_token: 06xxxxxxxxxxxxxxxxxxxxxxxxxxx
  secret_key: 23xxxxxxxxxxxxxxxxxxxxxxxxx

proxy_servers:
  - name: LDAP-Proxy
    type: LDAP
    ip: 0.0.0.0 # The IP address on which the proxy will listen.
    port: 389 # LDAP Proxy & Load Balancer health-check port
    transport_type: plain
    auth_source: LDAP_SOURCE_1
    auth_method: push,email
    auth_timeout: 60
    use_append_mode: true
    rublon_section: rublon

auth_sources:
  - name: LDAP_SOURCE_1
    type: LDAP
    ip: 10.x.x.x # The IP address of the Identity Provider (IdP)
    port: 389 # The port of the Identity Provider (IdP)
    transport_type: plain
    search_dn: dc=rublondemo,dc=local
    access_user_dn: CN=rublonadmin,OU=Rublon,DC=rublondemo,DC=local
    access_user_password: Password123
    username_attribute: CN

Note

Both proxy instances must have the same content of their respective config files so that authentication outcomes are consistent regardless of which node handles the request.

For more information, refer to Configuring the Rublon Authentication Proxy as an LDAP Proxy Server.

RADIUS Proxy

RADIUS uses UDP, so you still need a TCP listener for the Load Balancer’s health check probes.

Enable the LDAP Proxy (on TCP 389) purely for this purpose; it will not participate in authentication.

In this scenario, the LDAP Proxy is not used in any authentication process, but merely forces the Rublon Auth Proxy to open and listen on a TCP port as specified in the config (default: TCP 389). Then, this TCP port can be used as the Load Balancer’s Health Check.

Load Balancer Config for RADIUS Proxy

Members of the target group specified as UDP 1812 (or any other port you specified in the Auth Proxy config)
Health Checks specified as TCP 389 (or any other port you specified in the Auth Proxy config)

Example of Rublon Auth Proxy Config for RADIUS Proxy

log:
  debug: true

rublon:
  api_server: https://core.rublon.net
  system_token: 06xxxxxxxxxxxxxxxxxxxxxxxxxxx
  secret_key: 23xxxxxxxxxxxxxxxxxxxxxxxxx

proxy_servers:
  - name: LDAP-Proxy # Dummy listener for Load Balancer's TCP health checks
    type: LDAP
    ip: 0.0.0.0 # The IP address on which the proxy will listen.
    port: 389 # TCP port the LB probes for node health
    transport_type: plain
    auth_source: LDAP_SOURCE_1
    auth_method: push,email
    auth_timeout: 60
    use_append_mode: true
    rublon_section: rublon

  - name: RADIUS-Proxy
    type: RADIUS
    radius_secret: radius_secret
    ip: 0.0.0.0 # The IP address on which the proxy will listen.
    port: 1812 # UDP port the Load Balancer forwards RADIUS packets to
    mode: standard
    auth_source: LDAP_SOURCE_1
    rublon_section: rublon
    use_append_mode: true
    auth_method: push,email
    auth_timeout: 60

auth_sources:
  - name: LDAP_SOURCE_1
    type: LDAP
    ip: 10.x.x.x # The IP address of the Identity Provider (IdP)
    port: 389 # The port of the Identity Provider (IdP)
    transport_type: plain
    search_dn: dc=rublondemo,dc=local
    access_user_dn: CN=rublonadmin,OU=Rublon,DC=rublondemo,DC=local
    access_user_password: Password123
    username_attribute: CN

Note

Both proxy instances must have the same content of their respective config files so that authentication outcomes are consistent regardless of which node handles the request.

For more information, refer to Configuring the Rublon Authentication Proxy as a RADIUS Proxy Server.

Configuring Integrations to Work with Rublon Authentication Proxy in High Availability Mode

When your application, VPN, or service is configured for single-node Rublon Authentication Proxy, you normally enter the IP address of the Rublon Auth Proxy instance in the service’s LDAP or RADIUS settings. In an HA deployment, you must enter the IP address of the Load Balancer instead.

Rublon Authentication Proxy HA FAQs

Does Rublon Authentication Proxy HA use an active-active or active-passive model?

The architecture described in this guide uses an active-active model. Both Rublon Authentication Proxy instances run simultaneously and can process authentication requests, while the load balancer distributes traffic between healthy instances.

Which load balancer can I use with Rublon Authentication Proxy?

Use a Layer 4 load balancer that supports the required traffic and health-check configuration. For RADIUS, it must forward UDP traffic on port 1812 to the Rublon Authentication Proxy instances and perform an independent TCP health check on port 389. For LDAP, both the traffic and health check use TCP port 389 or another configured port. Suitable options may include AWS Network Load Balancer, Azure Standard Load Balancer, F5 BIG-IP, and FortiADC.

Troubleshooting

If you encounter any issues with your Rublon integration, please contact Rublon Support.

Rublon Authentication Proxy – Documentation

Configuring the Rublon Authentication Proxy as an LDAP Proxy Server

Configuring the Rublon Authentication Proxy as a RADIUS Proxy Server