OpenVPN Access Server vs Community: What Actually Migrates

Profiles move; user lists stay behind. A team switching between Access Server and Community Edition meets that gap an hour into the cutover, when its first client authenticates and then has no group policy, no per-user route and no self-service password reset. Both products speak the same protocol and accept the same client, which is exactly why the gap stays invisible during planning. What you are actually choosing is the management layer and the people who own it.

Treat the decision as an inventory question rather than a feature grid. Ask who creates users, who revokes certificates, and who answers the page at 02:00.

Why the .ovpn File Does Not Carry the Setup

An .ovpn profile describes one client's relationship with one server: the remote host, the protocol, the CA, a client certificate and key, and any inline tls-crypt material. Drop that file into a fresh build and the client still completes a handshake, so the migration looks finished. Nothing in it lists the users, their groups, their static routes, or the policy that decided who was allowed to connect at all. Those records live in the server's own storage, and the two products store them in different shapes.

In Community Edition the equivalents are files you keep: client-config-dir entries holding per-client options such as ifconfig-push and iroute, a CRL for revocations, and the tls-crypt key. Access Server keeps the same concepts in its own database and exposes them through a web console and the sacli command-line tool. The concepts map one to one; the artifacts do not move at all.

Profiles also smuggle in behaviour that nobody notices until it changes. A client with redirect-gateway def1 sends all browsing through the server; move it to a build without that line and the complaint is that the internet broke. A CA mismatch or a wrong remote-cert-tls setting fails loudly, which is the good outcome. A missing tls-crypt key fails as a silent timeout, which is not.

What the Management Layer Owns

Count what is not protocol: account creation, password reset, group assignment, MFA enrolment, connection entitlements, and the audit trail that answers who connected when. Community Edition supplies none of those directly. You choose an authentication backend, wire PAM, LDAP or RADIUS in through a plugin or auth-user-pass-verify, and maintain the rest yourself. Access Server ships a user portal, an administration console and integrations for common identity providers. Neither arrangement is safer by default, because the policy still has to be written by someone who knows the network.

Entitlements are the sharpest operational difference. Access Server is licensed by a count of concurrent connections and enforces that count in software. On Community Edition, a global cap is a single max-clients line, while anything per user or per group means more client-config-dir work and your own enforcement. A team with no appetite for that maintenance is buying exactly that when it pays for the commercial product.

Licensing and Support: The Line Item Nobody Budgets

Community Edition is free and open source. Access Server is commercial, and its free tier has historically covered a small number of concurrent connections with a paid licence above that. Any figure quoted in an old forum answer is stale by now, so check the vendor's current terms before you cost the project. The honest comparison adds the hours spent building user management, MFA and monitoring on the community side to the licence line on the commercial side.

Support ownership follows the same split. With Community Edition you are the escalation path for every odd client and every kernel update. With Access Server you have a vendor to call, and you inherit its release cadence whether or not it suits your change window.

Checks to Run Before the Cutover

Inventory what the running server actually holds before either direction of switch. On the Access Server side, export the user list and group assignments and note which accounts rely on MFA. On the Community Edition side, list the issued certificates, the CRL and every file under client-config-dir. Compare the two lists line by line, because the difference between them is the migration work.

Test representative clients while the old service is still running. openvpn --config client.ovpn --verb 4 in the foreground prints the handshake, the pushed routes and the DNS options, and openssl x509 -in client.crt -noout -subject -enddate shows which certificate the client really presents. A client that connects but cannot reach an internal host has a route or iroute gap, not an authentication failure.

Keep the old recovery path alive until the replacement passes a denied-access test as well as a successful one. Write the final map as a single page: each requirement, the artifact that satisfies it today, and the artifact that will satisfy it afterwards.