[BUG] Google SSO broken - auth.pritunl.com callback flow fails with RST on session 3

Pritunl Pritunl VPN
1

Environment

  • Pritunl version: 1.32.4567.52 (jammy build, pinned)
  • OS: Ubuntu 22.04.5 LTS (3 hosts)
  • MongoDB: Atlas M10, version 8.0.23, cluster mono-region France Central
  • SSO mode: Google
  • Hosts: 3 Azure VMs across France Central, East US, Canada Central
  • Embedded Python in Pritunl: 3.9.25

Problem

Google SSO is completely broken since 2026-05-27. Users attempting VPN authentication via Google SSO get a browser timeout at https://auth.pritunl.com/callback/google. The OAuth flow reaches Google successfully (authorization code is issued), but the callback flow never completes.

Diagnostic

What works

  • Pritunl service is running normally on all 3 hosts
  • MongoDB Atlas connectivity is healthy
  • Google Workspace Directory API sync works (org_names/groups are fetched successfully in logs)
  • Admin UI is accessible
  • Existing VPN profiles (certificate-based) connect when SSO is disabled
  • Outbound connectivity from Pritunl server to auth.pritunl.com:443 is confirmed working

What fails

  • Any new Google SSO authentication via the Pritunl client or web console
  • The browser hangs indefinitely at https://auth.pritunl.com/callback/google?state=...&code=...
  • sudo pritunl set user.skip_remote_sso_check true has no effect (issue is at initial auth, not connection check)

tcpdump analysis (captured on OPS-VPN-FR-01 during a failed SSO attempt)

Filter: tcpdump -n -i eth0 host 129.213.65.110 (auth.pritunl.com)

Four outbound sessions observed from the Pritunl server (10.0.0.5) to auth.pritunl.com (129.213.65.110:443). No inbound connection from auth.pritunl.com was observed at any point.

Session 1 (00:25:11) - State token registration

Session 2 (00:31:00) - First poll after Google auth

Session 3 (00:31:14) — FAILURE POINT

  • FR-01 → auth.pritunl.com: 173 bytes sent
  • auth.pritunl.com → FR-01: 612 bytes, then 31 bytes
  • FR-01 sends RST — connection abruptly reset by the Pritunl server
  • auth.pritunl.com sends FIN after the RST
  • Duration: ~300ms
  • This is the exact point where the SSO flow breaks. auth.pritunl.com returns an unexpected response (643 bytes total, including a 31-byte trailing payload), and the Pritunl server’s Python 3.9 handler aborts the connection with RST instead of processing it.

Session 4 (00:31:16) - Retry after RST

Hypothesis

The RST in session 3 suggests that auth.pritunl.com has changed the format or content of its error/response payload for the SSO callback, and the Pritunl server-side Python 3.9 handler (specifically the sso_callback_get or related polling function in handlers/sso.py) is unable to parse this response and resets the connection. The browser never receives the final redirect and times out.

This is consistent with a recent change on the auth.pritunl.com infrastructure that introduced a response format incompatible with the Python 3.9 client code in Pritunl 1.32.4567.52.

Note: we tested the Noble build (1.32.4567.52-0ubuntu1~noble) on a fresh Ubuntu 24.04 VM and confirmed it also embeds Python 3.9.25. The issue reproduces identically on Noble.

Pritunl logs during the failed attempt

No error is logged in journalctl -u pritunl during the failed SSO attempt. The connection reset happens at the TCP layer before any application-level error is produced. This is consistent with an unhandled exception or a parse failure that does not reach Pritunl’s logging layer.

Steps already taken

  • sudo pritunl set user.skip_remote_sso_check true — no effect
  • Verified NSG rules: port 443 inbound is open to * on all 3 hosts — not a firewall issue
  • Verified auth.pritunl.com is reachable (TLS handshake succeeds, outbound calls complete normally in sessions 1, 2, 4)
  • Tested on Noble build 1.32.4567.52 — reproduces identically
  • Checked forum for known incidents — none found matching this symptom
  • Current mitigation: SSO disabled in Pritunl settings, users connecting with certificate/PIN

Request

  1. Can you confirm whether a change was deployed to auth.pritunl.com recently that modified the response format for the SSO callback polling endpoint?
  2. Is there a known fix or updated build that addresses this RST behavior in the Google SSO handler?
  3. If the issue is on the auth.pritunl.com side, what is the expected timeline for a fix?
2

The sessions listed don’t describe how that process works, there is no polling. There’s been no recent changes to the authentication server and no other reports of issues with Google single sign-on. This may be an issue with IPv6, the domain will resolve to both IPv4 and IPv6. Run curl https://app4.pritunl.com/ip and curl https://app6.pritunl.com/ip to verify both IPv4 and IPv6 is working. If IPv6 is not working make sure it is fully disabled and there are no IPv6 DNS servers configured. This often happens when IPv6 is enabled on a VPC but a IPv6 gateway is never added to the routing table.

If you are seeing a stalled single sign-on connection request that can occur when the event system in the database is broken. Run sudo pritunl clear-message-cache.

Otherwise the issue is likely occurring on the client, it’s mostly the client that is interacting with the authentication requests. Open the Chrome developer tools and enable preserve log in the network tab.