Access Server to Community OpenVPN: What Must Be Rebuilt

Access Server and Community OpenVPN speak the same protocol and almost nothing else the same way. The handshake, cipher negotiation and tunnel data plane are compatible, so a client can often connect to either without editing its profile. What differs is who owns the configuration: one product ships a management layer that writes and enforces policy, while the other hands you a config file and a set of hooks and expects you to decide.

That distinction is the migration plan. Anything the old product decided on your behalf has to become an explicit decision somewhere in the new deployment.

Where the two deployments stop being interchangeable

In Access Server, the web administration interface owns users, groups, per-user permissions, certificate issuance and the profile bundle a person downloads. The daemon underneath is configured by that layer, so the running service is the product of stored state you rarely edit by hand. In Community OpenVPN, the config file is the state: it names the listener, the certificate authority, the authentication hook and every pushed option, and nothing rewrites it for you. The same TLS machinery therefore sits under two very different ownership models.

A short mapping makes the gap concrete. Users and groups exist only in the old database until you recreate them. Profile bundles become a config file plus certificates you distribute yourself. Per-user permissions become directives in client-config-dir. The admin interface becomes whatever process you choose for issuing certificates and editing files.

Write that mapping down before touching a server. Every row you cannot fill is a feature you are about to drop, and dropping one silently is how a migration becomes an outage two weeks later.

Identity does not transfer with the certificate files

Certificates from the old authority may parse correctly in the new service and still be the wrong identity, because the old product paired them with account state the new one cannot see. Decide first whether the new deployment authenticates by certificate alone, by a plugin that reaches PAM or RADIUS, or by some combination, then check that each option preserves the properties you need. A shared certificate with no per-user identity is one credential for everyone who holds it. Revocation has to work from day one as well, which in Community OpenVPN means a CRL file referenced by crl-verify plus a process that regenerates it.

Plan enrolment before cutover rather than after. New certificates, a tested revocation path and a documented way to disable one person are prerequisites, not follow-up work. If multifactor authentication came from the old product's integration, name the replacement explicitly, because a plugin that is not installed fails closed at the worst possible moment.

Routing and name resolution follow the config writer

Routes, DNS settings and full-tunnel behaviour are pushed options in both products, but only one of them computes them for you. In Community OpenVPN you write the push directives yourself, decide whether redirect-gateway belongs on the server or the client, and confirm that forwarding and NAT exist on the host. A finished handshake tells you nothing about forwarding, address translation or the routes a client actually received.

Per-client behaviour needs client-config-dir plus a file named for the client's certificate common name, and a site-to-site peer needs iroute entries for the prefixes behind it. Get the naming wrong and the options are ignored without an error. Test with one non-production client in its own address pool, then read the address it was assigned, the routes it was given and the resolver settings it ended up with.

Sequence the cutover so the old service can return

Run the new listener on a different port or address, and keep the old one serving traffic while you prove the replacement. Two daemons on one socket is not a rollback plan.

Move one group at a time, with its own certificates, its own pool and its own routes, and rehearse the return path rather than discovering it during an incident. Rollback that only works if the new service is stopped first is still rollback, but it has to be tested while nothing is on fire.

Finally, list the features with no direct equivalent and decide each one's fate in writing: self-service profile download, per-user permission flags, the administrative interface itself, live connection reporting. Replacing them with a documented manual process is a legitimate answer. Leaving the row blank is not.

The work is done when a user who never saw the old portal can enrol, connect, reach the intended internal address and be revoked cleanly. Everything before that point is preparation.