Issue with Pritunl + Entra ID authentication during node failover

ebu · June 23, 2026, 9:26am

Hello,

I am experiencing an issue with Pritunl authentication (Entra ID / Azure SSO) when using two hosts and performing a failover between nodes.

Setup
Two nodes: VM1 and VM2 (same priority)
Both nodes are attached to the same Pritunl server listening on TCP 8443
Both nodes are fully functional

Pritunl version : Server v1.32.4567.52 36a664 - Client : v1.3.4566.62

Behavior
Authentication via Entra ID works perfectly:

When both nodes are active
When only one node is active

However, when I stop the Pritunl service on the node where the client is currently connected (Or if I reboot the node) : sudo systemctl stop pritunl

On the client side: The connection times out and disconnects

On the server side, in logs:
The client attempts to connect to the second node
Server logs example

[VM1][2026-06-23 07:59:03,832][INFO] Authenticating user
user_name = “my_mail@org.com”
factors   = [“azure”]

[VM1][2026-06-23 07:59:03,837][INFO] Client authentication with sso token
user_name   = “my_mail@org.com”
org_name    = “Org”
server_name = “Org_srv”

[VM1][2026-06-23 07:59:04,920][INFO] Storing authentication cache token

sudo systemctl stop pritunl on VM1

[VM2][2026-06-23 07:59:27,859][INFO] Authenticating user
user_name = “my_mail@org.com”
factors   = [“azure”]

A tcpdump on the client shows:

Clean disconnection from VM1
New TCP connection to VM2 on port 8443
Immediately followed by pritunl client disconnection

Using a local proxy (Burp Suite):

I do not see any Entra ID reauthentication during failover, it seems expected (since SSO token reuse should occur)
Full authentication is visible only during initial login

Question
Is there a way to achieve seamless failover between Pritunl nodes?

When a node is stopped or restarted, we would like the client to automatically reconnect to the other node without requiring the user to click “Connect” again or reauthenticate.
Is this behavior expected with Pritunl + Entra ID, or is there a configuration (session sharing, token synchronization, HA setup, etc.) that allows automatic reconnection?

Thanks in advance for your help.

zach · June 23, 2026, 8:52pm

This might be the nil pointer dereference that occurred on reconnection. The service would crash and auto restart so the logs won’t indicate any errors. It was fixed in the recent Pritunl Client v1.3.4655.98 release.

If the issue still occurs use the commands below to run the client background service in a terminal to check for errors. This is only possible on macOS and Linux.

macOS

sudo launchctl unload /Library/LaunchDaemons/com.pritunl.service.plist
sudo /Applications/Pritunl.app/Contents/Resources/pritunl-server

Linux

sudo systemctl stop pritunl-client
sudo pritunl-client-service

ebu · July 2, 2026, 6:36am

Hello thanks for your message.
I just updated to the indicated version: 1.3.4655.98. But it does not reconnect automatically.

