SSO Authentication Fails in v1.32.4349.59 - Client Not Adding * Marker to ALB Endpoint in data_remotes

Pritunl Pritunl VPN
,
1

Issue Summary:

SSO authentication via Okta works in Pritunl server version 1.32.4278.46 (Beta environment) but fails in version 1.32.4349.59 (Production environment). The client successfully initiates SSO authentication and receives Okta redirect, but fails to complete the VPN connection due to incorrect endpoint selection for authentication API calls.

Environment Details:

  • Working Environment (Beta): Pritunl Server v1.32.4278.46

  • Failing Environment (Production): Pritunl Server v1.32.4349.59

  • Client Version: Latest macOS client

  • Authentication: Okta SAML SSO

  • Infrastructure: AWS ALB (HTTPS) + NLB (UDP) setup

Root Cause Analysis:

The issue stems from a behavioral change in Pritunl client logic between server versions 4278.46 and 4349.59. In the working version, the client automatically adds a * marker to the ALB endpoint in data_remotes for authentication API calls. In version 4349.59, this behavior has changed, causing the client to use the NLB endpoint for authentication API calls, which fails.

Client Log Analysis:

Working Beta-Devin Logs:

data_remotes=string{“pritunl-alb-2027382609.us-east-1.elb.amazonaws.com*”, “pritunl-prod-nlb-aiagents-031f42d15fcfd3b3.elb.us-east-1.amazonaws.com”}
:white_check_mark: ALB has * marker - authentication succeeds

Failing Production Logs:
data_remotes=string{“pritunl-prod-vpn-webui.prod.vpn.toasttab.com”, “pritunl-prod-vpn-19679-nlb-5158ca234a16ba5c.elb.us-east-1.amazonaws.com”}

:cross_mark: No * marker on either endpoint - authentication fails

Post “https://pritunl-prod-vpn-19679-nlb-5158ca234a16ba5c.elb.us-east-1.amazonaws.com/key/ovpn/…”: context deadline exceeded

:cross_mark: Client tries to use NLB for authentication API call instead of ALB

Infrastructure Setup:

Host Configurations Tested:

  1. All hosts with NLB Public Address + ALB Sync Address (Original)

  2. One host with ALB Public Address + ALB Sync Address, others with NLB (Current)

  3. Priority variations (0, 1, 2 for different hosts)

  4. Empty Sync Address fields (mimicking Beta setup)

Key Observations:

  1. SSO Initiation Works: Client successfully initiates SSO and receives Okta redirect

  2. Authentication Completes: User can authenticate via Okta

  3. API Call Fails: Client makes authentication API call to NLB instead of ALB

  4. Version-Specific Behavior: Issue only occurs in version 4349.59, not 4278.46

Expected vs Actual Behavior:

Expected (v4278.46 behavior):

  • Client adds * marker to ALB endpoint in data_remotes

  • Uses ALB for authentication API calls

  • Uses NLB for VPN tunnel establishment

Actual (v4349.59 behavior):

  • Client does not add * marker to any endpoint

  • Uses NLB for authentication API calls (fails)

  • SSO authentication completes but VPN connection fails

Questions:

  1. Is this a known issue in version 4349.59?

  2. What changed in the client logic for endpoint selection between versions 4278.46 and 4349.59?

  3. How can we force the client to add the * marker to the ALB endpoint in version 4349.59?

  4. Are there any configuration changes needed for the new SSO rate limiting features in 4349.59?

  5. Should we downgrade to version 4278.46 or is there a fix/workaround for 4349.59?

2

System wont allow me to add more than. 6 Hyperlinks, hence I made a purposeful syntax error. The ALB FQDN is: pritunl-prod-vpn-webui.prod.vpn.toasttab.com

3

The * indicates it is a sync remote. These come from the Sync Address field in the advanced host settings. Open the profile settings in the client and check the Configuration Sync Hosts. Then click debugging and check Remotes Data. These are the addresses used for VPN connections. The order that the addresses are attempted will vary based on the configuration but it will show the order in the client service logs.

Network load balancers won’t work with most of the authentication modes. Tokens are created which are scoped only to one host. If the request goes to different hosts it will break. If this was working it may have been random chance that the requests got sent to the correct host. The client will already handle failover and randomly selecting a host.

Below are all the addresses and how to configure them for multi-host configurations.

Hosts Tab

  • Host Public Address: The public IPv4 address or domain of the Pritunl host. This should always be the public IP of the host for all configurations even when using a load balancer.
  • Host Public IPv6 Address: The public IPv6 address or domain of the Pritunl host. This should always be the public IP of the host for all configurations even when using a load balancer.
  • Host Sync Address: In the advanced host settings. The public address or domain that the web server of the Pritunl servers can be accessed from. If a load balancer is configured that address should be set here.

Top Right Settings

  • Connection Single Sign-On Domain: Only shown when using single sign-on connection authentication. The public address or domain that is used to validate single sign-on requests through the Pritunl web server for a new VPN connection. If a load balancer is configured that address should be set here. Requires valid SSL certificate.
4

We have an ALB and an NLB both sitting in front of 3 EC2 instances with the NLB setup to be Sticky. In this Beta setup we have been successful in getting SSO working and the client does show receiving the NLB FQDN in remotes_data and uses that to setup a tunnel. For the production setup, we intend to use 16 different NLB’s (one per Server Profile) front-ending 3 EC2 instances each, totaling 48 EC2 instances. The ALB uses all 48 instances as backend hosts/targets while each NLB uses a triplet of EC2 instances that are dedicated for a specific server profile. The idea here is similar to the Beta where the Client should receive the NLB FQDN in the remote_data and use it for the VPN tunnel setup but I am seeing it use that instead of the Sync-Host address for the Auth API call.

Remotes Data

{“pritunl-prod-nlb-aiagents-031f42d15fcfd3b3.elb.us-east-1.amazonaws.com”:{“priority”:0}}