Microsoft retired the Azure VPN Client for Linux preview package on August 31, 2026. An installed client may still establish a Point-to-Site (P2S) virtual private network (VPN) tunnel, but Microsoft no longer supports the package or provides bug fixes or security patches. A working connection is not an acceptable production dependency. Microsoft’s May 28, 2026 retirement guidance states that the package is being removed from the Microsoft Linux repository. Any organization that missed the deadline should treat every remaining installation as a post-support remediation exception, not as evidence that the risk can be deferred.
The scope is narrow, but the migration is not. Azure VPN Gateway, P2S as a service, the Windows and macOS Azure VPN clients, Site-to-Site (S2S) VPN, and existing gateway configurations were not retired. The affected component is the Microsoft Linux preview client, package microsoft-azurevpnclient, which supplied the documented Microsoft Entra ID authentication path. Microsoft’s replacement guidance directs Linux users to OpenVPN with certificate authentication or strongSwan with Internet Key Exchange version 2 (IKEv2) and certificate or Remote Authentication Dial-In User Service (RADIUS) authentication. Those documented alternatives do not support Microsoft Entra ID authentication with Azure VPN Gateway P2S.
That identity gap is the center of this runbook. The objective is not another binary; it is continuous access with explicit decisions about identity, device, revocation, routing, Domain Name System (DNS) behavior, logging, and support. The runbook provides a fleet inventory, architecture decision, control map, coexistence sequence, endpoint standards, positive and negative tests, decommission evidence, and rollback that never depends on reinstalling the retired package.
Define the Exact Retirement Scope and Immediate Risk
Treat the Azure VPN Client Linux retirement as a supportability and identity-risk event, not as an Azure VPN Gateway outage. Microsoft says the retired component is the Linux preview package named microsoft-azurevpnclient. Its Point-to-Site service overview still lists certificate, Microsoft Entra ID, and RADIUS authentication as gateway capabilities, but client operating system and tunnel combinations determine what a user can actually use. The distinction matters during executive reporting: the platform is available, while one supported Linux access path has ended.
Item | Status after August 31, 2026 | Operational meaning |
Azure VPN Client preview package for Linux | Retired | No Microsoft support, bug fixes, or security patches; prohibit new production installations. |
Existing Linux connections through that package | May still function temporarily | Connectivity is not evidence of supportability; record every remaining user as an exception. |
Azure VPN Gateway and P2S configuration | Not retired | Retain the gateway and redesign the Linux client, tunnel, and authentication path. |
Azure VPN Client on Windows and macOS | Not affected by this retirement | Managed users on those platforms can remain on supported client paths, subject to normal lifecycle checks. |
Site-to-Site VPN and other gateway connections | Not affected | Do not alter unrelated tunnels merely to close the Linux client risk. |
OpenVPN certificate and strongSwan IKEv2 paths | Documented alternatives | They require new authentication and operating controls; they are not Entra-equivalent client swaps. |
Use the ownership boundaries described in Refonte Learning’s cloud architecture foundations as context, then name one migration lead with authority over gateway, identity, endpoint, and support decisions.
Inventory Every Linux User, Device, Profile, Route, and Dependency
A package inventory alone will miss the people most likely to fail during cutover: unmanaged devices, copied profiles, dormant contractors, and users who connect only during incidents. Build the inventory from endpoint management, package telemetry, configuration management, help-desk records, Azure diagnostic logs, identity sign-in evidence, and service-owner interviews. Microsoft’s former Linux Entra client page documented support only for Ubuntu 20.04 and 22.04, but your discovery must include every distribution on which the package or a copied profile may exist.
The inventory should be governed with the same owner-and-evidence discipline discussed in Refonte Learning’s cloud architecture engineering practices: an unknown value is a migration risk, not an empty field.
Required field | What to record | Evidence source |
User and business owner | Named user, manager, employment type, privilege tier, criticality | Identity directory, human resources feed, access review |
Device and distribution | Asset ID, hostname, Linux distribution/version, managed or unmanaged status | Endpoint management, configuration management database (CMDB), local discovery |
Location and network | Normal country/site, home or office use, captive or restricted networks | User interview, client telemetry, support history |
Gateway and profile | Subscription, resource group, gateway, profile name/version, distribution channel | Azure inventory, endpoint file inventory |
Tunnel and authentication | Current tunnel, Entra tenant/application, certificate, or RADIUS dependency | Gateway configuration, profile contents |
Entra dependency | multifactor authentication (MFA), Conditional Access, device compliance, sign-in risk, account-disable workflow, audit use | Policy review, identity logs, control owners |
Routes and DNS | Client address pool, advertised routes, DNS suffixes/servers, split or full tunnel behavior | Gateway configuration, profile, client tests |
Applications | Critical hosts, ports, protocols, private endpoints, on-premises dependencies | Application owner validation |
Last successful connection | Timestamp, assigned Internet Protocol (IP) address, client version, success or failure evidence | Gateway/client logs and support records |
Classify each record into a migration cohort: privileged administration, critical operational access, standard employee access, contractor access, or dormant/unknown. Then add two binary decisions: whether the device is managed and whether Entra supplied a control that the replacement path cannot reproduce. Privileged or contractor access on unmanaged Linux with Conditional Access dependency belongs in the highest-risk cohort even if the user connects infrequently.
Choose the Target Remote-Access Architecture Instead of a Replacement Binary
A credible Azure VPN Linux migration decision starts with identity and control requirements, then chooses the client. Microsoft documents Linux certificate connectivity through OpenVPN and strongSwan, and RADIUS through supported tunnel/authentication combinations. Certificate paths also require an operable private public key infrastructure (PKI), not merely a certificate file. It does not say that either client recreates Entra sign-in, Conditional Access, single sign-on, device posture, or identity logging. Architecture approval must therefore compare complete access paths rather than feature lists for two open-source packages.
Use broader hybrid and multi-cloud decision patterns only to frame placement, dependency, and portability tradeoffs; this decision remains a narrow remote-access control choice.
Target path | Identity and device posture | Operations and support | Cost and dominant failure mode |
OpenVPN on Linux with client certificate | Certificate identifies the issued credential; Entra controls and device posture are absent unless enforced elsewhere. | Documented Linux path; requires PKI, profile distribution, package governance, renewal, and revocation. | PKI and endpoint effort; copied or unrevoked keys. |
strongSwan on Linux with IKEv2 certificate | Same certificate limits; endpoint and PKI controls must bind the credential to a device. | Documented IKEv2 path; verify the gateway service tier (SKU), reachability, client settings, and PKI. | Operational effort; IKEv2 reachability or certificate failure. |
strongSwan with RADIUS | Centralizes user authentication but does not recreate Entra Conditional Access. | Requires RADIUS high availability, network paths, shared secrets, latency, and policy testing. | Added infrastructure; authentication outage or weak secret handling. |
Managed Windows or macOS Azure VPN Client | Preserves a supported Entra P2S path when policy permits a platform change. | Requires managed desktop or virtual-desktop capacity, application compatibility, and support. | Desktop or service cost; bottleneck or emergency-access failure. |
Another approved zero-trust access service | May expose identity and device signals; prove every required policy and log. | Requires design or procurement, connectors, logging, support, and an exit plan. | Licensing and integration cost; a rushed new dependency. |
Use OpenVPN or strongSwan Certificates When Private PKI Operations Are Mature
Microsoft’s Linux certificate-client configuration guidance supports OpenVPN and strongSwan paths, but client configuration is only the last step. A certificate architecture is acceptable when a private public key infrastructure (PKI) owner can issue a unique client certificate, protect its private key, renew it before expiry, identify its serial number and thumbprint, revoke it quickly, and prove the revoked credential fails against the gateway.
Stop the certificate path if the organization cannot revoke one user-device credential without disabling every client, if private keys must be emailed or copied through tickets, or if endpoint ownership is unknown. Those conditions convert the migration into a long-lived bearer-credential risk.
Use strongSwan With RADIUS Only When the Added Dependency Is Defensible
RADIUS can preserve centralized user authentication for some environments, especially where an existing service already integrates with the authoritative directory and multifactor authentication. It is still a new dependency in the Linux P2S path. Azure VPN Gateway forwards authentication exchanges to the configured RADIUS server; the design therefore inherits server availability, network reachability, shared-secret security, directory latency, and the selected RADIUS product’s policy and logging behavior.
Use RADIUS only when the added components improve control more than they increase outage and support risk. A newly assembled RADIUS service built solely to meet the retirement deadline is rarely the fastest safe path; it needs the same availability, monitoring, patching, recovery, and ownership discipline as any other authentication tier.
Resolve the Microsoft Entra ID Capability Gap Explicitly
The August 31, 2026 retirement eliminated the documented Azure VPN Client Entra ID path on Linux. Microsoft’s Linux Entra ID client documentation identifies the client as Preview and directs readers to the retirement guidance. The replacement decision must therefore enumerate every Entra behavior relied upon in the existing design and assign it one of four states: preserved, replaced, weakened, or unavailable.
Refonte Learning’s explanation of zero-trust cloud architecture is useful here only when translated into verifiable controls: explicit identity, device state, least privilege, continuous evidence, and assumed compromise.
Current Entra-dependent behavior | Certificate path | RADIUS path | Managed platform or alternative service |
Interactive user identity and single sign-on | Replaced by private-key possession; attribution depends on issuance records. | May preserve centralized credentials; prompts, federation, and claims depend on the design. | Preserved only after end-to-end tenant and client testing. |
Account disablement | Weakened unless offboarding revokes the issued certificate promptly. | May be preserved through directory integration; verify cache and outage behavior. | Preserved only if disablement blocks new sessions within the required time. |
Multifactor authentication and Conditional Access | Unavailable in the documented Azure P2S Linux certificate alternatives. | Replaced by supported RADIUS controls; not Entra Conditional Access parity. | Potentially preserved through a supported Entra path or verified policy engine. |
Managed-device or compliance gate | Replaced by enrollment and endpoint controls; not enforced automatically by the tunnel. | Requires a separate proven device control. | Potentially preserved when authoritative posture blocks noncompliant devices. |
Identity logging and risk investigation | Replaced by certificate, device, gateway, and endpoint correlation. | Replaced by RADIUS, directory, gateway, and endpoint correlation. | Preserved only if logs expose user, device, policy result, session, and resource path. |
Group or role-based authorization | Enforce at firewall, application, or another policy layer. | Use only verified attributes and downstream enforcement. | Potentially preserved when the target consumes and tests group or role claims. |
Decide Whether to Accept Certificate Identity or Move to Another Access Service
Certificate identity can be defensible when the tunnel is only a network transport, applications perform their own strong user authentication, devices are managed, certificates are uniquely issued, and revocation is automated. It is much harder to defend for unmanaged bring-your-own-device access, shared workstations, privileged administration, or workflows that treat the VPN login as the primary user and device control.
Decision question | Certificate path is acceptable when… | Choose another supported path when… |
Where is the user authenticated? | Each critical application independently authenticates and authorizes the user. | The VPN connection is the main identity boundary. |
How is device trust enforced? | Enrollment is limited to managed, encrypted, supported endpoints and copying is controlled. | Unmanaged devices or portable keys are permitted. |
How fast must offboarding act? | The revocation workflow meets the required disablement time and is tested. | Account disablement must block access immediately but certificate revocation is manual or delayed. |
Which identity controls are mandatory? | No connection-time Entra control is required, or a documented compensating control is approved. | MFA, Conditional Access, sign-in risk, or device compliance must be evaluated at connection time. |
Can the organization support a new service? | A separate service would add complexity without materially improving required assurance. | A managed platform or evaluated identity-aware service preserves mandatory controls more safely. |
Build the Certificate or RADIUS Control Plane Before Client Rollout
Client rollout begins only after the authentication control plane is operational. Microsoft’s certificate-authentication gateway guide explains that the gateway stores uploaded root public certificate data and validates client certificates issued beneath those roots. It also recommends a unique certificate per client because individual revocation is then possible. The root private key is not uploaded to Azure and should remain tightly protected.
This separation of trust anchors, issuance, endpoint custody, and monitoring is a concrete application of cloud security architecture, not a certificate-generation task delegated to whoever owns the VPN client package.
Control-plane component | Accountable owner | Minimum production evidence |
Trust anchor and issuing policy | PKI/security owner | Approved hierarchy, protected root key, scoped issuing policy, documented certificate purpose |
Enrollment and device binding | Identity and endpoint owners | Approved user-device request, managed-device check, unique serial/thumbprint inventory |
Gateway trust and revocation | Network/platform owner | Root public certificate configuration, revoked thumbprint process, tested emergency root removal |
Renewal and expiry | PKI plus service owner | Renewal schedule, overlap policy, expiry alerts, renewal test before pilot |
RADIUS service if selected | Identity/platform owner | Two-server design, reachable paths, secret custody, failover and outage tests |
Audit and support | Security operations and service desk | Correlated logs, access review, escalation runbook, offboarding evidence |
Automate Certificate Issuance, Renewal, Revocation, and Offboarding
The Linux VPN certificate lifecycle must be a workflow, not a document. A useful sequence begins with an approved user-device request, verifies that the endpoint is managed and supported, issues one credential, records its serial number and certificate thumbprint, installs it through a protected channel, and confirms the private key is not broadly exportable. Where the exact client stack cannot use hardware-backed storage, apply restrictive ownership and file permissions and document the remaining export risk.
Lifecycle event | Required action | Closure evidence |
Routine renewal | Issue new credential, test, revoke predecessor after overlap | Two serials linked, new success, old denial, inventory updated |
User departure | Revoke all user-device certificates and remove access assignments | Directory event, gateway change, endpoint removal, failed connection test |
Lost or stolen device | Revoke device credential immediately; isolate device through endpoint controls | Incident ticket, thumbprint, denial result, security review |
Private-key exposure suspected | Revoke credential, investigate copies, issue only after device is trusted | Incident timeline, replacement approval, old credential denial |
Issuing certificate authority (CA) compromise | Remove affected root, activate alternate trust path, reissue clean credentials | Gateway diff, emergency access proof, complete affected-certificate inventory |
Do not assume publishing a certificate revocation list elsewhere is enough for Azure P2S. Microsoft’s documented operational mechanism is adding the client certificate thumbprint to the gateway revocation list, while removing a root certificate blocks all child certificates. Build automation around the control Azure actually evaluates, then test its propagation and denial timing.
Engineer RADIUS Availability, Secrets, Accounting, and Failure Behavior
Microsoft’s June 8, 2026 P2S RADIUS configuration guide supports primary and secondary servers, requires a route-based non-Basic gateway, limits IKEv2 with RADIUS to Extensible Authentication Protocol (EAP)-based methods, and requires Site-to-Site reachability when an on-premises RADIUS server is used. Design those prerequisites before changing the gateway.
Failure or control | Required design | Test and evidence |
Primary server unavailable | Secondary server in an independent failure domain; documented selection behavior. | Disable primary; prove bounded failover, correct policy, and alerting. |
Both servers unavailable | Fail closed; keep a separate approved emergency path. | Isolate both; prove denial and measure user-facing failure time. |
Shared-secret compromise or rotation | Approved custody; unique secrets where supported; one-path-at-a-time rotation. | Prove old secret fails and new secret succeeds without log exposure. |
Network latency or loss | Defined timeout budget, monitored paths, and peak capacity. | Inject delay or loss; measure retries, prompts, and gateway behavior. |
Directory or MFA failure | Explicit deny, retry, and emergency policy; no undocumented fail-open. | Simulate outage and retain accept or reject evidence. |
Accounting and correlation | Required attributes, timestamps, session IDs, retention, and privacy controls. | Correlate chosen RADIUS records with gateway and endpoint logs. |
Microsoft documents authentication pass-through, but the selected RADIUS product and policy stack determine many operational details. Do not invent timeout values, attribute availability, or accounting behavior from generic RADIUS knowledge. Measure them end to end, record the result, and block promotion if security operations cannot identify who connected, from which managed device, through which gateway path, and under which policy decision.
Change Gateway Tunnel and Authentication Settings With Coexistence
Azure VPN Gateway can enable multiple tunnel types and, in supported combinations, multiple authentication types. That capability allows controlled coexistence while Linux users move, but it is not permission to leave every path enabled indefinitely. The gateway owner must verify the current SKU, route-based configuration, active-active implications, address pool, client matrix, and available tunnel/authentication options in the live portal or infrastructure code before the change.
Migration state | Gateway/client posture | Entry and exit criteria |
Baseline captured | Current P2S settings, roots, revoked certificates, RADIUS settings, routes, diagnostics, and client profiles exported | Configuration snapshot reviewed; rollback owner and supported fallback identified |
Coexistence enabled | Existing supported Windows/macOS path retained; new Linux certificate or RADIUS path added in a supported combination | Lab client succeeds; existing supported clients still authenticate and reach required applications |
Linux waves migrating | New profiles issued only to approved cohorts; retired Linux client remains a dated exception, not fallback | Each wave meets identity, route, DNS, stability, and support gates |
Legacy exception closed | Retired package and profile removed; obsolete roots/authentication exceptions disabled when safe | Fleet evidence reconciled; no dependent user; decommission proof approved |
Generate, Protect, Distribute, and Rotate Client Profiles
A client profile package is sensitive configuration even when it does not contain a private key. It reveals gateway endpoints, tunnel parameters, certificate authorities, routes, and assumptions an attacker can use. Generate it only after the approved gateway change, assign a version, calculate an integrity hash, store it in a restricted repository, and distribute it through an authenticated endpoint-management or secure delivery channel.
Manifest field | Required value | Why it matters |
Profile ID and version | Stable name plus monotonically increasing version | Support can identify the exact configuration in use. |
Gateway identity | Subscription, resource group, gateway resource ID, environment | Prevents production and test profiles from being confused. |
Tunnel and authentication | OpenVPN/certificate, IKEv2/certificate, or approved RADIUS combination | Makes security semantics visible. |
Generated time and source change | Coordinated Universal Time (UTC) timestamp, change ticket, configuration commit | Establishes provenance and rollback reference. |
Integrity | Secure Hash Algorithm 256 (SHA-256) digest and, where available, package signature | Detects unintended modification or substitution. |
Audience and delivery | User cohort, device group, approved delivery channel | Limits uncontrolled profile reuse. |
Supersedes and retirement date | Prior versions and final removal date | Prevents stale-profile drift. |
Owner and support path | Service owner, escalation queue, known limitations | Makes the profile operable after rollout. |
Rotate a profile whenever gateway endpoints, tunnel types, certificate roots, routes, DNS settings, maximum transmission unit (MTU) assumptions, or authentication settings change. Rotation is complete only when new profiles are installed, old versions are blocked or removed where feasible, support scripts and knowledge articles are updated, and telemetry shows no remaining clients on the superseded version.
Harden Linux Endpoints and Bind Credentials to Managed Devices
Microsoft’s August 11, 2026 VPN Gateway security guidance recommends supported client profiles, certificate protection, least privilege, diagnostic logging, and deliberate use of multiple authentication types. The Linux endpoint is where those principles either become controls or become assumptions.
Endpoint control | Required state before production | Evidence and blocking condition |
Operating system support | Distribution and release are within the organization’s supported lifecycle and receive security updates | Endpoint inventory; block end-of-life or unknown systems |
Disk and boot protection | Approved full-disk encryption and secure boot posture where policy requires it | Management attestation; block missing recovery/escrow controls |
Endpoint detection and response | Healthy agent, current policy, active telemetry | Security console status; block stale or isolated agents |
Package provenance | Client obtained from an approved repository or verified build source; version pinned or governed | Package signature/hash and repository policy; block ad hoc downloads |
Private-key custody | Unique key, restrictive permissions, non-exportable or hardware-backed when the proven client stack supports it | File/keystore inspection; block shared or world-readable keys |
Administrative privilege | Local admin rights limited; VPN files not modifiable by ordinary users beyond approved needs | Privilege inventory and file ownership |
Time synchronization | Reliable time source and acceptable drift | Monitoring result; block if certificate and authentication timing cannot be trusted |
Retired artifacts | Old package repository, package, profiles, services, and scripts scheduled for removal | Compliance query with dated closure |
Validate Routes, DNS, Split Tunneling, MTU, and Application Reachability
Authentication success proves only that a tunnel formed. It does not prove that traffic takes the intended path, that private names resolve, that overlapping home networks are handled, or that large packets and stateful protocols work. Profile formats and route installation differ between clients, so capture the actual route and resolver state on each supported Linux distribution after connection.
Microsoft’s guidance for advertising custom P2S routes confirms that gateway routes can be distributed to remote clients. Use that capability deliberately and verify the client received the intended prefixes. Do not copy every old route without proving it is still required.
Test area | Procedure | Expected evidence and stop condition |
Client address and route table | Record assigned address, interface, route priorities, and source. | Approved pool and routes; no unexpected default or overlap. |
Azure VNet and peered VNets | Reach approved hosts and trace each required path. | Intended prefixes succeed; segmentation still denies prohibited networks. |
On-premises and hybrid routes | Test each required application across the transit path. | Symmetric return path and expected source; stop on black holes or asymmetry. |
DNS suffixes and private zones | Resolve short and fully qualified names; record resolver, answer, and latency. | Correct private answer; stop on public leakage or inconsistent suffix behavior. |
Split versus full tunnel | Compare private and internet destinations before and after connection. | Traffic follows approved policy; no assumed gateway egress. |
Overlapping local networks | Test common home, hotel, and office ranges. | Critical Azure prefixes win; unavoidable conflicts are documented. |
Maximum transmission unit | Exercise large payloads and Path MTU Discovery. | No fragmentation black hole, stall, or protocol-specific failure. |
Internet Protocol version 4 (IPv4) and version 6 (IPv6) | Test only the address families the design claims. | Supported traffic works; unsupported traffic cannot bypass policy. |
Proxy, captive network, and firewall | Connect from restricted networks in pilot scope. | Predictable success or documented denial with supported fallback. |
Critical application protocols | Run owner-approved administrative, database, application programming interface (API), and file transactions. | Functional and authorization evidence, not only ping or open ports. |
Also review the gateway virtual network’s resolver design. Microsoft’s VPN Gateway DNS guidance in the official frequently asked questions (FAQ) warns that custom DNS and private-zone configurations can interfere with gateway control-plane name resolution unless Azure DNS forwarding is handled correctly. That is separate from client DNS, and both layers require evidence.
Pilot Both Paths and Prove Security Parity Where It Exists
Pilot the target architecture in rings that expose operational risk before business-critical users depend on it. Include at least one user from each supported distribution, geographic/network condition, privilege tier, and application pattern. When two target paths remain under consideration—such as OpenVPN certificates and strongSwan with RADIUS—run the same test script against both so the decision is based on controls and failure behavior, not initial connection speed.
Pilot ring | Participants and objective | Exit evidence |
Lab | Network, identity, endpoint, PKI/RADIUS, and security engineers; prove configuration and observability | Positive and negative tests, configuration snapshot, known limitations, supported rollback |
Internal operations | Service desk, site reliability engineering (SRE), platform, and security staff on representative managed Linux devices | Install success, reconnect behavior, support runbook, identity correlation, no critical route/DNS defect |
Noncritical business users | Small cohort with ordinary application paths and varied networks | User-experience baseline, application owner approval, stable connection and support metrics |
Privileged or critical users | Administrators and service owners only after earlier rings pass | Stronger control review, break-glass test, revocation timing, executive risk disposition |
Broad deployment | Remaining approved users by cohort | Automated compliance, low exception count, decommission readiness |
Security parity exists only for controls that produce equivalent decisions and records. Certificate issuance tied to a compliant device may replace one device gate, but it does not reproduce continuous Conditional Access evaluation. RADIUS may preserve centralized account disablement, but it does not become Entra sign-in risk protection by association. Label each control honestly, update the decision record, and require the control owner to approve any weakened state.
Run Negative Tests for Revoked Users, Lost Devices, and Stale Profiles
Negative tests reveal the gaps hidden by a successful tunnel. Run them in an isolated pilot environment or controlled window with named observers and a preapproved recovery path. Record the expected denial, the actual result, the time until enforcement, and every log source used to explain the decision.
Negative test | Expected secure result | Failure meaning and response |
Disable Entra account while a certificate remains valid | Certificate access may continue until revocation; this must match the approved design. | If stakeholders expected immediate denial, stop and redesign offboarding. |
Revoke a client certificate thumbprint | New connection is denied within the measured target. | Verify thumbprint, propagation, and credential selection before rollout. |
Use an expired certificate | Authentication fails with diagnosable evidence. | Block renewal rollout if another unintended credential is selected. |
Copy a profile without its private key | The profile alone cannot authenticate. | Replace packaging if credentials are embedded or broadly accessible. |
Copy an exportable key to an unapproved device | Controls block or detect use, or the residual risk is explicitly accepted and rapidly revocable. | Successful uncontrolled use is a device-binding failure. |
Use a superseded profile | It is rejected, removed, or clearly identified and cannot use changed routes. | Accelerate withdrawal and version enforcement. |
Fail the primary RADIUS server | Secondary authentication meets the approved experience and alerts. | Stop on unbounded retries or inconsistent policy. |
Fail both RADIUS servers or the directory | Access fails closed; the separate emergency path remains audited. | Any undocumented fail-open behavior is critical. |
Report a device lost | Service desk revokes, isolates, and proves denial without user help. | Escalate incomplete asset-to-certificate mapping. |
Monitor Authentication, Tunnel Health, User Experience, and Support Load
Microsoft’s Azure VPN Gateway monitoring guidance distinguishes automatically collected platform metrics from resource logs that require diagnostic settings. Enable and validate diagnostics before migration waves so failures have a baseline and a destination. Protect the log workspace because authentication, route, address, and topology data can be sensitive.
Signal | Use during migration | Owner and action |
P2S connection count and gateway bandwidth | Detect wave adoption, sudden drops, saturation, or unexpected concurrent use | Network operations compare with cohort schedule and investigate deviations |
User VPN route count and configuration activity | Detect route/configuration changes that can invalidate profiles or reachability assumptions | Platform owner correlates every change to an approved ticket |
P2S diagnostic events | Trace IKEv2/OpenVPN connection attempts and failures | Security/network teams correlate timestamp, client, protocol, assigned IP, and credential evidence |
RADIUS accept/reject, latency, and server health | Identify directory, MFA, shared-secret, or failover problems | Identity team alerts on error ratio, latency change, and server unavailability |
Client logs and endpoint posture | Diagnose package, certificate, route, DNS, time, and local-policy faults | Endpoint team collects only approved fields and redacts secrets |
Application transaction checks | Prove the tunnel still reaches business services with correct authorization | Application owner owns synthetic and user validation |
Help-desk contacts and deployment failures | Expose usability and distribution defects hidden by infrastructure metrics | Service owner tracks volume, reason, resolution time, and repeated device patterns |
Control exceptions | Count users lacking required identity/device parity or still using retired artifacts | Migration lead escalates against expiry and risk acceptance |
Use Microsoft’s P2S diagnostic-log guidance to validate the relevant log categories and queries. Build a correlation record containing user or RADIUS identity, device asset ID, certificate serial/thumbprint where applicable, gateway, tunnel type, assigned client address, connection timestamp, profile version, and application test result. Do not store private keys, shared secrets, or profile passwords in logs.
Remove the Retired Package, Profiles, Repositories, and Exceptions
Decommissioning is a separate workstream, not the final line of an installation script. The retired package can remain on a device, a repository can reinstall it, an old profile can mislead support, or an obsolete certificate can continue to authenticate even after the user adopts the new client. Close each artifact deliberately and retain proof.
Decommission object | Required action | Evidence |
Retired package | Uninstall microsoft-azurevpnclient from every affected endpoint | Endpoint compliance query and sampled local verification |
Microsoft repository entry or deployment source | Remove or disable the source and any automation that can reinstall the package | Repository/configuration diff and failed deployment eligibility check |
Old client profiles and cached configuration | Remove obsolete profiles, shortcuts, services, and user instructions | File/process inventory and service-desk knowledge review |
Legacy credentials | Revoke certificates no longer needed and remove temporary enrollment access | Gateway revoked list, PKI inventory, failed connection test |
Gateway coexistence settings | Disable authentication/tunnel exceptions that have no remaining approved users | Gateway configuration diff and supported-client regression |
Documentation and support scripts | Replace old screenshots, commands, package names, and troubleshooting flows | Published version, owner, review date |
Risk exceptions | Close or renew only with executive approval, named user, compensating controls, and expiry | Risk register and residual-user report |
CMDB and access records | Update target architecture, client/profile version, and owner | Reconciled inventory with zero unexplained devices |
The Azure VPN client decommission is complete only when fleet telemetry, gateway evidence, access records, and support documentation agree. Users who have not connected recently are not automatically safe to ignore; remove their access or require reapproval and fresh enrollment before a future connection.
Prepare Failure Recovery and Rollback Without Reinstating Unsupported Software
Remote-access continuity should follow the same tested dependency and recovery discipline described in Refonte Learning’s cloud-native resilience engineering, but the recovery objective here is narrower: restore a supported path to critical applications without weakening authentication or reviving retired software.
Failure | Supported recovery action | Do not do |
Certificate path rejects valid users | Pause the wave; verify trust chain, credential, profile, time, and revocation state; restore the last tested supported target if needed. | Reinstall the retired client as the default fallback. |
Route or DNS change breaks applications | Withdraw the bad profile or route, restore supported settings, regenerate profiles, and retest. | Leave users on mixed, undocumented route sets. |
RADIUS primary fails | Use tested secondary behavior; move critical users to the approved contingency if service objectives fail. | Enable fail-open or share emergency credentials broadly. |
RADIUS tier or directory is unavailable | Use the documented, scoped, time-limited emergency path and retain break-glass evidence. | Create an unreviewed certificate exception during the incident. |
Certificate issuer or private key is compromised | Remove affected trust, isolate devices, activate a clean issuer or alternate path, and reissue. | Keep compromised credentials active for convenience. |
Managed Windows or macOS path regresses | Restore the captured supported gateway configuration and validate those clients. | Exclude other clients because the Linux change triggered the regression. |
Critical application is unreachable | Move the cohort to its approved fallback, revert the relevant change, and involve the owner. | Continue the wave while users improvise tunnels. |
Define rollback triggers in measurable terms: critical-user authentication failure, an uncontained authorization bypass, revocation outside the approved time, loss of identity correlation, route/DNS failure across a critical application, or support volume exceeding operational capacity. Roll back the affected wave or configuration, not the entire security model. Preserve evidence, identify the failed assumption, and repeat the relevant negative tests before promotion.
Run a Deadline-Relative Migration and Post-Deadline Remediation Plan
Define T-0 as August 31, 2026, the official retirement date. Before T-0, follow the T-minus windows. After T-0, enter at T+1, treat each unsupported client as a production-remediation exception, and complete the same discovery, control, migration, and removal evidence without reviving retired software.
Window | Accountable owner | Required action | Exit evidence |
T-30 to T-22 | Sponsor and migration lead | Freeze new installs, snapshot gateway settings, open the exception register, and notify users. | Named owners, approved scope, baseline, and no new unsupported deployments. |
T-21 to T-15 | Endpoint, identity, network, and service owners | Reconcile users, devices, gateways, profiles, applications, and Entra-control dependencies; classify cohorts. | Complete inventory, risk classes, and escalated unknowns. |
T-14 to T-8 | Architecture, security, and PKI or RADIUS owners | Select primary and fallback paths; approve control mapping; build lifecycle, availability, secrets, and logging. | Signed decision, residual risks, lifecycle or failover tests, and coexistence end date. |
T-7 to T-3 | Gateway, endpoint, and service-desk owners | Stage coexistence, enable diagnostics, version profiles, harden endpoints, and publish support and rollback procedures. | Lab pass, monitoring baseline, profile manifest, compliance, and rollback package. |
T-2 to T-1 | Pilot lead and application owners | Run positive, negative, route, DNS, MTU, and application tests; migrate only passing cohorts. | No critical bypass, application sign-off, revocation timing, and fallback proof. |
T-0 | Migration lead and risk authority | End approved use of the retired package; send unresolved users to supported fallback; record residual dependencies. | No approved unsupported path; every residual case has controls, owner, expiry, and acceptance. |
T+1 to T+7 | Incident or remediation lead | Find and isolate remaining dependencies, migrate or replace access, and reconcile failed or ambiguous attempts. | Named residual list, containment, successful target tests, and closure criteria. |
T+8 to T+14 | Endpoint, gateway, PKI, and support owners | Remove package, repository, profiles, stale credentials, temporary exceptions, and unneeded coexistence; update documentation. | Fleet compliance, gateway diff, failed legacy test, and current support material. |
T+15 to T+30 | Service owner and sponsor | Close or renew dated exceptions; transfer ownership; schedule renewal, failover, access-review, and recovery tests. | Zero unexplained users, signed closure, dated exceptions, and recurring tests. |
A remaining exception record must name the user, device, business impact, unsupported dependency, controls lost, compensating controls, approved fallback, owner, approval date, and expiration. Do not accept “user unavailable” or “application too critical to change” without a supported contingency and a date. Report residual risk by count, business criticality, and days past T-0—not by percentage complete alone.
A successful tunnel is not a successful migration. Completion requires proof that identity, device trust, revocation, routes, DNS, authorization, monitoring, support, recovery, and decommissioning work together. In certificate-ready environments, the fastest safe path is a documented OpenVPN or strongSwan configuration, unique user-device certificates from a mature private public key infrastructure, fixed coexistence, and removal after negative tests. An established, resilient RADIUS tier can preserve centralized authentication, but it must still survive network, directory, secret, latency, and outage tests.
Stop rather than downgrade when privileged or regulated access requires Entra Conditional Access, multifactor authentication, device compliance, immediate disablement, or attributable sign-ins the target cannot reproduce. Use a supported managed platform or independently evaluated identity-aware path. Refonte Learning’s Cloud Architecture Program covers relevant Linux and Azure foundations: identity and access management, virtual networks, routing, private connectivity, security, observability, resilience, Terraform, policy as code, and cloud financial operations (FinOps). The page lists four months at 8–12 hours per week and a Training Certificate and Certificate of Internship for successful participants. It does not list OpenVPN, strongSwan, RADIUS, or this retirement; assess product-specific preparation separately.