Technical Lab: Create and configure a local network gateway
Questions
Question 1 — Multiple Choice
When creating a local network gateway in Azure to represent an on-premises VPN device, an administrator needs to decide which information is required during resource creation.
Considering a scenario where the on-premises VPN device has the public IP 203.0.113.45 and manages the address prefix 10.10.0.0/16, which set of information is sufficient and necessary to create the local network gateway?
A) Resource name, Azure gateway IP address, on-premises address prefix, and Azure region.
B) Resource name, on-premises VPN device public IP address, on-premises address prefix, and resource group.
C) Resource name, shared key, on-premises address prefix, and VPN device public IP address.
D) Resource name, on-premises VPN device public IP address, BGP ASN, and resource group.
Question 2 — Technical Scenario
A network team configured a Site-to-Site VPN connection between Azure and a remote office. The local network gateway was created with the prefix 192.168.1.0/24. Later, the remote office expanded its network and added the segment 192.168.2.0/24.
Users from the new segment cannot access resources in Azure. The VPN connection remains active and traffic from the original segment works normally.
Local Network Gateway — current state:
Address space: 192.168.1.0/24
New on-premises segment: 192.168.2.0/24
VPN connection status: Connected
What is the most likely cause and correct action?
A) The VPN connection needs to be recreated to include the new prefix, as prefixes cannot be changed after creation.
B) The prefix 192.168.2.0/24 should be added to the address space of the existing local network gateway, without needing to recreate the connection.
C) A second local network gateway should be created exclusively for the new prefix 192.168.2.0/24.
D) The virtual network gateway needs to be reconfigured with the new prefix, as it is responsible for storing on-premises addresses.
Question 3 — True or False
Statement: when BGP is enabled on a Site-to-Site VPN connection, the address prefixes configured in the local network gateway are ignored by Azure and completely replaced by routes advertised via BGP by the on-premises device.
True or False?
Question 4 — Technical Scenario
An architect needs to configure a Site-to-Site VPN connection between Azure and a business partner. The partner's VPN device does not have a static public IP address: it uses a dynamic IP address with a fixed FQDN (Fully Qualified Domain Name), such as vpn.parceiro.com.br.
The architect considers the following approaches for the local network gateway address field:
Option 1: Insert the partner's current dynamic IP in the "IP address" field
Option 2: Insert the FQDN in the "FQDN" field available in the local network gateway
Option 3: Create the local network gateway without an address and configure BGP only
Option 4: Use a second virtual network gateway instead of the local network gateway
Which approach is technically valid and supported by Azure?
A) Option 1, manually updating the IP in the local network gateway whenever the partner's address changes.
B) Option 2, as the local network gateway natively supports using FQDN instead of the public IP address.
C) Option 3, as when BGP is active the peer IP address is sufficient and the main address field is optional.
D) Option 4, as devices without static IP cannot be represented by a local network gateway.
Question 5 — Multiple Choice
An administrator needs to configure BGP on a Site-to-Site VPN connection. He has already created the local network gateway without enabling BGP. Now he wants to add BGP settings to the existing resource.
What information is required to enable BGP on the local network gateway?
A) ASN (Autonomous System Number) of the on-premises device and the IP address of the on-premises BGP peer.
B) ASN of the on-premises device, BGP peer IP address, and the shared key of the connection.
C) ASN of the on-premises device, BGP peer IP address, and the address prefixes that will be advertised.
D) ASN of the on-premises device and the on-premises address prefixes already configured in the local network gateway.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
The local network gateway is an Azure resource that represents the VPN device or on-premises site. To create it, the following are required: a name, the public IP address of the on-premises VPN device (or its FQDN), the address space (prefixes) it manages, and a resource group for allocation.
The IP address of the Azure virtual network gateway is not specified here: the local network gateway describes the remote side (on-premises), not the Azure side. The shared key is configured in the connection, not in the local network gateway. The BGP ASN is only necessary if BGP is enabled, and is optional in standard creation.
Choosing A, C, or D represents the common confusion between which information belongs to the local network gateway versus the connection or virtual network gateway.
Answer Key — Question 2
Answer: B
The local network gateway stores the address prefixes that represent the on-premises network. This address space can be edited at any time without needing to recreate the resource or connection. Simply add 192.168.2.0/24 to the address space of the existing local network gateway.
The VPN connection itself does not need to be interrupted or recreated for this change. Azure will automatically propagate the new prefix to the connection routing after the update.
Alternative A is wrong because prefixes in the local network gateway are editable. Alternative C is inefficient and unnecessary: a single local network gateway can contain multiple prefixes. Alternative D reveals a fundamental misconception: on-premises prefixes are managed in the local network gateway, never in the virtual network gateway.
Answer Key — Question 3
Answer: False
When BGP is enabled on a Site-to-Site VPN connection, the prefixes configured statically in the local network gateway and routes learned via BGP coexist. Azure does not ignore static prefixes: it uses them together with BGP routes.
In practice, when BGP is active, Microsoft's recommendation is to insert only the BGP peer IP address in the local network gateway prefix field (usually as /32), but this is a configuration convention, not an automatic replacement. BGP routes advertised by the on-premises device complement routing, but do not erase the static prefixes defined in the resource.
Understanding this distinction is important to avoid duplicate or conflicting routing in hybrid environments.
Answer Key — Question 4
Answer: B
Azure natively supports using FQDN in the local network gateway address field as an alternative to static public IP address. This functionality was added to support scenarios where the partner's or remote site's VPN device has a dynamic IP address with fixed DNS.
Alternative A is functionally possible, but represents a manual process subject to failures and is not the recommended or natively supported approach for dynamic addresses. Alternative C is incorrect: BGP requires the peer IP address, it does not eliminate the need to identify the remote endpoint. Alternative D is wrong because the local network gateway was designed exactly to represent external devices, including those without static IP.
Answer Key — Question 5
Answer: A
To enable BGP on a local network gateway, Azure requires only two additional fields: the ASN (Autonomous System Number) of the on-premises device and the on-premises BGP peer IP address (usually the loopback interface address or tunnel interface of the remote router).
The shared key belongs to the connection, not the local network gateway, so alternative B is incorrect. Address prefixes (alternatives C and D) are configured in the address space field of the local network gateway and are independent of BGP configuration: when BGP is active, the recommended practice is to define the peer address as a /32 prefix, but this is not a field of the BGP configuration itself. Confusing where each piece of information is configured is the most frequent error in this context.