Implementing a secure Azure Virtual Desktop environment with a unique cross-region constraint. This project demonstrates Site-to-Site VPN connectivity, VNet Peering for subscription limit workarounds, and secure host pool deployment.

Project Overview

This project addresses a real-world scenario where subscription quota limits in the primary region (UK South) necessitated a split-region architecture.

• UK South (Hub): Contains the VPN Gateway and primary connectivity Hub. Due to subscription restrictions (Compute Quota), VMs cannot be created here.

• UK West (Spoke): Hosts the Azure Virtual Desktop (AVD) infrastructure, including Session Hosts and the Host Pool.

• Connectivity: A Site-to-Site (S2S) VPN connects the on-premise environment to UK South, while VNet Peering extends this connectivity to UK West.

Note

Some IP addresses and specific resource IDs have been redacted or replaced with

generic placeholders for security purposes.

1. Resource Group Strategy

To maintain logical separation and strict region control, two distinct Resource Groups were created.

• rg-network-uksouth: strictly for the VPN Gateway and the Hub VNet.

• rg-avd-ukwest: contains all Compute resources (Session Hosts), Disks, and the AVD Host Pool objects.

2. VNet Configuration

We established two Virtual Networks to handle the split traffic flow.

Hub VNet (UK South)

Address Space: 10.10.0.0/16

• GatewaySubnet: 10.10.1.0/24 (Dedicated for VPN Gateway)

• Default: 10.10.0.0/24 (Reserved for future hub services)

Spoke VNet (UK West)

• Address Space: 10.20.0.0/16

• AVD-Subnet: 10.20.1.0/24 (Where session hosts reside)

3. Deploying VPN Gateway (UK South)

A Virtual Network Gateway (VpnGw1) was deployed into the rg-network-uksouth resource group. This serves as the termination point for the Site-to-Site connection.

Configuration Highlights:

• SKU: VpnGw1

• VPN Type: Route-based

• Local Network Gateway: Configured to point to the on-premise public IP.

4. Configuring VNet Peering

This is the critical configuration that bridges the subscription limitation. Since the VPN exists in UK South, but the VMs are in UK West, we must allow traffic to transit via the peer.

Peering A: UK South -> UK West

In the Hub VNet (UK South), we configured the peering connection to the Spoke.

Critical Setting

Gateway Transit: Enabled. This allows the Spoke VNet to "see" the VPN Gateway in this Hub VNet.

Peering B: UK West -> UK South

In the Spoke VNet (UK West), the return peering was configured.

Critical Setting

Use Remote Gateway: Enabled. This tells the AVD machines in UK West to route internet/intranet traffic via the VPN Gateway in UK South.

5. Creating the AVD Host Pool

With the network plumbing in place, the AVD Host Pool was deployed in UK West.

• Host Pool Name: hp-avd-corporate-01

• Pool Type: Pooled (Depth-first load balancing)

• Session Hosts: 2x Standard D2s v3 instances.

• Image: Windows 11 Enterprise Multi-session + Microsoft 365 Apps.

6. Workspace & App Groups

A Desktop Application Group (DAG) was created to provide users with a full desktop experience.

• Workspace: ws-corporate-remote

• User Assignment: Assigned to the AVD-Users Entra ID group.

7. Network Security Groups (NSG)

An NSG was applied to the AVD-Subnet in UK West.

Unlike standard RDP (port 3389), which is blocked for security reasons, AVD uses reverse-connect technology. However, strict outbound rules were applied to ensure that session hosts communicate only with the required Azure endpoints and the internal network via the peering link.

8. Validation & Testing

Connectivity Test:
Connected via the Remote Desktop Client. Verified that the session landed on a host in UK West (10.20.1.x).

Latency Check:
Performed a ping test from the AVD Session Host (UK West) to the On-Premise Gateway IP (via UK South). Latency remains low despite the cross-region hop.

Pinging 192.168.1.10 with 32 bytes of data: Reply from 192.168.1.10: bytes=32 time=24ms TTL=126 Reply from 192.168.1.10: bytes=32 time=25ms TTL=126