4 of the 9 questions we have for this objective, shown with the answer and the reasoning.
Design, implement, and manage a point-to-site VPN connection
Fallbrook Dairy has a single Windows Server 2022 file server in a small warehouse with no VPN appliance and no plans to buy one. The server must reach a virtual network named vnet-erp so that it can synchronize data with an Azure SQL Managed Instance that has only a private address. The server is already managed through Windows Admin Center, which is registered with the company's Azure subscription. The solution must minimize administrative effort.
What should you use?
- AAzure Network Adapter from Windows Admin Center, letting it create a point-to-site VPN gateway in vnet-erp and connect the server as a client.Azure Network Adapter is a Windows Admin Center extension that creates (or reuses) a point-to-site VPN gateway in the target virtual network and configures the server as a VPN client in a single wizard.
- BA site-to-site VPN with a local network gateway representing the warehouse router.A site-to-site VPN requires a VPN-capable on-premises device, which the warehouse does not have and will not purchase.
- CAzure Extended Network to stretch the warehouse subnet into vnet-erp.Azure Extended Network needs an existing site-to-site VPN or ExpressRoute connection plus two appliances; it is for keeping IP addresses during migration, not for connecting a lone server.
- DAn ExpressRoute Local circuit ordered through a connectivity provider.ExpressRoute requires a provider circuit and dedicated hardware, which is far more cost and effort than a single server needs.
Why: Azure Network Adapter is a feature of Windows Admin Center that connects an individual Windows Server to an Azure virtual network over a point-to-site VPN without any on-premises VPN device. Its requirements are a Windows Admin Center instance registered with Azure, a target virtual network and subscription, and either an existing point-to-site-capable VPN gateway or permission to let the wizard create one along with the GatewaySubnet, certificates, and client configuration. The deciding constraints are the absence of a VPN appliance and the need for minimal administrative effort, which rule out site-to-site, Extended Network, and ExpressRoute. Note that the wizard creates a VpnGw SKU gateway, which incurs hourly charges even for one server.
Design, implement, and manage a point-to-site VPN connection
Ellery Pharmaceuticals must authenticate point-to-site users against its on-premises Active Directory by using an existing Network Policy Server (NPS) at 10.200.5.20 in the Raleigh data center. The Azure gateway is a route-based VpnGw1 in a virtual network named vnet-research that already has a working site-to-site VPN to Raleigh. Users will connect with IKEv2 from Windows and macOS devices. The connection to the Azure gateway must keep working if the primary NPS server is offline.
Which three actions should you perform? Each correct answer presents part of the solution.
- AIn the point-to-site configuration, select RADIUS authentication and enter the primary server IP address 10.200.5.20 and its shared secret.RADIUS authentication on the gateway requires the RADIUS server's IP address and the shared secret so the gateway can forward authentication requests.
- BAdd a second RADIUS server IP address and secret in the point-to-site configuration for a standby NPS server.Azure VPN Gateway supports a primary and a secondary RADIUS server; configuring both provides authentication redundancy if the primary NPS is offline.
- CEnsure the RADIUS server is reachable from the gateway through the existing site-to-site VPN and that the NPS firewall allows UDP 1812 from the gateway's instance addresses in the GatewaySubnet.The gateway reaches an on-premises RADIUS server through the site-to-site or ExpressRoute connection, so the server must be routable and must accept RADIUS traffic from the gateway's private IP addresses.
- DChange the gateway SKU to Basic to reduce cost, because RADIUS authentication does not require a VpnGw SKU.The Basic SKU does not support RADIUS authentication or IKEv2 point-to-site connections, so this change would break the design.
- ESwitch the tunnel type to OpenVPN, because RADIUS authentication is supported only with OpenVPN.RADIUS authentication works with IKEv2, SSTP, and OpenVPN tunnel types; it is Microsoft Entra ID authentication that is limited to OpenVPN.
Why: RADIUS authentication lets the VPN gateway delegate credential checks to an existing identity infrastructure such as NPS in front of Active Directory. On the gateway you specify the RADIUS server IP address and shared secret, and optionally a second server for redundancy, which the scenario requires because the primary might be offline. The server can live in the virtual network or on-premises; in the latter case the gateway must be able to reach it over a site-to-site VPN or ExpressRoute connection, and the server must accept traffic from the gateway's private addresses in the GatewaySubnet. RADIUS requires a VpnGw SKU (not Basic) and is independent of tunnel type, so the Basic and OpenVPN-only options are traps.
Design, implement, and manage a point-to-site VPN connection
Ashbury Analytics uses a point-to-site VPN with Azure certificate authentication and the IKEv2 tunnel type. The point-to-site configuration on the gateway lists one trusted root certificate, Ashbury Root CA 2019. Last month the PKI team introduced a new root, Ashbury Root CA 2025, and a new analyst received a client certificate that chains to it. The analyst's connection fails with a certificate authentication error, while analysts whose certificates chain to Ashbury Root CA 2019 connect without problems.
What should you do to resolve the issue?
- AExport the public key (Base-64 encoded .cer) of Ashbury Root CA 2025 and add it as an additional trusted root certificate in the gateway's point-to-site configuration.The gateway validates each client certificate against the trusted root certificates uploaded to its point-to-site configuration. A certificate that chains to a root the gateway does not know fails validation, and adding the new root's public key fixes it without affecting existing users.
- BSwitch the gateway authentication type to RADIUS so the certificate chain is validated by the NPS server instead.Changing the authentication method for all users to fix one trust chain is disproportionate and would require new client profiles and an NPS deployment.
- CAdd the analyst's client certificate thumbprint to the revoked certificates list on the gateway.The revoked certificates list blocks specific client certificates; adding the thumbprint would prevent the analyst from connecting rather than fix the trust chain.
- DChange the tunnel type to SSTP, because IKEv2 accepts client certificates only from the first root certificate uploaded to the gateway.IKEv2 and SSTP use the same list of trusted root certificates, and a gateway can trust multiple roots; the tunnel type is not the cause.
Why: In Azure certificate authentication, you upload the public key of one or more trusted root certificates (up to 20) to the point-to-site configuration, and each client presents a certificate that must chain to one of them. When the PKI introduces a new root CA, the gateway must be told to trust it, otherwise clients whose certificates chain to that root fail authentication. The deciding clue is that only certificates from the new root fail while every other user connects. Adding the new root alongside the old one fixes the analyst and lets you migrate users gradually; the other options either block the user, change unrelated settings, or rebuild authentication unnecessarily.
Design, implement, and manage a point-to-site VPN connection
Dunmore Engineering issues domain-joined Windows 11 Enterprise laptops that must reach on-premises domain controllers and Azure file servers before any user signs in, so that Group Policy and password changes work from anywhere. The company plans an Always On VPN device tunnel to a VpnGw2 gateway in a virtual network connected to the data center. Security has asked which gateway settings are mandatory to support the device tunnel.
Which point-to-site configuration should you specify on the gateway?
- ATunnel type OpenVPN with Microsoft Entra ID authentication.An Always On VPN device tunnel authenticates the machine before any user is present, so user-based Microsoft Entra ID sign-in cannot be used, and the device tunnel requires IKEv2 rather than OpenVPN.
- BTunnel type IKEv2 with Azure certificate authentication using machine certificates issued by the corporate CA.The Always On VPN device tunnel requires the IKEv2 tunnel type and machine certificate authentication, and the gateway must trust the root of the CA that issues the device certificates.
- CTunnel type SSTP with RADIUS authentication against an on-premises NPS server.SSTP cannot be used for a device tunnel, and RADIUS username/password authentication requires a user, which is not available before sign-in.
- DTunnel type IKEv2 with RADIUS authentication using EAP-MSCHAPv2.EAP-MSCHAPv2 is a user credential method; a device tunnel is established by the machine using certificate authentication, not user credentials.
Why: Always On VPN offers two tunnel types: a device tunnel that connects when the machine starts, before user sign-in, and a user tunnel that connects after sign-in. The device tunnel is supported only on domain-joined Windows 10 or 11 Enterprise or Education devices, and it requires the IKEv2 protocol with machine certificate authentication, so the Azure gateway must be configured with IKEv2 and Azure certificate authentication, with the issuing CA's root uploaded as a trusted root. The deciding constraint is pre-logon reachability for Group Policy and domain controllers, which only a device tunnel provides. A user tunnel can use IKEv2 or SSTP with user certificates, but any method that depends on a signed-in user cannot connect before sign-in.