Technical Lab: Implement a site-to-site VPN connection
Questions
Question 1 — Multiple Choice
A network team needs to connect on-premises infrastructure to a VNet in Azure using a site-to-site VPN connection. The local VPN device only supports IKEv1 and the Azure gateway has been provisioned with the VpnGw1 SKU.
Which statement correctly describes the expected behavior in this scenario?
A) The connection will be established normally, as the VpnGw1 SKU supports both IKEv1 and IKEv2 by default.
B) The connection will fail because the VpnGw1 SKU only supports IKEv2.
C) The connection will be established, but with bandwidth limited to 100 Mbps for using IKEv1.
D) The connection will require creating a second gateway with Basic SKU for IKEv1 compatibility.
Question 2 — Technical Scenario
An engineer configured a site-to-site VPN connection between an Azure VNet and an on-premises data center. After provisioning, the connection status in the portal shows as "Connected", but VMs in the VNet cannot communicate with on-premises servers.
Consider the Local Network Gateway configuration below:
Local Network Gateway
Name: lng-datacenter
IP Address: 203.0.113.10
Address Space: 10.10.0.0/16
And the actual on-premises subnet configuration:
On-premises servers: 192.168.5.0/24
VPN device gateway: 203.0.113.10
What is the most likely cause of the communication failure?
A) The public IP of the on-premises VPN device is incorrect in the Local Network Gateway.
B) The address space configured in the Local Network Gateway does not match the actual on-premises servers subnet.
C) The Azure VNet does not have a static route pointing to the local gateway.
D) The Virtual Network Gateway SKU does not support the traffic volume between the networks.
Question 3 — True or False
Statement: In a site-to-site VPN connection in Azure, it is possible to use the same Virtual Network Gateway for both site-to-site and point-to-site connections simultaneously, as long as the gateway is not the Basic SKU.
True or False?
Question 4 — Technical Scenario
A company has two remote offices, each with its own VPN device, and wants to connect them to the same Azure VNet. The responsible engineer created two distinct Local Network Gateways and is trying to create the second site-to-site connection from the same Virtual Network Gateway.
After successfully creating the first connection, when trying to create the second, the engineer observes that the operation fails with the following message:
The virtual network gateway does not support multiple connections
with the same local network gateway IP address.
Both offices have distinct public IPs. What is the most likely cause of the error?
A) The Virtual Network Gateway SKU does not support multiple site-to-site connections.
B) The gateway VPN type is configured as Policy-Based, which allows only a single connection.
C) Both Local Network Gateways are configured with the same address space, causing routing conflicts.
D) The second connection requires a second Virtual Network Gateway in a different dedicated subnet.
Question 5 — Multiple Choice
When provisioning a Virtual Network Gateway for a site-to-site VPN connection, the engineer needs to create a specific subnet in the VNet. Which of the options below correctly describes the mandatory requirements for this subnet?
A) The subnet must be named GatewaySubnet and can have any prefix size, including /29.
B) The subnet must be named GatewaySubnet and it is recommended to use /27 or larger to support high availability configurations and coexistence with other gateways.
C) The subnet can have any name, but must be dedicated exclusively to the gateway and use the /28 prefix.
D) The subnet must be named AzureGatewaySubnet and have a minimum size of /27.
Answer Key and Explanations
Answer Key — Question 1
Answer: A
The VpnGw1 SKU and all SKUs in the VpnGw family support both IKEv1 and IKEv2. The restriction of supporting only IKEv2 exists only in the Basic SKUs of the older generation, and even then in specific scenarios. Therefore, an on-premises device that supports only IKEv1 can establish the connection with a VpnGw1 gateway normally.
The main misconception represented by the distractors is confusing the Basic SKU limitation with production SKUs of the VpnGw family. Option C introduces a non-existent throughput limitation associated with the IKEv1 protocol, which has no technical basis. Option D reverses the logic: the Basic SKU is the most limited, not the most compatible.
Answer Key — Question 2
Answer: B
The "Connected" status indicates that the VPN tunnel (IKE phase) was successfully established between the two endpoints. However, data communication depends on correct routing within the tunnel. The Local Network Gateway defines which on-premises network prefixes Azure considers accessible through that connection.
In the presented scenario, the Address Space of the Local Network Gateway is configured as 10.10.0.0/16, but the actual servers are in 192.168.5.0/24. Azure will not send traffic destined for 192.168.5.0/24 through the tunnel because this prefix is not declared in the Local Network Gateway. The result is an active tunnel, but without effective routing to the correct hosts.
Option A is wrong because the VPN device IP is correct. Option C is wrong because Azure automatically injects routes via gateway, without needing manual static routes in the VNet. Option D is wrong because the problem is configuration, not capacity.
Answer Key — Question 3
Answer: True
A Virtual Network Gateway in Azure supports site-to-site and point-to-site connections simultaneously. This coexistence is a native and documented functionality, allowing remote offices (site-to-site) and individual users (point-to-site) to connect to the same VNet through the same gateway.
The real restriction is in the Basic SKU: it does not support point-to-site connections based on RADIUS certificate or Microsoft Entra ID, and has general limitations that make it unsuitable for production environments. SKUs like VpnGw1 and above fully support the coexistence of both connection types. Confusing "not supported in Basic" with "not supported in general" is the most common misconception on this topic.
Answer Key — Question 4
Answer: B
When the Virtual Network Gateway VPN type is Policy-Based, the gateway supports only a single site-to-site connection. Policy-based VPNs use static access lists to define traffic that enters the tunnel, which architecturally prevents multiple simultaneous connections.
To connect multiple sites to the same gateway, the VPN type must be Route-Based. Route-Based gateways use dynamic or static routing to direct traffic through tunnels, supporting multiple simultaneous connections without conflict.
Option A is wrong because the problem is not the SKU, but the VPN type. Option C is wrong because the error message does not mention address space conflict, and the gateway IPs are distinct. Option D is wrong because multiple site-to-site connections from the same gateway are fully supported in Route-Based mode.
Answer Key — Question 5
Answer: B
The name GatewaySubnet is mandatory and exact: Azure identifies this subnet by name to associate with the Virtual Network Gateway. No other name is accepted.
Regarding size, the /29 prefix is technically accepted by the portal, but is inadequate for environments requiring high availability (active-active) or coexistence with other gateways like the ExpressRoute Gateway, as these scenarios demand more IP addresses within the subnet. Microsoft explicitly recommends /27 or larger to avoid future restrictions.
Option A is partially correct on the name, but /29 is discouraged and may make advanced configurations unfeasible. Option C is wrong on the name: any name different from GatewaySubnet will cause provisioning to fail. Option D is wrong on the name: AzureGatewaySubnet is not accepted by Azure.