Use Azure Firewall to manage and secure Windows 365 environments

This article explains how to simplify and protect your Windows 365 environment using Azure Firewall. The example architecture explained here provides low maintenance and automated access to the required endpoints through a direct and optimized connection path. You can use Azure Firewall network rules and fully qualified domain name (FQDN) tags to replicate this architecture example in your environment.

The Windows 365 service requires optimized, non-proxied connectivity to critical service endpoints, many of which reside within Microsoft’s infrastructure. Connecting to these resources using on-premises networks through the internet is inefficient and isn't recommended. Such connections can also be complex to configure and manage.

For example, some Windows 365 customers using the ANC deployment model might have a direct connection back to an on-premises environment that uses ExpressRoute or Site-To-Site VPN. Outbound traffic might be routed using an existing proxy server in the same way as on-premises traffic. This connection strategy isn’t optimized for Windows 365 environments and likely to introduce significant performance impact.

Instead, you can use Azure Firewall with your ANC Windows 365 environments to provide optimized, secure, low maintenance, and automated access.

Required endpoints for Windows 365

Windows 365 requires access to the following endpoints:

1. Windows 365
2. Azure Virtual Desktop
3. Intune

You might also consider access to other Microsoft services (like Office 365) when configuring optimized connectivity from the environment.

FQDN tags for certain services are available for Azure Firewall to help configure and maintain these rules in a simple way and are discussed later in this document.

Example architecture using Azure Firewall and FQDN tags

There are many ways to configure networking within Azure. Here, we use:

• A single VNet with Azure Firewall managing outbound access.
• An ExpressRoute circuit to connect the VNet back to the on-premises environment.

The traffic flow in this diagram:

1. Contoso Corporate Network: This on-premises IP subnet is advertised into the VNet through the ExpressRoute gateway. All traffic to this range (10.0.0.0/8) is sent through the ExpressRoute circuit.
2. All other traffic from the Windows 365 subnet is sent to the Azure firewall through a User Defined Route (UDR) route of 0.0.0.0/0. The next hop IP is set to the Azure Firewall's private IP.
3. The Firewall has application rules (and FQDN tags) and network rules configured for the Windows 365 required endpoints. Traffic that complies with the rules is allowed out. Any other traffic not explicitly permitted is blocked.

Azure Firewall application rules

The environment in the diagram was set up using the following Azure Firewall application rules (applied in callout 3). All traffic not destined for the Contoso on-premises subnet is directed to the firewall. These rules allow the defined traffic to egress to its destination. For more information about deploying Azure Firewall, see Deploy and configure Azure Firewall using the Azure portal.

Azure Firewall can be associated with public IP addresses to provide outbound connectivity to the internet. The first Public IP is selected at random to provide outbound SNAT. The next available public IP will be used after all SNAT ports from the first IP are exhausted. In scenarios that require high throughput, it is recomended to leverage an Azure NAT Gateway. NAT Gateway dynamically scales outbound connectivity and can be integrated with an Azure Firewall. See the integrate NAT Gateway with Azure Firewall tutorial for guidance.

Windows365 tag

The Windows365 tag includes the required Azure Virtual Desktop (AVD) endpoints, except those endpoints with nonstandard ports that need to be entered manually (see the Network rules section).

The Windows365 tag doesn't include Intune. The MicrosoftIntune tag can be used separately.

The Windows365 FQDN tag includes all required endpoints except those endpoints listed as Required in separate rows of this document, which must be configured separately. FQDN tags are different from a service tag. For example, the WindowsVirtualDesktop service tag only includes the IP addresses that *.wvd.microsoft.com resolves to.

Network rules

Azure Firewall doesn’t currently handle nonstandard ports in an FQDN tag. Windows 365 has a few nonstandard port requirements, so the following rules must be added manually as Network Rules in addition to the FQDN tags.

Partner security solution options

Other ways to help protect your Windows 365 environment are partner security solution options that provide automated rulesets to access required endpoints for the Windows 365 service. Such options include:

• Check Point Software Technologies Updatable Objects

Next steps

Learn more about Windows 365 architecture.

To learn more about FQDNS, see FQDN tags overview.

To learn more about service tags, see Virtual network service tags.