If I restart the pritunl service, on the client I see a timeout (Connection timed out on <session_name> (<my_email_address>), I see it switch to the other IP, it appears connected for about 5 seconds (the status time increases) but the client then goes to the disconnected status.

If I stop one node (sudo systemctl stop pritunl), and stop pritunl on the other one and few second after I restart the service it will reconnect without any problem on this last node (the first node is still stoped) and without prompting me for SSO authentication.

So it is like if the automatique process work, but in the same node.

Regards

zach · July 6, 2026, 9:48am

Check the service logs in the top right menu of the client for errors. Also check the logs for that profile from the drop down menu in the client logs viewer.

ebu · August 6, 2026, 3:08pm

Hello @zach ,
Sorry for the delay for this reply. So You will find the client log, after a “sudo systemctl stop pritunl” on node01. And we would have expected to be reconnected to node02. We can see the client trying but failing. In the node02 log, we see:
==> /var/log/pritunl.log <==
[node02][2026-08-06 14:55:59,470][INFO] Authenticating user
user_name = “myusername@myorg.com”
factors = [“azure”]
And the client failed to reconnect.

Service log :
2026-08-06 16:55:45 us=171000 268 variation(s) on previous 4 message(s) suppressed by --mute
2026-08-06 16:55:45 us=171000 Connection reset, restarting [0]
2026-08-06 16:55:45 us=171000 TCP/UDP: Closing socket
2026-08-06 16:55:45 us=187000 SIGUSR1[soft,connection-reset] received, process restarting
2026-08-06 16:55:45 us=187000 Restart pause, 2 second(s)
2026-08-06 16:55:47 us=203000 Re-using SSL/TLS context
2026-08-06 16:55:47 us=203000 Outgoing Control Channel Authentication: Using 160 bit message hash ‘SHA1’ for HMAC authentication
2026-08-06 16:55:47 us=203000 NOTE: --mute triggered…
2026-08-06 16:55:47 us=203000 1 variation(s) on previous 4 message(s) suppressed by --mute
2026-08-06 16:55:47 us=203000 Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]
2026-08-06 16:55:47 us=203000 NOTE: --mute triggered…
2026-08-06 16:55:47 us=203000 1 variation(s) on previous 4 message(s) suppressed by --mute
2026-08-06 16:55:47 us=203000 TCP/UDP: Preserving recently used remote address: [AF_INET]node01:8443
2026-08-06 16:55:47 us=203000 Socket Buffers: R=[65536->393216] S=[64512->393216]
2026-08-06 16:55:47 us=203000 Attempting to establish TCP connection with [AF_INET]node01:8443
2026-08-06 16:55:51 us=234000 TCP: connect to [AF_INET]node01:8443 failed: Unknown error
2026-08-06 16:55:51 us=234000 SIGUSR1[connection failed(soft),connection-failed] received, process restarting
2026-08-06 16:55:51 us=234000 Restart pause, 2 second(s)
2026-08-06 16:55:53 us=265000 Re-using SSL/TLS context
2026-08-06 16:55:53 us=265000 Outgoing Control Channel Authentication: Using 160 bit message hash ‘SHA1’ for HMAC authentication
2026-08-06 16:55:53 us=265000 NOTE: --mute triggered…
2026-08-06 16:55:53 us=265000 1 variation(s) on previous 4 message(s) suppressed by --mute
2026-08-06 16:55:53 us=265000 Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]
2026-08-06 16:55:53 us=265000 NOTE: --mute triggered…
2026-08-06 16:55:53 us=265000 1 variation(s) on previous 4 message(s) suppressed by --mute
2026-08-06 16:55:53 us=265000 TCP/UDP: Preserving recently used remote address: [AF_INET]node01:8443
2026-08-06 16:55:53 us=265000 Socket Buffers: R=[65536->393216] S=[64512->393216]
2026-08-06 16:55:53 us=265000 Attempting to establish TCP connection with [AF_INET]node01:8443
2026-08-06 16:55:57 us=281000 TCP: connect to [AF_INET]node01:8443 failed: Unknown error
2026-08-06 16:55:57 us=281000 SIGUSR1[connection failed(soft),connection-failed] received, process restarting
2026-08-06 16:55:57 us=281000 Restart pause, 2 second(s)
2026-08-06 16:55:59 us=296000 Re-using SSL/TLS context
2026-08-06 16:55:59 us=296000 Outgoing Control Channel Authentication: Using 160 bit message hash ‘SHA1’ for HMAC authentication
2026-08-06 16:55:59 us=296000 NOTE: --mute triggered…
2026-08-06 16:55:59 us=296000 1 variation(s) on previous 4 message(s) suppressed by --mute
2026-08-06 16:55:59 us=312000 Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]
2026-08-06 16:55:59 us=312000 NOTE: --mute triggered…
2026-08-06 16:55:59 us=312000 1 variation(s) on previous 4 message(s) suppressed by --mute
2026-08-06 16:55:59 us=312000 TCP/UDP: Preserving recently used remote address: [AF_INET]node02:8443
2026-08-06 16:55:59 us=312000 Socket Buffers: R=[65536->393216] S=[64512->393216]
2026-08-06 16:55:59 us=312000 Attempting to establish TCP connection with [AF_INET]node02:8443
2026-08-06 16:55:59 us=328000 NOTE: --mute triggered…
2026-08-06 16:55:59 us=343000 3 variation(s) on previous 4 message(s) suppressed by --mute
2026-08-06 16:55:59 us=343000 TLS: Initial packet from [AF_INET]node02:8443, sid=b505b141 4fa56ec9
2026-08-06 16:55:59 us=421000 NOTE: --mute triggered…
2026-08-06 16:55:59 us=453000 7 variation(s) on previous 4 message(s) suppressed by --mute
2026-08-06 16:55:59 us=453000 [691704cb38ec76efbcc8845f] Peer Connection Initiated with [AF_INET]node02:8443
2026-08-06 16:55:59 us=453000 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2026-08-06 16:55:59 us=453000 NOTE: --mute triggered…
2026-08-06 16:55:59 us=531000 1 variation(s) on previous 4 message(s) suppressed by --mute
2026-08-06 16:55:59 us=531000 AUTH: Received control message: AUTH_FAILED
2026-08-06 16:55:59 us=531000 TCP/UDP: Closing socket
2026-08-06 16:55:59 us=531000 C:\WINDOWS\system32\route.exe DELETE 10.100.0.0 MASK 255.255.0.0 172.22.0.1
2026-08-06 16:55:59 us=546000 NOTE: --mute triggered…
2026-08-06 16:56:00 us=656000 177 variation(s) on previous 4 message(s) suppressed by --mute
2026-08-06 16:56:00 us=656000 Closing tap-windows6 interface
2026-08-06 16:56:00 us=828000 TAP: DHCP address released
2026-08-06 16:56:00 us=828000 SIGTERM[soft,auth-failure] received, process exiting

