Server-locked profile fails behind a TLS proxy: which generation?

One user can connect and another cannot, through the same portal, on the same day. Both have server-locked profiles, both are on the same Access Server build, and the only difference is when their profile was generated. That is the pattern worth recognising, because "server-locked" names a policy rather than a connection sequence. Access Server has shipped two generations of that artifact, and a TLS reverse proxy sits in front of only one of their paths. Three conditions decide which branch you are on.

Two generations, two connection sequences

In the older design, current through 2.8, the imported file is a pseudo-profile. OpenVPN Connect uses it to authenticate against the Access Server web API over HTTPS, receives a temporary user-locked profile and a session token, and only then establishes the VPN. Two transports run in sequence, and the first one is an ordinary web request.

The format introduced with 2.9 does not perform that per-connection bootstrap. It is a native profile usable by compatible OpenVPN clients, not only by OpenVPN Connect. Downloading it or importing it by URL can still involve HTTPS — that is a publication step, not a per-connection fetch of a temporary profile.

An upgrade does not necessarily rewrite profiles that were already issued, so a current server version can still be handing out the old artifact. The server build tells you what is possible, not what this user imported.

Three conditions that pick your branch

The first condition is the artifact's generation. Ask for the file, look at how it was produced, and note the client version that imported it. If you cannot establish the generation from the file, a fresh profile issued for a test account will tell you what the server produces today, which is different information from what the failing user holds.

The second is what your front end actually terminates. A layer-seven HTTP reverse proxy that offloads TLS is not the same object as a layer-four TCP forwarder, and neither is a UDP forwarder. Access Server's usual arrangement on port 443 has the OpenVPN TCP daemon recognising browser traffic and handing it to the web services, so inserting an unrelated HTTPS terminator in front does not preserve that daemon's protocol handling. Sharing the number 443 does not make two designs equivalent.

The third is where the failure lands. A pre-VPN failure and a control-channel failure look similar in a client that only says "connecting", but they leave evidence in different places. If the old format is in play, the bootstrap is a candidate. If the new format is in play, an empty web access log is expected and proves nothing either way.

When the artifact is old: the bootstrap fails first

Read the client's actual error rather than its final state. The interesting fields are the HTTPS error, the server identity the client expected, the destination the request went to, and whether certificate validation completed. Then match those against the web service and proxy logs on the server side.

A browser reaching the login page is not evidence that this client's API authentication succeeded. They are different requests, with different certificate expectations and often different hostnames. If the portal is served correctly and the client still fails, the disagreement is in the bootstrap path, not in the user's password.

Do not make the comparison pass by disabling TLS verification or loosening authentication policy. That converts a diagnosable configuration mismatch into a working-but-unverified path, and it is exactly the change that turns a temporary test into a permanent hole. The Access Server connection-profile documentation describes both generations and the temporary-profile flow, and it is the reference to check before assuming a proxy is at fault.

When the artifact is new: read the control channel instead

With a 2.9-style profile, the client goes straight to the native VPN endpoint. Investigate the endpoints in the profile, the transport in use, and the control-channel error. If the client never issues an HTTP request, that is consistent with the design and not a symptom.

This is also where the proxy question changes shape. An HTTPS offload cannot break a TCP-only stream it never sees, but it can still break the download that publishes the profile, and a TCP-only forwarder will not carry UDP at all. Check which transport the profile asks for before concluding that the front end is irrelevant.

TLS passthrough for a single stream is a narrow arrangement. It does not provide UDP forwarding, and it does not reproduce the daemon's own service-forwarding behaviour on 443. If your front end does one of those things, say which, because the remedy differs.

Remedies that stay narrow

The least disruptive check is to generate a fresh supported profile for a test account and connect through the intended native endpoint with the same authentication requirements. If that works and the retained old profile does not, you have separated the artifact from the server and from the proxy in one step.

Distributing a user-locked profile removes the legacy bootstrap dependency entirely, because there is no temporary-profile exchange to fail. It must be issued for the intended user, never copied from an administrator, and it changes what the client is authorised to do, so treat it as a policy decision rather than a workaround.

Then fix the publication layout so that each required path exists: the web path for downloads and portal use, and the native VPN path on the transport the profiles expect. Keep the proxy's job to one layer. A working user-locked tunnel proves that path works; it does not prove every proxy arrangement supports every generation, and an old bootstrap failure does not condemn the newer format.

• Identify the artifact generation before touching the proxy.
• Establish whether the failure happens before the tunnel or inside it.
• Confirm what the front end terminates: HTTP, TCP stream, or UDP.
• Test a newly issued profile against the native endpoint with policy unchanged.