Access and networks

Global Secure Access (GSA) is the umbrella name for Microsoft Entra Internet Access and Microsoft Entra Private Access, built into the Entra platform. Microsoft pairs these two with Microsoft Defender for Cloud Apps, its cloud access security broker (CASB), to complete its Security Service Edge (SSE) solution. Together, the three converge into one identity-aware control plane covering zero-trust network access (ZTNA), secure web gateway (SWG) and CASB controls.

The pitch is straightforward. Rather than bolting on third-party SSE products that have no awareness of your identity platform, GSA pulls network security into the same control plane as Entra ID, Conditional Access and endpoint management. That trade-off, tighter integration versus best-of-breed flexibility, is the question this post answers.

Azure Virtual Desktop has matured since its initial release. What was once a complex, sprawling service requiring deep Azure networking expertise is now a viable enterprise VDI platform. But maturity in the product doesn't guarantee maturity in implementations. I've seen AVD deployments that replicate every anti-pattern from legacy Citrix environments, and others that embrace cloud-native principles and end up with a platform that costs less to run.

This post distils the architectural principles I apply when designing AVD solutions. It's not a step-by-step deployment guide; Microsoft's documentation covers that adequately. Instead, it focuses on the decisions that determine whether your AVD platform becomes an asset or a liability.

Most homelabs start as a flat network. A NAS, a few Docker containers, some IoT devices, maybe a Proxmox host, all share the same subnet, the same default gateway, the same path to the internet. It works fine until you start asking questions like "why can my smart plug talk to my backup server?" or "can I route BBC iPlayer through a UK exit without affecting everything else on this VLAN?"

This post describes the network as I first built it. By September 2026 it had grown: the router is now a high availability pair, there are more VLANs, the VPN tunnels form a failover pool, and deployment runs per node with health checks and automatic rollback. The routing approach below is unchanged.

These are the questions that turned my flat network into a VLAN-segmented, policy-routed setup running on an OpenWRT instance inside a Proxmox LXC. The result is a system where adding a new domain to a specific VPN tunnel is a one-line YAML change, and the entire network configuration is rendered from templates, with no manual edits on the router, ever.