Profile log :
[2026-08-06 16:55:59][INFO] connection: Stopping reconnect ◆ client_disconnect=false ◆ client_disconnect_waiters=0 ◆ client_disconnected=false ◆ client_provider=true ◆ client_startime=4224 ◆ data_iface=“” ◆ data_mode=“” ◆ data_remotes=string{“synchostname.myorg.com*”, “node01”, “node02”} ◆ data_status=“connected” ◆ data_timestamp=1786028156 ◆ data_tun_iface=“” ◆ ovpn_auth_failed=true ◆ ovpn_cmd=true ◆ ovpn_connected=true ◆ ovpn_dir=“C:\Program Files (x86)\Pritunl\openvpn” ◆ ovpn_last_auth_failed=-1 ◆ ovpn_management_pass=true ◆ ovpn_management_port=9701 ◆ ovpn_path=“C:\Program Files (x86)\Pritunl\openvpn\openvpn.exe” ◆ ovpn_remotes=string{“node01(8443/tcp-client)”, “node01(8443/tcp-client)”, “node02(8443/tcp-client)”} ◆ ovpn_running=1 ◆ ovpn_tap_iface=“Pritunl 1” ◆ profile_dco=false ◆ profile_device_auth=false ◆ profile_disable_dns=false ◆ profile_disable_gateway=false ◆ profile_dynamic_firewall=false ◆ profile_force_connect=false ◆ profile_force_dns=false ◆ profile_geo_sort=false ◆ profile_id=“b701a05dc2172052” ◆ profile_mode=“ovpn” ◆ profile_reconnect=true ◆ profile_sso_auth=true ◆ profile_system_profile=false ◆ profile_timeout=false ◆ reason=“ovpn_auth_error” ◆ state_closed=false ◆ state_closed_waiters=0 ◆ state_deadline=false ◆ state_delay=false ◆ state_id=“64fb2993fea856c3” ◆ state_interactive=true ◆ state_no_reconnect=false ◆ state_stop=false ◆ state_system_interactive=false ◆ state_temp_paths=string{“C:\ProgramData\Pritunl\Temp\b701a05dc2172052-management.txt”, “C:\ProgramData\Pritunl\Temp\b701a05dc2172052”, “C:\ProgramData\Pritunl\Temp\b701a05dc2172052.auth”, “C:\ProgramData\Pritunl\Temp\b701a05dc2172052-block.bat”} ◆ state_time=time.Date(2026, time.August, 6, 15, 45, 35, 37465600, time.Local) ◆ wg_bash_path=“” ◆ wg_conf_path=“” ◆ wg_conf_path2=“” ◆ wg_connected=false ◆ wg_last_handshake=0 ◆ wg_path=“C:\Program Files (x86)\Pritunl\wireguard\wg.exe” ◆ wg_priv_key=false ◆ wg_pub_key=false ◆ wg_quick_path=“C:\Program Files (x86)\Pritunl\wireguard\wg-quick.exe” ◆ wg_server_pub_key=false ◆ wg_sso_start=time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC) ◆ wg_sso_token=false ◆ wg_util_path=“C:\Program Files (x86)\Pritunl\wireguard\wireguard.exe”
[2026-08-06 16:56:02][ERRO] connection: Disconnecting ◆ client_disconnect=true ◆ client_disconnect_waiters=0 ◆ client_disconnected=false ◆ client_provider=true ◆ client_startime=4227 ◆ data_iface=“” ◆ data_mode=“” ◆ data_remotes=string{“synchostname.myorg.com*”, “node01”, “node02”} ◆ data_status=“connected” ◆ data_timestamp=1786028156 ◆ data_tun_iface=“” ◆ ovpn_auth_failed=true ◆ ovpn_cmd=true ◆ ovpn_connected=true ◆ ovpn_dir=“C:\Program Files (x86)\Pritunl\openvpn” ◆ ovpn_last_auth_failed=0 ◆ ovpn_management_pass=true ◆ ovpn_management_port=9701 ◆ ovpn_path=“C:\Program Files (x86)\Pritunl\openvpn\openvpn.exe” ◆ ovpn_remotes=string{“node01(8443/tcp-client)”, “node01(8443/tcp-client)”, “node02(8443/tcp-client)”} ◆ ovpn_running=-1 ◆ ovpn_tap_iface=“Pritunl 1” ◆ profile_dco=false ◆ profile_device_auth=false ◆ profile_disable_dns=false ◆ profile_disable_gateway=false ◆ profile_dynamic_firewall=false ◆ profile_force_connect=false ◆ profile_force_dns=false ◆ profile_geo_sort=false ◆ profile_id=“b701a05dc2172052” ◆ profile_mode=“ovpn” ◆ profile_reconnect=true ◆ profile_sso_auth=true ◆ profile_system_profile=false ◆ profile_timeout=false ◆ state_closed=false ◆ state_closed_waiters=0 ◆ state_deadline=false ◆ state_delay=false ◆ state_id=“64fb2993fea856c3” ◆ state_interactive=true ◆ state_no_reconnect=true ◆ state_stop=true ◆ state_system_interactive=false ◆ state_temp_paths=string{“C:\ProgramData\Pritunl\Temp\b701a05dc2172052-management.txt”, “C:\ProgramData\Pritunl\Temp\b701a05dc2172052”, “C:\ProgramData\Pritunl\Temp\b701a05dc2172052.auth”, “C:\ProgramData\Pritunl\Temp\b701a05dc2172052-block.bat”} ◆ state_time=time.Date(2026, time.August, 6, 15, 45, 35, 37465600, time.Local) ◆ wg_bash_path=“” ◆ wg_conf_path=“” ◆ wg_conf_path2=“” ◆ wg_connected=false ◆ wg_last_handshake=0 ◆ wg_path=“C:\Program Files (x86)\Pritunl\wireguard\wg.exe” ◆ wg_priv_key=false ◆ wg_pub_key=false ◆ wg_quick_path=“C:\Program Files (x86)\Pritunl\wireguard\wg-quick.exe” ◆ wg_server_pub_key=false ◆ wg_sso_start=time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC) ◆ wg_sso_token=false ◆ wg_util_path=“C:\Program Files (x86)\Pritunl\wireguard\wireguard.exe”
[2026-08-06 16:56:04][INFO] profile: Disconnected without restart ◆ client_disconnect=true ◆ client_disconnect_waiters=0 ◆ client_disconnected=true ◆ client_provider=true ◆ client_startime=4229 ◆ data_iface=“” ◆ data_mode=“” ◆ data_remotes=string{“synchostname.myorg.com*”, “node01”, “node02”} ◆ data_status=“disconnected” ◆ data_timestamp=0 ◆ data_tun_iface=“” ◆ ovpn_auth_failed=true ◆ ovpn_cmd=true ◆ ovpn_connected=true ◆ ovpn_dir=“C:\Program Files (x86)\Pritunl\openvpn” ◆ ovpn_last_auth_failed=2 ◆ ovpn_management_pass=true ◆ ovpn_management_port=9701 ◆ ovpn_path=“C:\Program Files (x86)\Pritunl\openvpn\openvpn.exe” ◆ ovpn_remotes=string{“node01(8443/tcp-client)”, “node01(8443/tcp-client)”, “node02(8443/tcp-client)”} ◆ ovpn_running=-1 ◆ ovpn_tap_iface=“Pritunl 1” ◆ profile_dco=false ◆ profile_device_auth=false ◆ profile_disable_dns=false ◆ profile_disable_gateway=false ◆ profile_dynamic_firewall=false ◆ profile_force_connect=false ◆ profile_force_dns=false ◆ profile_geo_sort=false ◆ profile_id=“b701a05dc2172052” ◆ profile_mode=“ovpn” ◆ profile_reconnect=true ◆ profile_sso_auth=true ◆ profile_system_profile=false ◆ profile_timeout=false ◆ state_closed=true ◆ state_closed_waiters=0 ◆ state_deadline=false ◆ state_delay=false ◆ state_id=“64fb2993fea856c3” ◆ state_interactive=true ◆ state_no_reconnect=true ◆ state_stop=true ◆ state_system_interactive=false ◆ state_temp_paths=string{“C:\ProgramData\Pritunl\Temp\b701a05dc2172052-management.txt”, “C:\ProgramData\Pritunl\Temp\b701a05dc2172052”, “C:\ProgramData\Pritunl\Temp\b701a05dc2172052.auth”, “C:\ProgramData\Pritunl\Temp\b701a05dc2172052-block.bat”} ◆ state_time=time.Date(2026, time.August, 6, 15, 45, 35, 37465600, time.Local) ◆ wg_bash_path=“” ◆ wg_conf_path=“” ◆ wg_conf_path2=“” ◆ wg_connected=false ◆ wg_last_handshake=0 ◆ wg_path=“C:\Program Files (x86)\Pritunl\wireguard\wg.exe” ◆ wg_priv_key=false ◆ wg_pub_key=false ◆ wg_quick_path=“C:\Program Files (x86)\Pritunl\wireguard\wg-quick.exe” ◆ wg_server_pub_key=false ◆ wg_sso_start=time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC) ◆ wg_sso_token=false ◆ wg_util_path=“C:\Program Files (x86)\Pritunl\wireguard\wireguard.exe”
[2026-08-06 16:56:05][ERRO] connection: Failed to get interface address ◆ client_disconnect=true ◆ client_disconnect_waiters=0 ◆ client_disconnected=true ◆ client_provider=true ◆ client_startime=4230 ◆ data_iface=“” ◆ data_mode=“” ◆ data_remotes=string{“synchostname.myorg.com*”, “node01”, “node02”} ◆ data_status=“disconnected” ◆ data_timestamp=0 ◆ data_tun_iface=“” ◆ output=“\r\nConfiguration pour l’interface «\u00a0Pritunl 1\u00a0»\r\n DHCP activé: Oui\r\n Métrique de l’interface\u00a0: 5\r\n\r\n” ◆ ovpn_auth_failed=true ◆ ovpn_cmd=true ◆ ovpn_connected=true ◆ ovpn_dir=“C:\Program Files (x86)\Pritunl\openvpn” ◆ ovpn_last_auth_failed=2 ◆ ovpn_management_pass=true ◆ ovpn_management_port=9701 ◆ ovpn_path=“C:\Program Files (x86)\Pritunl\openvpn\openvpn.exe” ◆ ovpn_remotes=string{“node01(8443/tcp-client)”, “node01(8443/tcp-client)”, “node02(8443/tcp-client)”} ◆ ovpn_running=-1 ◆ ovpn_tap_iface=“Pritunl 1” ◆ profile_dco=false ◆ profile_device_auth=false ◆ profile_disable_dns=false ◆ profile_disable_gateway=false ◆ profile_dynamic_firewall=false ◆ profile_force_connect=false ◆ profile_force_dns=false ◆ profile_geo_sort=false ◆ profile_id=“b701a05dc2172052” ◆ profile_mode=“ovpn” ◆ profile_reconnect=true ◆ profile_sso_auth=true ◆ profile_system_profile=false ◆ profile_timeout=false ◆ state_closed=true ◆ state_closed_waiters=0 ◆ state_deadline=false ◆ state_delay=false ◆ state_id=“64fb2993fea856c3” ◆ state_interactive=true ◆ state_no_reconnect=true ◆ state_stop=true ◆ state_system_interactive=false ◆ state_temp_paths=string{“C:\ProgramData\Pritunl\Temp\b701a05dc2172052-management.txt”, “C:\ProgramData\Pritunl\Temp\b701a05dc2172052”, “C:\ProgramData\Pritunl\Temp\b701a05dc2172052.auth”, “C:\ProgramData\Pritunl\Temp\b701a05dc2172052-block.bat”} ◆ state_time=time.Date(2026, time.August, 6, 15, 45, 35, 37465600, time.Local) ◆ wg_bash_path=“” ◆ wg_conf_path=“” ◆ wg_conf_path2=“” ◆ wg_connected=false ◆ wg_last_handshake=0 ◆ wg_path=“C:\Program Files (x86)\Pritunl\wireguard\wg.exe” ◆ wg_priv_key=false ◆ wg_pub_key=false ◆ wg_quick_path=“C:\Program Files (x86)\Pritunl\wireguard\wg-quick.exe” ◆ wg_server_pub_key=false ◆ wg_sso_start=time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC) ◆ wg_sso_token=false ◆ wg_util_path=“C:\Program Files (x86)\Pritunl\wireguard\wireguard.exe”

