Technical Lab: Diagnose and Resolve Virtual Network Gateway Connectivity Issues
Questions
Question 1 — Multiple Choice
A network team configured a Site-to-Site VPN Gateway connection between the on-premises network and an Azure VNet. The connection shows "Connected" status in the portal, but traffic doesn't flow between networks. The team has already confirmed that routes are correct and NSGs don't block traffic.
What is the most likely cause of the problem?
A) The VPN Gateway SKU doesn't support Site-to-Site connections
B) The shared key (PSK) configured in the Azure gateway doesn't match the one configured on the on-premises device
C) BGP wasn't enabled on the connection, preventing route exchange
D) The gateway subnet was configured with /29 prefix, which is insufficient for the service
Question 2 — Technical Scenario
An engineer is diagnosing an ExpressRoute connection that shows high latency and intermittent packet loss. The circuit is provisioned and the private peering status appears as "Provisioned". The following command was executed on the gateway:
Get-AzVirtualNetworkGatewayBGPPeerStatus `
-VirtualNetworkGatewayName "gw-prod" `
-ResourceGroupName "rg-network"
The result shows the peer with state "Idle" instead of "Connected".
What is the most likely cause of this behavior?
A) The ExpressRoute circuit was provisioned in Local tier, which doesn't support BGP
B) The ASN configured in the Azure gateway conflicts with the connectivity provider's ASN
C) The BGP session between the gateway and Microsoft Edge Router (MSEE) wasn't established, indicating a problem at the peering layer
D) The gateway is using Standard SKU, which doesn't support ExpressRoute
Question 3 — True or False
A VPN Gateway configured with Active-Active and BGP enabled guarantees automatic failover without traffic interruption (zero downtime) in case of failure of one gateway instance, because both instances maintain independent BGP sessions with the on-premises device.
Is this statement true or false?
Question 4 — Technical Scenario
An organization has the following topology:
On-premises
|
| Site-to-Site VPN
|
Hub VNet (10.0.0.0/16)
|
| VNet Peering
|
Spoke VNet (10.1.0.0/16)
On-premises users can access resources in the Hub VNet, but cannot access resources in the Spoke VNet. The VNet Peering between Hub and Spoke is in "Connected" state.
Which configuration is missing or incorrect?
A) The gateway subnet of the Hub VNet needs to be expanded to include the Spoke VNet prefix
B) The Hub-to-Spoke peering needs "Allow gateway transit" enabled, and the Spoke-to-Hub peering needs "Use remote gateways" enabled
C) A static route pointing to 10.1.0.0/16 needs to be added directly on the on-premises VPN device
D) BGP needs to be enabled on the VPN Gateway to automatically propagate Spoke VNet routes
Question 5 — Multiple Choice
When using Network Watcher VPN Diagnostics to troubleshoot a failed Site-to-Site connection, the log returns the following error:
IKE authentication credentials are unacceptable
Which of the following items should be checked as priority based on this message?
A) The contracted bandwidth in the gateway SKU and the count of active tunnels
B) Return traffic and whether the gateway subnet NSG is blocking UDP 500
C) The Pre-Shared Key, IKE Phase 1 parameters (encryption, integrity, DH group), and certificates if certificate authentication is used
D) Address prefix overlap between the Azure VNet and on-premises network
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Explanation:
- The "Connected" status in the portal indicates that the IKE tunnel was successfully established at the control plane level, but this doesn't guarantee data flow. The PSK is negotiated during IKE Phase 1; if there's a mismatch, the tunnel may appear connected on one side and failed on the other, depending on the device implementation. In this scenario, PSK inconsistency is the classic cause of "connected without traffic".
- Alternatives A and D are dismissible in context: the minimum SKU (Basic) supports Site-to-Site, and
/29is the minimum accepted prefix for gateway subnet (6 usable IPs, sufficient). BGP (alternative C) is optional for Site-to-Site and its absence doesn't prevent traffic flow when static routes are correct, as the statement confirms. - Choosing C would lead to investigating a feature that's not a prerequisite, delaying the actual diagnosis.
Answer Key — Question 2
Answer: C
Explanation:
- The "Idle" state in BGP peer status indicates that the TCP session on port 179 wasn't established between the Azure gateway and MSEE. This occurs at the peering layer, not at the circuit provisioning layer. A circuit with "Provisioned" status only confirms that the provider completed the physical and logical link configuration, but not that BGP is functional.
- Alternative A is incorrect: Local tier supports BGP, the difference is in announced routes (local only). Alternative B is plausible, but ASN conflict usually prevents peering establishment from the beginning, doesn't cause intermittent "Idle" state. Alternative D is incorrect: Standard SKU supports ExpressRoute.
- The next diagnostic step would be to verify peering IP configurations, VLAN ID, and ASN in the ExpressRoute circuit portal and with the provider.
Answer Key — Question 3
Answer: False
Explanation:
- Active-Active configuration with BGP significantly improves resilience, but doesn't guarantee zero downtime. In case of instance failure, BGP sessions established by that instance need to be reestablished by the surviving instance. This BGP reconvergence process introduces interruption of several seconds to tens of seconds, depending on configured timers (hold time, keepalive).
- The non-obvious point is that "Active-Active" describes the traffic forwarding topology (both instances process data simultaneously), not control session continuity. To minimize downtime, the on-premises device must also support two independent tunnels with both instances and BGP timers should be optimized.
- Confusing "high availability" with "zero downtime" is a common mistake when designing resilience solutions with VPN Gateway.
Answer Key — Question 4
Answer: B
Explanation:
- In a Hub-and-Spoke topology, the VPN Gateway resides in the Hub. For traffic originating on-premises to reach the Spoke, Azure requires two peering configurations to be active together: "Allow gateway transit" on the Hub side (allowing the gateway to be shared with peered networks) and "Use remote gateways" on the Spoke side (instructing the Spoke to use the Hub's remote gateway for external traffic routing).
- Alternative A is incorrect: the gateway subnet doesn't need to know Spoke prefixes; routing is done by the data plane, not by subnet sizing. Alternative C confuses routing responsibility: the on-premises device doesn't need manual static routes when the gateway announces routes correctly. Alternative D is a condition that improves dynamic propagation, but doesn't solve the absence of peering flags.
- This is one of the most frequent configuration errors in Hub-and-Spoke topologies in Azure.
Answer Key — Question 5
Answer: C
Explanation:
- The message
IKE authentication credentials are unacceptableis generated during IKE Phase 1 and indicates that authentication credentials presented by the peer were rejected. This covers three main scenarios: incorrect or mismatched PSK, incompatible cryptographic parameters (encryption algorithm, integrity algorithm, or Diffie-Hellman group), or invalid/expired certificate when certificate authentication is used. - Alternative B (NSG blocking UDP 500) would cause IKE initialization failure, but diagnostic log wouldn't reach the authentication phase to generate this specific message. Alternative D (prefix overlap) would cause routing problems after tunnel establishment, not authentication failure. Alternative A is irrelevant for this type of error.
- Knowing how to interpret VPN Diagnostics error codes is essential to reduce resolution time, as each message points to a specific layer of the IKE negotiation process.