3.4 Azure Extended Network, Always On VPN & Azure Network Adapter
Key Takeaways
- Extended network for Azure stretches an on-premises subnet into Azure over a bidirectional VXLAN tunnel between a pair of Windows Server virtual appliances, one on-premises and one in Azure, so migrated VMs keep their original private IP addresses.
- Each subnet you extend needs its own appliance pair, and the extension rides on an existing site-to-site VPN or ExpressRoute connection rather than replacing it.
- Microsoft's own guidance is to treat subnet extension as an intermediate step for machines that genuinely cannot be re-addressed, and to renumber and migrate properly wherever possible.
- Always On VPN is a Windows client-side remote access technology; the Azure-side requirement is a route-based VPN gateway configured for point-to-site with IKEv2 or SSTP and certificate or RADIUS authentication, since Microsoft Entra ID authentication is OpenVPN-only.
- Azure Network Adapter is a Windows Admin Center feature that creates a point-to-site connection from a single Windows Server to an Azure VNet, so the Azure prerequisites are a VNet with a GatewaySubnet and a route-based P2S-enabled VPN gateway.
Azure Extended Network, Always On VPN & Azure Network Adapter
The AZ-700 connectivity objectives include three items that no amount of general VPN knowledge will cover, because they are named features with specific prerequisites: Implement Azure Extended Network, Specify Azure requirements for Always On VPN, and Specify Azure requirements for Azure Network Adapter. Each appears as a single bullet in the official outline, and each is worth knowing precisely because the wrong answers are all plausible.
1. Azure Extended Network (Subnet Extension)
The problem it solves
Some workloads cannot be re-addressed. A legacy application may hard-code IP addresses in configuration files, a licence may be bound to an address, or a compliance rule may pin a service to a specific range. Normally Azure solves the IP-preservation problem by letting you choose any address space for a VNet — but that only works if the whole subnet moves. Extended network for Azure handles the harder case: half the subnet stays on-premises and half moves to Azure, and both halves must keep their original addresses and behave as though they are on the same broadcast domain.
How it works
| Component | Detail |
|---|---|
| Overlay technology | A bidirectional VXLAN tunnel carries the stretched Layer 2 segment over a Layer 3 network |
| Appliances | A pair of Windows Server virtual machines acting as virtual appliances — one running on-premises, one running in Azure — each also connected to the subnet being extended |
| Scale unit | One appliance pair per extended subnet. Extending three subnets means three pairs |
| Underlay | The tunnel runs over existing hybrid connectivity — a site-to-site VPN or an ExpressRoute circuit |
| Management | Configured through Windows Admin Center |
| Addressing | The same subnet CIDR exists on both sides; individual addresses are assigned to VMs in Azure and on-premises without overlap |
Packet flow
When an Azure VM sends a packet to an on-premises VM in the stretched subnet, the Azure-side appliance captures the packet, encapsulates it, and sends it across the VPN or ExpressRoute link. The on-premises appliance decapsulates it and forwards it to the recipient. Return traffic follows the mirror path. The appliances learn which addresses sit behind each other; larger designs add a mapping service that resolves an IP address to the appliance fronting it.
[!CAUTION] Microsoft's own guidance is not to do this if you can avoid it. The documentation states plainly that you should not extend subnets unless it is necessary, that extension should be an intermediate step, and that you should renumber applications over time. On the exam, "extend the subnet" is the correct answer only when the scenario states that IP addresses cannot change and that the workload is split between on-premises and Azure. If the scenario merely wants hybrid connectivity, the answer is site-to-site VPN, ExpressRoute, or Virtual WAN.
When it is the right answer
| Scenario cue | Right answer |
|---|---|
| "Phased migration; some app servers move now, the database stays on-premises, and neither can be re-addressed" | Extended network for Azure |
| "We want on-premises and Azure to route to each other" | Site-to-site VPN or ExpressRoute |
| "We want the same address space in two Azure regions" | This is an overlap problem — re-address, or use NAT; peering rejects overlapping spaces |
| "A latency-sensitive component must stay in the datacenter but shares a subnet with migrated servers" | Extended network for Azure |
2. Always On VPN — Azure Requirements
Always On VPN is a Windows client remote-access technology that replaced DirectAccess. The client automatically establishes a VPN tunnel whenever the device has internet connectivity, using device tunnels (before user sign-in, for domain services) and user tunnels (after sign-in, for user resources). The AZ-700 objective is narrowly scoped: specify the Azure requirements, not configure the Windows client.
| Azure-side requirement | Why |
|---|---|
| A route-based VPN gateway | Point-to-site configurations require the route-based VPN type; policy-based gateways cannot serve P2S at all |
| Point-to-site configuration enabled on the gateway, with a client address pool | Always On VPN clients connect as P2S clients |
| A tunnel type the Windows native client supports — IKEv2 or SSTP | The Windows built-in VPN client, which Always On VPN profiles drive, uses the native IKEv2/SSTP stack |
| Certificate authentication or RADIUS authentication | These are the authentication types compatible with IKEv2 and SSTP |
| A gateway SKU that supports P2S at the required scale | The Basic SKU does not support IKEv2, IPv6, or RADIUS authentication |
[!IMPORTANT] Microsoft Entra ID authentication is not an option for Always On VPN. Entra ID authentication for Azure point-to-site is supported only for the OpenVPN protocol, and it requires the Azure VPN Client application. Always On VPN drives the Windows native client over IKEv2/SSTP, so an exam option that pairs Always On VPN with Entra ID authentication is incorrect.
The tunnel-type / authentication compatibility matrix
This table decides a large share of point-to-site questions.
| Tunnel type | Compatible authentication mechanisms |
|---|---|
| OpenVPN | Any subset of Microsoft Entra ID, RADIUS, and Azure certificate |
| SSTP | RADIUS or Azure certificate |
| IKEv2 | RADIUS or Azure certificate |
| IKEv2 and OpenVPN | RADIUS / Azure certificate / Entra ID + RADIUS / Entra ID + Azure certificate |
| IKEv2 and SSTP | RADIUS or Azure certificate |
If you select multiple authentication types, Azure applies each one only to the tunnel types that support it — selecting "IKEv2 and OpenVPN" with "Entra ID and RADIUS" means Entra ID works over OpenVPN only.
3. Azure Network Adapter — Azure Requirements
Azure Network Adapter is a Windows Admin Center feature that connects a single Windows Server — on-premises or anywhere else — to an Azure virtual network in a few clicks. Windows Admin Center provisions the point-to-site plumbing on your behalf, which is why the objective is again about Azure prerequisites rather than configuration steps.
| Azure-side requirement | Detail |
|---|---|
| A target virtual network | The VNet the server will join logically |
A GatewaySubnet | Required before any virtual network gateway can be created; /27 or larger is the standard recommendation |
| A route-based virtual network gateway with point-to-site enabled | Windows Admin Center will create one if it does not exist, which is why gateway provisioning time dominates the operation |
| A point-to-site client address pool | Supplies the address the server's virtual adapter receives |
| Certificate-based authentication | Windows Admin Center generates and installs the required certificates for the connection |
| Windows Admin Center registered with Azure | The Azure integration must be configured before the Azure Network Adapter option appears |
Choosing between the three
| Requirement | Feature |
|---|---|
| One Windows Server needs private connectivity to a VNet, configured from Windows Admin Center | Azure Network Adapter |
| A fleet of domain-joined Windows laptops needs seamless, automatic connectivity to Azure resources | Always On VPN over a route-based P2S gateway with IKEv2/SSTP |
| A production subnet must exist simultaneously on-premises and in Azure with unchanged IP addresses | Extended network for Azure |
| A branch office site needs permanent connectivity to a VNet | Site-to-site VPN or ExpressRoute |
A manufacturer is migrating a plant-floor application to Azure. The application servers move to Azure but the historian database must remain in the datacenter for latency reasons, and neither tier can have its IP address changed because addresses are embedded in PLC configuration files. Both tiers currently share 10.40.12.0/24. Which Azure approach meets the requirement?
A security architect is designing Always On VPN for 4,000 domain-joined Windows laptops connecting into an Azure hub virtual network. They want Microsoft Entra ID authentication with Conditional Access. Which statement correctly describes the Azure-side constraint they will hit?