Best regards
Eric

zach · August 6, 2026, 5:20pm

Check the server output in the servers tab for the authentication failure reason. This will be shown in the output after the AUTH_FAILED.

ebu · August 7, 2026, 9:17am

Hello, In the server tab / server output the logs are :

[node2] 2026-08-07 08:47:33 us=786925 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 NOTE: --mute triggered...
[node2] 2026-08-07 08:47:37 us=404948 tcp4-server:168.63.129.16:51610 13384 variation(s) on previous 10 message(s) suppressed by --mute
[node2] 2026-08-07 08:47:37 us=404997 tcp4-server:168.63.129.16:51610 Connection reset, restarting [0]
[node2] 2026-08-07 08:47:37 us=405006 tcp4-server:168.63.129.16:51610 SIGUSR1[soft,connection-reset] received, client-instance restarting
[node2] 2026-08-07 08:47:37 us=405024 register signal: SIGTERM (close_context)
[node2] 2026-08-07 08:47:37 us=405162 TCP/UDP: Closing socket
[node2] 2026-08-07 08:47:37 us=406083 MULTI: multi_create_instance called
[node2] 2026-08-07 08:47:37 us=406180 Re-using SSL/TLS context
[node2] 2026-08-07 08:47:37 us=406255 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
[node2] 2026-08-07 08:47:37 us=406268 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
[node2] 2026-08-07 08:47:37 us=406342 Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]
[node2] 2026-08-07 08:47:37 us=406371 Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
[node2] 2026-08-07 08:47:37 us=406456 TCP connection established with [AF_INET]168.63.129.16:52279
[node2] 2026-08-07 08:47:37 us=406487 Socket flags: TCP_NODELAY=1 succeeded
[node2] 2026-08-07 08:47:37 us=406512 TCPv4_SERVER link local: (not bound)
[node2] 2026-08-07 08:47:37 us=406518 TCPv4_SERVER link remote: [AF_INET]168.63.129.16:52279
[node2] 2026-08-07 08:47:38 us=85270 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 TUN READ [109]
[node2] 2026-08-07 08:47:38 us=85357 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 TCPv4_SERVER WRITE [137] to [AF_INET]MyPublicIPaddress:17401: P_DATA_V2 kid=0 DATA len=136
[node2] 2026-08-07 08:47:38 us=85390 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 TUN READ [210]
[node2] 2026-08-07 08:47:38 us=85405 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 NOTE: --mute triggered...
[node1] 2026-08-07 08:47:38 us=232115 register signal: SIGUSR1 (connection-reset)
[node1] 2026-08-07 08:47:38 us=232157 tcp4-server:168.63.129.16:57934 Connection reset, restarting [0]
[node1] 2026-08-07 08:47:38 us=232165 tcp4-server:168.63.129.16:57934 SIGUSR1[soft,connection-reset] received, client-instance restarting
[node1] 2026-08-07 08:47:38 us=232179 register signal: SIGTERM (close_context)
[node1] 2026-08-07 08:47:38 us=232309 TCP/UDP: Closing socket
[node1] 2026-08-07 08:47:38 us=233119 MULTI: multi_create_instance called
[node1] 2026-08-07 08:47:38 us=233184 Re-using SSL/TLS context
[node1] 2026-08-07 08:47:38 us=233259 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
[node1] 2026-08-07 08:47:38 us=233270 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
[node1] 2026-08-07 08:47:38 us=233348 Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]
[node1] 2026-08-07 08:47:38 us=233359 Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
[node1] 2026-08-07 08:47:38 us=233428 TCP connection established with [AF_INET]168.63.129.16:57993
[node1] 2026-08-07 08:47:38 us=233437 Socket flags: TCP_NODELAY=1 succeeded
[node1] 2026-08-07 08:47:38 us=233444 TCPv4_SERVER link local: (not bound)
[node1] 2026-08-07 08:47:38 us=233450 TCPv4_SERVER link remote: [AF_INET]168.63.129.16:57993
[node2] 2026-08-07 08:47:39 us=161365 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 6928 variation(s) on previous 10 message(s) suppressed by --mute
[node2] 2026-08-07 08:47:39 us=161393 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 MULTI: packet dropped due to output saturation (multi_process_incoming_tun)
[node2] 2026-08-07 08:47:39 us=161400 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 TUN READ [0]
[node2] 2026-08-07 08:47:39 us=161410 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 MULTI: packet dropped due to output saturation (multi_process_incoming_tun)
[node2] 2026-08-07 08:47:39 us=161416 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 TUN READ [0]
[node2] 2026-08-07 08:47:39 us=161423 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 MULTI: packet dropped due to output saturation (multi_process_incoming_tun)
[node2] 2026-08-07 08:47:39 us=161428 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 TUN READ [0]
[node2] 2026-08-07 08:47:39 us=162153 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 TCPv4_SERVER WRITE [1450] to [AF_INET]MyPublicIPaddress:17401: P_DATA_V2 kid=0 DATA len=1449
[node2] 2026-08-07 08:47:39 us=162193 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 TCPv4_SERVER WRITE [1450] to [AF_INET]MyPublicIPaddress:17401: P_DATA_V2 kid=0 DATA len=1449
[node2] 2026-08-07 08:47:39 us=162207 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 NOTE: --mute triggered...
[node2] 2026-08-07 08:47:39 us=171860 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 236 variation(s) on previous 10 message(s) suppressed by --mute
[node2] 2026-08-07 08:47:39 us=171904 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 MULTI: packet dropped due to output saturation (multi_process_incoming_tun)
[node2] 2026-08-07 08:47:39 us=171911 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 TUN READ [0]
[node2] 2026-08-07 08:47:39 us=171922 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 MULTI: packet dropped due to output saturation (multi_process_incoming_tun)
[node2] 2026-08-07 08:47:39 us=171928 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 TUN READ [0]
[node2] 2026-08-07 08:47:39 us=172343 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 TCPv4_SERVER WRITE [1400] to [AF_INET]MyPublicIPaddress:17401: P_DATA_V2 kid=0 DATA len=1399
[node2] 2026-08-07 08:47:39 us=176732 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 TCPv4_SERVER WRITE [1400] to [AF_INET]MyPublicIPaddress:17401: P_DATA_V2 kid=0 DATA len=1399
[node2] 2026-08-07 08:47:39 us=177074 699dbd258510c5fd4492981c/tcp4-server:MyPublicIPaddress:17401 NOTE: --mute triggered...

