Can a Post-Quantum VPN Fall Back to Classical Key Exchange?

Preference and enforcement are different

A mixed list can allow a classical group when the hybrid group is unavailable. Placing a hybrid group first expresses a preference; it does not remove the other allowed choices. A connection indicator may therefore be insufficient to establish post-quantum key agreement.

A hybrid-only list permits no classical alternative within that group policy. Compatibility errors become visible connection failures. This is a deliberate availability tradeoff, so software and profiles need to support the same construction.

The release policy

The ALightVPN OpenVPN configuration generator writes the following policy when its group setting has not been overridden:

tls-version-min 1.3
tls-groups SecP384r1MLKEM1024

This is a release-configuration excerpt, not a complete profile or a live-server report. Deployment overrides, another profile, or another executable may change the effective behavior. Retain certificate checks and other profile settings; do not copy these two lines as a replacement for a complete supported configuration.

Changing a data-channel cipher does not establish or enforce the TLS key-agreement group. Diagnose the failing layer before editing settings.

How to test a fallback policy

Administrators should run policy tests in a controlled environment, using disposable test credentials and an approved server configuration:

1. Connect a supported client and record its selected group and completed handshake.
2. Try a client constrained to classical groups against the hybrid-only server. Confirm negotiation fails because no permitted group is shared; an unrelated network or authentication failure is not the same test.
3. If a migration environment intentionally allows a mixed list, record which group each client actually selects. Report classical sessions separately.
4. Repeat after deployment changes, dependency updates and configuration overrides.

No completed production fallback test report is included here. These steps describe how to collect evidence; they do not claim a test has passed for every server.

What to do when a client cannot connect

Check its package, loaded library and available groups first. Then review the issued profile and certificate errors with support. Avoid adding classical groups simply to obtain a green connection status; that changes the intended policy.

Follow the compatibility checklist and verify the next successful session. Treat any reported classical negotiation as a configuration question requiring investigation.

Common questions

Is the first group in a list guaranteed to be selected?

No. The effective policies and peer capabilities determine negotiation. Inspect the selected group for the successful session.

Is failure to connect proof that fallback is blocked?

Not alone. A test must establish that the cause was the lack of a shared permitted group, rather than authentication or network failure.

Should I remove certificate checks to troubleshoot group support?

No. Authentication and group support are separate checks. Keep identity validation enabled and use the supported diagnostic procedure.