Troubleshooting Lab: Select and Configure a Tunnel Type
Diagnostic Scenarios
Scenario 1 — Root Cause
A network team reports that the site-to-site connection between the on-premises environment and Azure was successfully established for several months. After routine maintenance on the on-premises perimeter firewall, the VPN connection stopped coming up. The Azure VPN gateway shows Connected status in the portal, but the tunnel appears as Disconnected on the on-premises side.
The administrator collects the following information:
# Diagnostic output on on-premises gateway
IKE Phase 1: FAILED
Error: No proposal chosen
Local proposal: IKEv2, AES-256, SHA-256, DH Group 14
Remote proposal: IKEv2, AES-128, SHA-1, DH Group 2
# Azure VPN Gateway configuration (custom IPsec policy)
IkeEncryption: AES256
IkeIntegrity: SHA256
DhGroup: DHGroup14
IpsecEncryption: AES256
IpsecIntegrity: SHA256
PfsGroup: PFS14
The on-premises firewall was updated to new firmware during maintenance. The firewall manufacturer confirmed that the previous version supported the same algorithms configured in Azure. The firewall's WAN interface is active with internet connectivity confirmed via ping to external IPs.
What is the root cause of the tunnel failure?
A) The "Connected" status in the Azure portal indicates that the Azure gateway restarted during maintenance and lost the custom IPsec policy configuration
B) The new on-premises firewall firmware is not applying the previously configured IKE proposal, sending parameters incompatible with Azure's IPsec policy
C) The firewall's WAN interface has an MTU issue after the firmware update, causing IKE packet fragmentation and negotiation failure
D) The Azure VPN Gateway entered failover mode and is rejecting new connections until manually restarted
Scenario 2 — Action Decision
The security team identified that the organization's point-to-site tunnel uses SSTP as the only configured protocol type. The cause was confirmed: the corporate security policy was updated to require that all remote clients, including macOS and Linux users, authenticate via Microsoft Entra ID without using individual device certificates.
The current environment is:
Gateway SKU: VpnGw2
Tunnel Type: SSTP
Authentication: Certificate (Root CA + Client Certificate)
Active P2S clients: 47 active sessions currently
VPN Gateway: in use by critical production applications
The scheduled maintenance window is in 6 hours. Changing the tunnel type requires gateway reconfiguration and VPN profile redistribution to all clients.
What is the correct action to take at this time?
A) Add OpenVPN as an additional tunnel type and configure Microsoft Entra ID authentication immediately, without waiting for the maintenance window, since adding a new protocol doesn't drop existing SSTP sessions
B) Replace the tunnel type from SSTP to IKEv2 immediately, since IKEv2 supports Microsoft Entra ID authentication and the change can be made without impacting active sessions
C) Wait for the maintenance window, add OpenVPN to the gateway, configure Microsoft Entra ID authentication and plan the distribution of the new VPN profile to clients
D) Disable SSTP immediately and reconfigure the gateway for OpenVPN, notifying the 47 active users to reconnect after the change
Scenario 3 — Root Cause
An administrator configured a new VNet-to-VNet connection between two VNets in different regions. After configuration, resources in both VNets cannot communicate. The administrator checks the portal and observes the following:
Gateway A (East US):
Type: VPN
VPN Type: PolicyBased
SKU: Basic
Status: Connected
Gateway B (West Europe):
Type: VPN
VPN Type: RouteBased
SKU: VpnGw1
Status: Connected
The administrator confirms that the address spaces of the two VNets do not overlap, that connection objects were created in both directions, and that the shared key was configured identically on both sides. The status of both connections appears as Connected in the portal.
VNet peering was not configured, as the architectural decision was to use VPN Gateway. NSGs applied to subnets do not block traffic between the IP ranges of the two VNets.
What is the root cause of the communication failure?
A) VNet peering was not configured and, without it, communication between VNets in different regions via VPN Gateway doesn't work even with connections created
B) PolicyBased gateways support only one simultaneous connection and are not compatible with VNet-to-VNet connections, making the topology invalid regardless of the displayed status
C) The shared key was configured identically on both sides, which is incorrect: each side must have a different key in VNet-to-VNet connections
D) NSGs applied to subnets are blocking return traffic, as permissive inbound rules without corresponding outbound rules cause asymmetric failure
Scenario 4 — Diagnostic Sequence
A remote user reports that their point-to-site VPN client cannot connect to the Azure VPN Gateway. The configured tunnel type is IKEv2 and the client is on a Windows 11 laptop. The administrator needs to diagnose the problem.
The following investigation steps are available, out of order:
[P] Verify if the root certificate is loaded in the Azure VPN Gateway
[Q] Verify if the VPN profile was generated and distributed after the
last gateway configuration change
[R] Test network connectivity from client to the gateway's public
endpoint on UDP port 500
[S] Verify if the client certificate was generated from the correct
root CA and is installed in the correct Windows store
[T] Review VPN client logs to identify at which phase of IKE
negotiation the failure occurs
What is the correct investigation sequence?
A) T, R, P, S, Q
B) R, T, P, S, Q
C) P, Q, S, R, T
D) R, P, Q, S, T
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The definitive clue is in the diagnostic log: the IKE proposal sent by the on-premises device uses AES-128, SHA-1, and DH Group 2, while Azure's custom policy requires AES-256, SHA-256, and DH Group 14. The "No proposal chosen" error is the classic indicator of IKE Phase 1 proposal incompatibility. The updated firmware is not applying the previous configuration, sending a default proposal different from what's expected.
The information about the WAN interface being active with working ping is irrelevant to this diagnosis: the problem is not network connectivity, but cryptographic parameter incompatibility. It was included to divert reasoning toward MTU or routing issues.
The most dangerous distractor is alternative A. The "Connected" status in the Azure portal might confuse someone who associates this state with the configuration being intact. In reality, the portal may cache the previous status for a few minutes, and the Azure gateway doesn't restart or lose configuration during on-premises maintenance.
Acting based on distractor A would lead the administrator to restart the Azure gateway unnecessarily, causing interruption to other gateway connections.
Answer Key — Scenario 2
Answer: C
The critical constraint in the scenario is the existence of 47 active sessions in a production environment and an available maintenance window in 6 hours. The correct action is to wait for this window to add OpenVPN to the gateway and configure Microsoft Entra ID authentication.
Alternative A seems technically correct but ignores a real constraint: changes to tunnel type or P2S gateway authentication configuration require clients to download and reinstall the updated VPN profile. Adding OpenVPN alone doesn't drop existing SSTP sessions, but the redistribution process and potential instability during the change justify using the maintenance window.
Alternative B is technically wrong: IKEv2 does not support Microsoft Entra ID authentication in P2S connections. This is the most common conceptual mistake on this topic.
Alternative D represents the correct action in essence, but executed at the wrong time, without respecting production constraints. Dropping 47 active sessions without a maintenance window is an operationally incorrect decision.
Answer Key — Scenario 3
Answer: B
PolicyBased gateways have fundamental restrictions: they support only IKEv1, allow one simultaneous connection only, and are not compatible with VNet-to-VNet connections. This gateway type was designed exclusively for legacy site-to-site connections with specific devices. The "Connected" status displayed in the portal doesn't mean data traffic is flowing correctly; it only reflects the control tunnel negotiation state.
The information about NSGs allowing traffic, non-overlapping address spaces, and identical shared key are correct and irrelevant data for the root cause: they were included to divert diagnosis toward security and routing checks.
The most dangerous distractor is alternative A. VNet peering is not necessary when communication occurs via VPN Gateway: the two approaches are mutually exclusive in the architecture. An administrator choosing A would waste time configuring peering without solving the real problem, which is gateway type incompatibility.
Answer Key — Scenario 4
Answer: B
The correct sequence is R, P, Q, S, T, which follows the logic of progressive elimination from external to internal:
- R — Check network connectivity first. If UDP 500 is blocked, no subsequent step makes sense.
- P — Confirm that the root certificate is present in the gateway. Without it, no client can authenticate.
- Q — Verify if the VPN profile was regenerated and distributed after gateway changes. An outdated profile will cause failure even with correct configuration.
- S — Validate the client certificate: correct source CA and correct Windows store.
- T — Only after confirming that infrastructure, certificates, and profile are correct, analyze logs to identify at which IKE phase the failure occurs.
Alternative A (T first) represents the error of jumping straight to logs without validating prerequisites, which frequently leads to inconclusive diagnoses because log failures point to symptoms, not root causes. Alternative C (P first before R) ignores that without network connectivity, all other checks are pointless.
Troubleshooting Tree: Select and Configure a Tunnel Type
Color Legend:
| Color | Node Type |
|---|---|
| Dark Blue | Initial symptom (entry point) |
| Medium Blue | Diagnostic question (decision) |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Validation or intermediate verification |
To use this tree when facing a real problem, start at the root node and answer each question based on what you observed in the environment. Follow the path that corresponds to your scenario: site-to-site, VNet-to-VNet, or point-to-site. At each fork, answer only with what is verifiable at that moment, without assuming causes. The path ends at a red node that names the cause and a green node that indicates the action. If the identified cause doesn't resolve the problem after corrective action, return to the previous question node and follow the alternative path.