I don’t find the “AUTH_FAILED” strings.

Just for info :
[node2][2026-08-07 07:34:12,155][INFO] Authenticating user
user_name = "``myusername@myorg.com``"
factors = ["azure"]
[node2][2026-08-07 07:34:12,165][INFO] Client authentication with sso token
user_name = "``myusername@myorg.com``"
org_name = "Org"
server_name = "Org_srv"
[node2][2026-08-07 07:34:12,166][INFO] Client sso authentication, skipping password
user_name = "``myusername@myorg.com``"
org_name = "Org"
server_name = "Org_srv"
[node1][2026-08-07 08:47:51,261][INFO] Authenticating user
user_name = "``myusername@myorg.com``"
factors = ["azure"]

regards

ebu · October 6, 2026, 9:28am

Hello,

I am sorry, but I could not find any logs showing a failed authentication, either on the client side or on the server side.

When I reboot the node my client is connected to, I can see the disconnection and the client attempting to reconnect. A few seconds later, however, it was disconnected (in a tcpdump I see the establish session to the other node). If I manually click the Connect button, the connection is established successfully.

My understanding was that if one of the two nodes is rebooted, the Pritunl client would automatically fail over and reconnect to the other node. Am I mistaken about this behavior?

Best regards,
Eric

ebu · October 6, 2026, 10:46am

