Troubleshooting Lab: Azure Network Adapter
Diagnostic Scenarios
Scenario 1 — Root Cause
An administrator configured the Azure Network Adapter on an on-premises server with Windows Server 2022 using Windows Admin Center. The process completed without apparent errors and WAC displayed the success message. However, when trying to access a VM in the VNet 172.16.0.0/16 from the server, all ping attempts and TCP connections fail.
The administrator checks the virtual interface status on the server:
Get-NetAdapter | Where-Object { $_.InterfaceDescription -like "*Azure*" }
Name InterfaceDescription Status
---- -------------------- ------
Azure Network Adapter Microsoft Azure VPN Adapter Up
Get-NetIPAddress -InterfaceAlias "Azure Network Adapter"
IPAddress : 192.168.200.5
PrefixLength : 32
AddressFamily : IPv4
The administrator also confirms that the VPN Gateway was provisioned in Azure and that the P2S connection status in the portal shows as Connected. The on-premises server has Windows Defender Firewall active with the domain profile applied. The target VNet does not have Network Security Groups associated with the subnets.
What is the root cause of the connectivity failure?
A) Windows Defender Firewall is blocking outbound traffic to the 172.16.0.0/16 range on the on-premises server
B) The P2S address pool configured on the VPN Gateway conflicts with the VNet address range
C) Routes to the 172.16.0.0/16 range were not added to the on-premises server routing table
D) The VPN Gateway was provisioned on the Basic SKU, which does not support P2S connections via Azure Network Adapter
Scenario 2 — Action Decision
The infrastructure team identified that an on-premises server with Azure Network Adapter installed lost connectivity to the Azure VNet after a maintenance window performed last night. The cause was confirmed: the root certificate used for P2S authentication expired and needs to be renewed. The impacted server hosts a file synchronization service that operates continuously and cannot be restarted during business hours. It's 9:15 AM on a Monday. Certificate renewal requires restarting the VPN service on the server.
The team has full administrative access to the server and the Azure portal. There is no scheduled maintenance window before Friday.
What is the correct action to take at this moment?
A) Renew the certificate immediately and restart the VPN service, as Azure connectivity is already interrupted and the current impact is greater than the restart impact
B) Wait for the Friday maintenance window to execute certificate renewal and service restart with controlled impact
C) Remove and reinstall the Azure Network Adapter via WAC, as this process automatically replaces the certificate without requiring manual restart
D) Create a new parallel P2S connection with a valid certificate and redirect traffic before terminating the expired connection
Scenario 3 — Root Cause
An engineer receives a ticket reporting that the Azure Network Adapter stopped working on an on-premises server after a Windows Admin Center update. The server runs Windows Server 2019 and had been operational for three months without incidents. The engineer collects the following information:
Event in Event Viewer (System):
Source: RasMan
ID: 20227
Description: The user CONTOSO\svc-network connected to the VPN.
The tunnel type was: IKEv2.
Authentication method: Certificate.
Status: Failed.
Reason: The certificate chain processed but terminated
in a root certificate which is not trusted by
the trust provider.
The engineer verifies that the client certificate is still present in the Certificates (Local Computer) > Personal repository and that the expiration date is in 18 months. The service account CONTOSO\svc-network has local administrator permissions on the server. WAC was updated from version 2211 to version 2306 during the previous maintenance window.
What is the root cause of the authentication failure?
A) The service account CONTOSO\svc-network lost permissions to access the certificate repository after the WAC update
B) The corresponding root certificate was removed from the Trusted Root Certification Authorities repository on the local server
C) The WAC update changed the authentication method from Certificate to Microsoft Entra ID, invalidating the existing certificate
D) The client certificate is installed in user context instead of machine context, preventing authentication by the RasMan service
Scenario 4 — Collateral Impact
An administrator detected that the VPN Gateway used by the Azure Network Adapter was provisioned on the VpnGw1 SKU, with capacity for up to 250 simultaneous P2S connections. To reduce costs, the administrator downgraded the gateway to the Basic SKU, as there were only 3 on-premises servers connected via Azure Network Adapter at the time. The operation was completed successfully in the Azure portal.
In the following days, the three servers continue connected and functioning normally.
What secondary consequence can this action cause at a future moment?
A) Existing servers will be automatically disconnected after 30 days, as the Basic SKU does not maintain P2S connections provisioned by higher SKU gateways
B) It will not be possible to use certificate-based authentication for new P2S connections, as the Basic SKU only supports authentication via Microsoft Entra ID
C) The aggregate throughput of all P2S connections will be limited to the Basic SKU ceiling, potentially causing performance degradation with the growth in number of servers
D) The Azure Network Adapter will lose support for traffic routing to subnets added to the VNet after the downgrade, requiring manual reconfiguration on each server
Answer Key and Explanations
Answer Key — Scenario 1
Answer: C
The decisive clue is in the Get-NetIPAddress output: the virtual interface received an IP address from the P2S pool (192.168.200.5), which confirms that the tunnel was established successfully. The Connected status in the portal corroborates this. If the tunnel is active but traffic to 172.16.0.0/16 doesn't reach its destination, the cause lies in the server's local routing, not in the tunnel connectivity itself.
The Azure Network Adapter installs routes for VNet prefixes at configuration time, but these routes may not be present if there was a silent failure in this step or if they were removed subsequently. The route print command on the server would reveal the absence of the route to 172.16.0.0/16.
Alternative A is the most dangerous distractor: the Firewall is frequently blamed in connectivity scenarios, but it wouldn't be able to block traffic if the routing itself doesn't know where to send the packets. Alternative B would be identified at configuration time, not after a successful connection. Alternative D is irrelevant because the gateway SKU doesn't prevent displaying the Connected status.
Answer Key — Scenario 2
Answer: A
The critical constraint that determines the correct answer is this: Azure connectivity is already interrupted. The file synchronization service has been without VNet access since last night. Waiting until Friday (alternative B) means accepting additional days of interruption to protect a service that is already degraded. The correct principle here is that the impact of restarting the VPN service is temporary and immediate, while the loss of connectivity is already an accomplished and growing fact.
Alternative C represents a technical misconception: removing and reinstalling the Azure Network Adapter does not automatically replace an expired certificate; the process would generate a new provisioning cycle but would not solve the certification problem more safely than direct renewal. Alternative D describes a valid operation in zero-downtime migration scenarios, but is unnecessarily complex when the original tunnel is already inoperative.
Answer Key — Scenario 3
Answer: B
The RasMan event 20227 is explicit: the certificate chain was processed but terminated in an untrusted root. This indicates that the client certificate exists and is valid (confirmed by the expiration date in 18 months), but the server cannot validate the chain because the root certificate is not in the trust anchor repository. The most likely cause is that the root certificate was inadvertently removed from the Trusted Root Certification Authorities repository during or after the WAC update.
The information about the WAC update from version 2211 to 2306 is purposefully irrelevant: it establishes a temporal correlation that induces the reader to seek a cause related to WAC itself, but WAC does not manage the operating system's root certificate repository. Alternative D represents a classic misconception: the certificate is in Local Computer > Personal, which is exactly where RasMan expects to find it for machine authentication.
The most dangerous distractor is alternative A: focusing on service account permissions after an update seems reasonable, but the error message describes failure in chain validation, not failure to access the repository.
Answer Key — Scenario 4
Answer: C
The real collateral impact is throughput limitation. The Basic VPN Gateway SKU has an aggregate throughput ceiling significantly lower than VpnGw1. With only 3 servers connected at the moment, this limit is not perceived. However, as more servers are added via Azure Network Adapter or as the volume of transferred data increases, the Basic SKU ceiling will become a performance bottleneck.
Alternative A is false: existing P2S connections are not automatically disconnected by SKU downgrade; they continue operational until they are actively terminated. Alternative B represents an important misconception: the Basic SKU does support certificate authentication for P2S; the real limitation of Basic is the absence of BGP support and more advanced protocols, not the authentication method. Alternative D does not correspond to any documented VPN Gateway behavior.
Troubleshooting Tree: Azure Network Adapter
Color legend:
| Color | Node type |
|---|---|
| Dark blue | Initial symptom (entry point) |
| Blue | Diagnostic question |
| Orange | Intermediate check or validation |
| Red | Identified cause |
| Green | Recommended action or resolution |
To use this tree when facing a real problem, start with the root node describing the observed symptom. At each question node, answer based on what you can directly verify on the server or in the Azure portal before advancing to the next level. Intermediate validation nodes indicate points where a specific check is necessary before confirming the hypothesis. Upon reaching a red node, the cause is identified; upon reaching a green node without a cause, the described action resolves or isolates the problem. Never skip levels: the sequence of questions exists to prevent corrective actions applied to the wrong cause.