4 of the 9 questions we have for this objective, shown with the answer and the reasoning.
Design, implement, and manage a site-to-site VPN connection
Cobalt Ridge Manufacturing is moving 12 virtual machines from an on-premises Hyper-V cluster to Azure. The VMs run a licensing server and shop-floor controllers whose IP addresses in the 192.168.50.0/24 subnet are hard-coded in hundreds of PLCs and cannot be changed. A site-to-site VPN already connects the plant to the virtual network vnet-plant. The company wants the migrated VMs to keep their 192.168.50.x addresses while the remaining machines on that subnet stay on-premises.
What should you implement?
- AAzure Extended Network, deploying one virtual appliance on-premises on a Windows Server Hyper-V host and one appliance VM in vnet-plant, then selecting the IP addresses to extend.Azure Extended Network stretches an on-premises subnet to Azure using two virtual appliances and VXLAN over the existing VPN or ExpressRoute connection, so migrated VMs keep their original IP addresses while other hosts remain on-premises.
- BAdd 192.168.50.0/24 as a second address space to vnet-plant and create a subnet with that prefix for the migrated VMs.A virtual network address space cannot overlap the on-premises address space declared on the local network gateway, and the subnet would conflict with the machines that remain on-premises.
- CConfigure NAT rules on the VPN gateway to translate the migrated VMs' new Azure addresses to their old 192.168.50.x addresses.VPN gateway NAT translates whole prefixes between sites with overlapping ranges; it does not let a single subnet be split across on-premises and Azure while hosts keep their addresses.
- DDeploy Azure Virtual Network Manager and create a mesh connectivity configuration that includes the on-premises subnet.Azure Virtual Network Manager manages connectivity and security between Azure virtual networks; it cannot include an on-premises subnet or extend layer 2 addressing.
Why: Azure Extended Network is purpose-built for the case where machines must keep their IP addresses during a migration and the subnet is temporarily split between on-premises and Azure. It uses two appliances (one on a Windows Server Hyper-V host on-premises, one as an Azure VM) that tunnel layer 2 traffic over VXLAN across an existing site-to-site VPN or ExpressRoute connection, and it is managed from Windows Admin Center. The deciding constraint is that the addresses are hard-coded and some hosts stay on-premises; this rules out simply re-addressing or declaring the subnet in Azure, since overlapping address spaces across the VPN are not allowed. VPN NAT and Virtual Network Manager are real features used out of context.
Design, implement, and manage a site-to-site VPN connection
Halvorsen Shipping must connect a legacy on-premises firewall that supports only policy-based (IKEv1, access-list driven) IPsec to a virtual network named vnet-ops. The same virtual network already hosts a VpnGw2 route-based gateway that serves a point-to-site VPN for 300 remote engineers and two other site-to-site tunnels. The company does not want to disrupt the existing connections and does not want to deploy a second gateway.
What should you do?
- AChange the VPN type of the existing gateway from RouteBased to PolicyBased.The VPN type cannot be changed after a gateway is created; you would have to delete and recreate the gateway. A policy-based gateway also supports only one tunnel, no point-to-site, and only the Basic SKU, so it would break the existing connections.
- BCreate a connection from the existing route-based gateway to the legacy firewall and enable policy-based traffic selectors together with a custom IPsec/IKE policy on that connection.A route-based gateway can connect to a policy-based device when the connection uses a custom IPsec/IKE policy with the UsePolicyBasedTrafficSelectors option enabled. The other tunnels and the point-to-site configuration are unaffected.
- CDeploy a second virtual network gateway of VPN type PolicyBased in a new GatewaySubnet in vnet-ops.A virtual network can have only one VPN gateway and one GatewaySubnet, and the company does not want a second gateway in any case.
- DEnable BGP on the existing gateway so the legacy firewall can learn the Azure routes dynamically.BGP requires a route-based IKEv2 device that supports BGP; a legacy policy-based firewall negotiates IKEv1 with access-list selectors and cannot use BGP.
Why: Policy-based VPN gateways in Azure are limited to the Basic SKU, a single site-to-site tunnel, IKEv1, no point-to-site, and no BGP, so they are only suitable for a single legacy device with no other requirements. Because the scenario already depends on a route-based gateway for multiple tunnels and point-to-site, the gateway must remain route-based. The documented solution for connecting a route-based gateway to a policy-based on-premises device is to apply a custom IPsec/IKE policy on the connection and enable policy-based traffic selectors, which makes Azure negotiate prefix-to-prefix selectors the legacy device expects. Changing the VPN type in place is the trap: it is not supported after creation.
Design, implement, and manage a site-to-site VPN connection
Juniper Lane Insurance is creating its first VPN gateway in a virtual network named vnet-claims (10.80.0.0/16) in the North Europe region. Requirements: the gateway must support BGP and future point-to-site clients using IKEv2 and OpenVPN, and the company may later add an ExpressRoute gateway to the same virtual network. The administrator plans to create a subnet named snet-gateway with prefix 10.80.255.0/29 and deploy a Basic SKU route-based gateway into it.
Which two settings in the plan must be changed so the deployment succeeds and meets the requirements? Each correct answer presents part of the solution.
- AName the subnet GatewaySubnet and size it /27 or larger.A virtual network gateway must be deployed into a subnet named exactly GatewaySubnet. Only the Basic SKU can use a subnet as small as /29; every VpnGw SKU requires /27 or larger, which also leaves room for an ExpressRoute gateway to coexist later.
- BUse a VpnGw SKU such as VpnGw1AZ instead of Basic.The Basic SKU does not support BGP, RADIUS, or the IKEv2 and OpenVPN tunnel types for point-to-site (it offers SSTP only). VpnGw1AZ or higher supports BGP and both modern point-to-site tunnel types.
- CSet the gateway type to ExpressRoute so that a later ExpressRoute circuit can share the gateway.A VPN gateway and an ExpressRoute gateway are separate resources with different gateway types. Setting the type to ExpressRoute would create an ExpressRoute gateway, not a VPN gateway.
- DSet the VPN type to PolicyBased so the gateway can support point-to-site clients.Policy-based gateways do not support point-to-site or BGP at all. Route-based is required for both.
- EAssociate a network security group to the GatewaySubnet to permit IKE traffic.Network security groups are not supported on the GatewaySubnet and are not needed; the platform manages gateway traffic.
Why: Two things are wrong with the plan. First, Azure requires the gateway subnet to be named GatewaySubnet; a subnet named snet-gateway cannot host a gateway. A /29 is allowed only for the Basic SKU, and all other SKUs require /27 or larger, which is also what a future VPN and ExpressRoute coexistence needs. Second, the Basic SKU lacks BGP, active-active, zone redundancy, IKEv2 and OpenVPN for point-to-site, and RADIUS support, so a VpnGw SKU is needed; the AZ variants are the ones Microsoft recommends for new gateways. Gateway type, VPN type, and NSG options are the distractors: they are real settings, but used here they would either create the wrong kind of gateway or are not applicable to the GatewaySubnet.
Design, implement, and manage a site-to-site VPN connection
Garrison Legal created a site-to-site connection named cn-austin between a VpnGw1 gateway and a local network gateway for its Austin office. The connection status in the portal has remained Connecting for an hour. The on-premises Palo Alto firewall logs show IKE phase 1 completes but phase 2 fails. The virtual network uses 10.20.0.0/16, and the Austin local network gateway address space was entered as 10.20.0.0/24 by mistake; the real Austin LAN is 10.120.0.0/24. The shared key matches on both sides.
What should you do to resolve the issue?
- AReset the virtual network gateway from the portal.A gateway reset reboots the gateway instance and is useful when tunnels stop passing traffic after previously working. It does not fix a configuration error.
- BChange the address space of the local network gateway to 10.120.0.0/24 so it no longer overlaps the virtual network address space.The local network gateway prefix 10.20.0.0/24 overlaps the virtual network's 10.20.0.0/16. Overlapping address spaces prevent the connection from being established; correcting the on-premises prefix to the real LAN range resolves the phase 2 failure.
- CRegenerate the shared key on the connection and update the firewall.The scenario states the shared key already matches, and a key mismatch typically fails at IKE phase 1, not phase 2.
- DUpgrade the gateway to VpnGw2 so that it supports NAT rules.NAT rules are a valid way to handle genuinely overlapping networks, but here the overlap is a typo in the local network gateway, so the straightforward fix is to correct the address space.
Why: When a site-to-site connection stays in Connecting while IKE phase 1 succeeds, the usual suspects are mismatched traffic selectors or overlapping address spaces rather than a key mismatch. Azure will not bring up a tunnel whose remote prefixes overlap the virtual network's own address space, because it would have no way to decide whether a destination is local or remote. The scenario gives the root cause explicitly: the local network gateway was given 10.20.0.0/24, which falls inside the virtual network's 10.20.0.0/16. Correcting the prefix to the real LAN range is the fix. Gateway reset and key regeneration are the standard troubleshooting steps for other symptoms, and NAT is reserved for networks that genuinely overlap.