If I attache the openvpn port to strace I see an error during the failed reconnection :

">CLIENT:ENV,daemon_pid=1935\r\n>CLIENT:ENV,daemon_start_time=1791282873\r\n>CLIENT:ENV,daemon_log_redirect=0\r\n>CLIENT:ENV,daemon=0\r\n>CLIENT:ENV,verb=6\r\n>CLIENT:ENV,config=/tmp/pritunl_1248818048da4a0eb6eccbabe3479150/7801a0a7c6894b928ff1f8d8e4300090/openvpn.conf\r\n>CLIENT:ENV,ifconfig_local=IP_address\r\n>CLIENT:ENV,ifconfig_netmask=255.255.0.0\r\n>CLIENT:ENV,script_context=init\r\n>CLIENT:ENV,tun_mtu=1500\r\n>CLIENT:ENV,dev=tun0\r\n>CLIENT:ENV,dev_type=tun\r\n>CLIENT:ENV,redirect_gateway=0\r\n>CLIENT:ENV,END\r\n", 497, MSG_NOSIGNAL, NULL, 0) = 497
epoll_ctl(6, EPOLL_CTL_MOD, 4, {events=EPOLLIN, data={u32=6, u64=6}}) = 0
epoll_ctl(6, EPOLL_CTL_MOD, 7, {events=EPOLLIN, data={u32=4, u64=4}}) = 0
epoll_wait(6, [{events=EPOLLIN, data={u32=4, u64=4}}], 2005, 552) = 1
recvfrom(7, "client-deny 43 1 "Invalid sso token"\n", 256, MSG_NOSIGNAL, NULL, NULL) = 37
newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0644, st_size=114, ...}, 0) = 0
write(1, "2026-10-06 10:38:09 us=134278 MANAGEMENT: CMD 'client-deny 43 1 "Invalid sso token"'\n", 85) = 85
newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0644, st_size=114, ...}, 0) = 0
write(1, "2026-10-06 10:38:09 us=134659 MULTI: connection rejected: Invalid sso token, CLI:[NULL]\n", 88) = 88
epoll_ctl(6, EPOLL_CTL_MOD, 4, {events=EPOLLIN, data={u32=6, u64=6}}) = 0
epoll_ctl(6, EPOLL_CTL_MOD, 7, {events=EPOLLOUT, data={u32=4, u64=4}}) = 0
epoll_wait(6, [{events=EPOLLOUT, data={u32=4, u64=4}}], 2005, 545) = 1
sendto(7, "SUCCESS: client-deny command succeeded\r\n", 40, MSG_NOSIGNAL, NULL, 0) = 40

