Skip to content

SupiVPN v0.9.0

Choose a tag to compare

View all tags
@github-actions github-actions released this 28 Oct 21:12
Immutable release. Only release title and notes can be modified.
v0.9.0
615c2a4
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

SupiVPN v0.9.0

Changes

  • Keep UDP as the default and add optional TCP/443 fallback in one account-bound profile. TCP is disabled unless explicitly configured. Existing bound UDP-only profiles continue to work.
  • Share each node's address pool across UDP and TCP without reserving half for either transport. One SupiVPN agent, node identity, generation and controller lease manage two unmodified upstream OpenVPN processes. Each transport uses a separate private management socket and TUN interface.
  • Generate the optional TCP listener, systemd integration, host routes and firewall settings through Debian setup. Route hooks select the correct TUN for each admitted address without granting additional network capabilities to the agent. Losing either management channel stops the shared node before generation replacement.
  • Handle a connection-limit conflict when an established UDP tunnel loses traffic and TCP reaches authentication before the old slot closes. One eligible same-profile, same-owner attempt receives a committed denial, waits 60 seconds in the agent, then requests a fresh client retry. The retry repeats profile, SAML, group, expiry and cluster-limit checks; it never evicts another tunnel, reserves an extra slot or allocates an IP while waiting. Its budget persists across controllers and nodes.
  • Require profile ownership on every supported listener. Remove legacy unbound admission and document migration, coordinated upgrades and HA requirements.

Compatibility

Breaking change for unbound profiles: v0.9.0 ends their support earlier than the previously announced 0.8.x/0.9.x transition. v0.8.x is now the last compatible series. Migrate all unbound users while still on v0.8.x before upgrading. This is an explicit scope change, not a newly classified Critical vulnerability exception.

Missing agent profile_binding and controller profile.binding settings now select required; explicit legacy settings fail startup. The legacy metadata gate and embedded controller deployment are no longer supported. Use the separate PostgreSQL-backed controller and the required metadata gate on every OpenVPN listener.

Existing bound UDP-only profiles remain valid. Preserve their UDP endpoint and port, CA, exact server-name verification, wrapping key and inline profile credential. They do not need new secrets or keys. To gain the TCP entry, download a newly issued profile after TCP is enabled. Unknown formats, missing or incorrect proofs, blocked profiles, owner mismatches and infrastructure failures never select a weaker authentication path.

Schema 12 remains current. Installations already on v0.8.1 or later need no database migration for this release. Schema compatibility does not imply arbitrary mixed agent/controller versions: upgrade server components together in a maintenance window. Mixed v0.8/v0.9 server deployments have not been validated as a rolling-upgrade path.

Upgrade and enable TCP

  1. Back up the database and operator configuration. On v0.8.x, issue and verify bound profiles for every user; stop and disable the former unbound listener. Keep the existing bound UDP port when consolidating the node.
  2. Update the controller and agent together. For Lambda deployments, update both controller Lambdas and the VPN-host agent; changing Lambda alone does not update host admission, routing or listeners. Retain the existing node identity, generation state, group pools, TLS material, wrapping key and restricted database grants. Packages do not automatically restart working services.
  3. Keep TCP disabled unless needed. For a fresh Debian deployment, set "tcp_fallback": {"enabled": true, "port": 443} in the setup input and review the plan. Do not rerun first-time setup over a working installation.
  4. For an existing deployment, follow the transport guide to add the TCP management socket, second OpenVPN configuration, shared-pool route hooks on both transports, routing and firewall policy. Set the public controller's profile.tcp_fallback_port only after preparing the host listener. TCP/443 must be free; this is OpenVPN over TCP, not an HTTPS endpoint that can share a web-server listener.
  5. Restart in the maintenance window and verify readiness, UDP-only reconnect, TCP fallback, owner/blocked-profile rejection and session limits before distributing new profiles. HA deployments require both transports on each participating node and corresponding load-balancer health checks; pool ranges must still be distinct between nodes.

Configuration and migration details:

Recovery behavior and validation limits

Initial endpoint polling waits three seconds before trying another transport; DNS, scheduling and TLS add time. It does not shorten the browser authentication window. Silent loss of an already established UDP tunnel is different: with packaged keepalive timers, allow roughly two minutes plus fresh browser/network time for recovery. Fallback creates a new tunnel, may change its IP and does not preserve application connections. Clients that do not handle temporary authentication refusals need a manual reconnect after confirmed closure. TCP-over-TCP can perform poorly under packet loss.

The shared pool belongs to one node; it does not transfer tunnels or addresses between HA nodes. Blocking a profile prevents new admission, rather than continuously terminating an already admitted tunnel. Keep browser login confirmation enabled unless accepting its documented relay risk.

Local validation passed Go/race, PostgreSQL integration, native Community OpenVPN, OpenVPN 3 Linux, HA admission/refusal cases, vet and repository audit, plus Debian and Lambda builds for arm64 and amd64. Debian 13 checks on both architectures covered fresh TCP setup, disable/re-enable, old bound UDP-only profiles, established UDP loss, simultaneous UDP/TCP controller/database outages, cancellation, rekey, lease/session expiry, cold boot and package lifecycle.

Initial VM runs failed; corrected test phases passed separately on the same disposable VMs with unchanged runtime packages. This is not one uninterrupted full VM run. Native OpenVPN Connect TCP tunnels, live AWS/load-balancer HA and mixed v0.8/v0.9 server upgrades remain unverified. Local synthetic-SAML checks do not establish a production HA recovery time.

The merged release commit 615c2a4dbf6619e6306a83fe60ebb316a9814f35 passed Checks, CodeQL, automatic Real Okta and the separate pre-release Real Okta run. The Okta acceptance summaries confirm plaintext/encrypted policy, wrong-recipient-key and group denial, six browser profile downloads, one-use/cookie protections and cleanup. These checks exercise SAML and profile issuance, not a native Connect TCP tunnel or a live AWS deployment.

Packages

Commit: 615c2a4dbf6619e6306a83fe60ebb316a9814f35. License: AGPL-3.0-only.

Verified native ARM64 and AMD64 builds from Checks for this signed tag. Both bundles use format 3.

Debian 13 packages for ARM64 and AMD64, a shared metapackage and native Debian source are included. Install verified matching packages with apt install ./supivpn*.deb; see DEPLOYMENT.md.

GitHub build provenance was verified for all binary archives, Debian assets and Corresponding Source, including the tag commit and Checks run attempt 1.

Database schema: 12; compatible VM schemas: 7, 8, 9, 10, 11, 12.
Isolated Lambda required schema: 12.

Corresponding Source accompanies the binaries. Verify SHA256SUMS.asc with the pinned SupiVPN release key, then verify the downloaded files against SHA256SUMS before use.

Assets 18
Loading