ebu · October 6, 2026, 1:24pm

And in the mongodb database, I notice that the pritunl collection have documents with my session (in client collection), but when I reboot the server the document has been removed. So that can explain why during the reconnected process it doesn’t find the session and don’t allowed the reconnexion.

Do you know if you have other customer with HA configuration and EntraID for the SSO ?

zach · October 6, 2026, 3:58pm

Both Pritunl hosts need to connect to one MongoDB replica set. That requires at least 3 replicas for quorum. Verify in /etc/pritunl.conf that both hosts have the same MongoDB database.

ebu · October 7, 2026, 8:09am

Hello Zach, thanks for your reply.
In /etc/pritunl.conf I already have the the mongodb connection strings :
sudo cat /etc/pritunl.conf | grep mongodb
"mongodb_uri": "mongodb://pritunl:password@<nodeip1>:27017,<nodeip2>:27017,<hostname_of_arbiter>:27017/pritunl?authSource=admin&replicaSet=pritunl&w=1",

I check and I can reach all mongodb server from the both node with mongosh :
pritunl [primary] pritunl> rs.status().members.map(m => ({
| name: m.name,
| health: m.health,
| state: m.state,
| stateStr: m.stateStr
| }))
[
{
name: '<nodeip1>:27017',
health: 1,
state: 1,
stateStr: 'PRIMARY'
},
{
name: 'hostname_of_arbiter:27017',
health: 1,
state: 7,
stateStr: 'ARBITER'
},
{
name: '<nodeip2>:27017',
health: 1,
state: 2,
stateStr: 'SECONDARY'
}
]

I try with the a pritunl account in the mongodb connection string or with an admin mongo account in the pritunl config file. But same result when I reboot.

zach · October 7, 2026, 10:08am

I did find an issue in the server where if there is no IPv6 address discovered it’s possible with some multi host configurations it will break the host connection order. Which could cause this error but I was not able to reproduce it. This will be fixed in the next client release. Try unchecking the Accept IPv6 Connections in the top right settings until then.

Also if you are using a network load balancer or anything that load balances the OpenVPN traffic this will not work. Only the Pritunl web server traffic should have a load balancer. The public address in the host settings must be the IP address of that host.

ebu · October 7, 2026, 2:01pm

I am sorry, but the Accept IPv6 is not check for me :

My LoadBalancer is only for the HTTPs web interface with authentication and exclusion of /ku/ and /key/. But I have the same problem without the authentication.

And both node have an public IP address where my VPN client will connect.

I will test the new VPN client when it will be available.

Another strange think. Shutdown node02 and connect the VPN no problème to connect to node01 with SSO Entra ID. But if on Node01 I restart the pritunl service (sudo systemctl restart pritunl), I am disconnected form the pritunl client and it will not automaticly reconnect few secondes later when the service is back online. I need to click on connect and the SSO process with Entra ID will begin.

I request a trial key to check a single node have the same kind of reconnection problem with Entra ID SSO (but I am waiting a reply from contact@pritunl.com).

zach · October 7, 2026, 6:56pm

The same license key can be used for multiple installs.

ebu · October 9, 2026, 1:26pm

Hello Zack,

Just for information, I install a signe node pritunl server and configure Entra ID auth.

When the Pritunl client is connected, and I restart the server in the WebUI, I have the same error message :
Connection timed out on Server_name (e-mail) / Failed to authenticate to Server_name (e-mail)

Do you know if you have other customer who use a Azure / Entra ID for SSO and for whom the automatic reconnection is working?

Best regards

zach · October 9, 2026, 7:16pm

Actually the issue is you have Pritunl Authentication Cache disabled in the settings. That will prevent automatic connection. It needs to cache the single sign-on authentication to automatically reconnect.

ebu · October 12, 2026, 8:05am

Hello Zach,
Thank you for your reply. Indeed, I hadn’t enabled the authentication cache on our cluster. However, after enabling it, I still get the error. And I just checked on the single node I created last week, and there the tests were performed with the box checked. So the problem doesn’t seem to be there.

Do you know whether automatic reconnection with Azure SSO works with other customers?

zach · October 13, 2026, 6:41am

I’m not aware of any issues with automatic reconnection. I tested both OpenVPN and WireGuard with Azure single sign-on and could not reproduce any issues.