Tag: Azure Firewall

To increase security on your Windows 365 hosts you might want to put your Windows 365 clients behind a firewall. There are several options but one of the options that you have is to use the Azure Firewall. The Azure firewall is a powerful SaaS solution of Microsoft, but also an expensive one. Recently Microsoft announced the preview of a new Firewall sku, the Azure Firewall basic. The solution is more aimed to midsized companies. It lacks the advanced features of the Standard and premium Firewall but is does provide you with enough features to better secure your environment. Besides it also in a lower price range so it should be more attractive to midsized companies.

• Azure Firewall Premium is recommended to secure highly sensitive applications (such as payment processing). It supports advanced threat protection capabilities like malware and TLS inspection.
• Azure Firewall Standard is recommended for customers looking for Layer 3–Layer 7 firewall and needs auto-scaling to handle peak traffic periods of up to 30 Gbps. It supports enterprise features like threat intelligence, DNS proxy, custom DNS, and web categories.
• Azure Firewall Basic is recommended for SMB customers with throughput needs of less than 250 Mbps.

In this blog I will show you the basics of setting up the new Azure Firewall Basic sku in combination with Windows 365 Enterprise. Unfortunately, Windows 365 Business is not suitable for Azure Firewall because you will need to redirect the traffic through the Azure Firewall. With Windows 365 business you do not have any control over the networking, since it’s managed by Microsoft. The article builds upon the blog series of Windows 365, so if you need information on how to set up Windows 365, I recommend reading through those articles first.

Azure Firewall

From a networking perspective an Azure Basic Firewall needs 3 subnets within a vnet. It needs a management subnet, Azure firewall subnet and a subnet workload subnet. The management and the Azure firewall subnet need specific names otherwise you won’t be able to deploy the Firewall. So, in your vnet you need to create 3 subnets:

1. Subnet : AzureFirewallSubnet, in my case I am using a 10.3.4.0/24 subnet
2. Subnet: AzureFirewallManagementSubnet, in my case I am using a 10.3.2.0/26 subnet
3. Subnet: Workload subnet 10.3.5.0/24

In production environments it is considered better to create a hub spoke network topology where you Firewall is in a separate Vnet than your workload. You connect your Vnets via network peering. The functionality doesn’t change is you have 1 or multiple Vnets.

Now you have set up the subnets in your Vnet its time to deploy the Azure Firewall. Sign into the Azure Portal and search for Firewalls and select Create.

To set up Azure Firewall sign into the Azure Portal and search for Firewalls and select Create.

• Subscription. Where the Azure firewall will be deployed. This needs to be the same subscription as where your vnet is created.
• Resource Group. Select or create a resource group to deploy the Firewall
• Name. Give you Firewall a name.
• Region. Select the region for your Firewall. This also needs to be the same as the region of you vnet.
• Availability zone. If the region supports availability zones you can select a zone or leave it to none
• Firewall SKU. Select Basic, or a higher sku.
• Firewall management. Is greyed out is you choose Basic
• Firewall Policy. Create a new policy. This also needs to be deployed in the same region.
• Virtual network. Choose a virtual network. Pick the network where you want to deploy the Firewall. If you did not create the necessary subnets, you will get an error.
• Public IP address. Create a new Public IP address
• Management public IP address. The basic sku also needs a public management IP. You won’t be able to connect to this IP, but it is necessary for Microsoft to manage your Firewall.

Choose review and create. The deployment will start and can take up to 30 min, so go grab yourself a cup of coffee.

While waiting for the deployment we can already create a route table. With a route table we can redirect network traffic within Azure. Otherwise the Windows 365 clients network traffic will leave Azure without passing through the Firewall.

In the Azure portal search for Route Table and create a new Route table

• Subscription. Same subscription as the vnet to which you want to connect to route table
• Resource Group. A resource group of your choosing.
• Region. Select the same region of your vnet
• Name. A clear name, such as route-to-fw
• Propagate gateway routes. Depending on your config, but you can leave it on yes.

When your route table has been created go to the route table and select Routes and select Add

Add the following to the new route:

• Route name. A clear descriptive name
• Address prefix destination. Choose IP Addresses
• Destination IP addresses/CIDR ranges. Enter 0.0.0.0/0 this way all traffic will be forwared.
• Next hop. Choose Virtual Applicance
• Next hop address. This is the IP of the Azure firewall. This is the first available IP in the AzureFirewallSubnet. In my case the range is 10.3.4.0/24 so the first available IP will be 10.2.4.4. You can also check this by going to the Firewall.

The next step is to associate the route table to a subnet, this way all devices in that subnet will use the route defined in the table. Be aware that associating the route table will result in disconnecting your Windows 365 user sessions. You need to configure the firewall as described in the next section. To associate the route table, select subnets and choose associate. You can there select the Vnet and the subnet of where your workload is deployed.

Configuring Azure Firewall

You now have a firewall and you route all the Windows 365 traffic through that firewall. This also means that the traffic that is required for users to connect to the Windows 365 machine is also blocked. So if a user tries to connect to its machine it will get the following message. So if you are deploying the firewall to a production environment wait with applying the route table otherwise your users won’t be able to connect to their machines.

You will need to make some firewall rules. Unfortunately, there is no official Microsoft documentation of which firewall rules you need to create in order for Windows 365 to work (At least I haven’t found it). There is however documentation available on firewall rules for Azure Virtual Desktop. The two basically share the same connection method so that should give us a good starting point. You can find the AVD documentation here https://learn.microsoft.com/en-us/azure/firewall/protect-azure-virtual-desktop?tabs=azure#create-network-rules . In the Azure Portal search for Firewall Policies. A policy was created when you deployed the Firewall so there should be at least one policy there. Open that policy and let’s start with Application rules. In the Application rules you have to have at least one rule collection. A rule collection is a logical set of rules that allow or deny traffic. Select Add a rule collection. Give the collection a name, for example Windows365Applicationrules. For type use Application and give the collection a priority. The priority determines the order of the collection to be deployed. If you don’t know how many rule collections you are going to have pick a number witch gives you flexibility in deploying higher of low collections. So don’t start with 100 since that is the highest priority. For Rule collection group you can leave the DefaultApplicationRuleCollectionGroup for now. Next you can define the rules.

Enter the following rules. The source is my subnet range where I deployed my Windows 365 machines.

Name	Source Type	Source	Protocol	Destination Type	Destination
Login Microsoft Online	IP Address	10.2.2.0/24	Https:443	FQDN	login.microsoftonline.com
AVD	IP Address	10.2.2.0/24	Https:443	FQDN	*.wvd.microsoft.com
W365 Monitor	IP Address	10.2.2.0/24	Https:443	FQDN	*.prod.warm.ingest.monitor.core.windows.net
catalogartifact	IP Address	10.2.2.0/24	Https:443	FQDN	catalogartifact.azureedge.net
W365 Monitoring	IP Address	10.2.2.0/24	Https:443	FQDN	gcs.prod.monitoring.core.windows.net
W365 blob storage	IP Address	10.2.2.0/24	Https:443	FQDN	mrsglobalsteus2prod.blob.core.windows.net
Microsoft	IP Address	10.2.2.0/24	http:80, Https:443	FQDN	www.microsoft.com

Next go to Network rules. Here also select Add a rule collection. Give the collection a name, select for rule collection type Network. Give a priority and for Rule collection action select Allow. For rule collection rule group select DefaultNetworkRuleCollectionGroup. Enter the following rules:

Name	Source type	Source	Protocol	Destination Ports	Destination Type	Destination
Azure Services	IP Address	10.2.2.0/24	TCP	80	IP Address	169.254.169.254, 168.63.129.16
AVD Services	IP Address	10.2.2.0/24	TCP	443	Service tags	Select WindowsVirtualDesktop, AzureFrontDoor.Frontend, AzureMonitor
DNS	IP Address	10.2.2.0/24	TCP, UDP	53	IP Address	*
azkms.core.windows.net	IP Address	10.2.2.0/24	TCP	1688	IP Address	20.118.99.224, 40.83.235.53
kms.core.windows.net	IP Address	10.2.2.0/24	TCP	1688	IP Address	23.102.135.246
	IP Address	10.2.2.0/24	TCP
	IP Address	10.2.2.0/24	TCP

After the policies are applied (and you have applied the route table) you should be able to sign in to your Windows 365 environment. However, browsing through the firewall logging ( you can enable this in the diagnostic settings of your firewall) I was still getting a lot of deny hits for Microsoft services. Even though I was able to connect to the Windows 365 machine, Windows 365 is depending on more services. For example it also communicates to Intune. So I have also added the following application rules:

Name	Source Type	Source	Protocol	Destination Type	Destination
servicebus.windows.net	IP Address	10.2.2.0/24	Https:443	FQDN	*.servicebus.windows.net
self.events.data.microsoft.com	IP Address	10.2.2.0/24	Https:443	FQDN	self.events.data.microsoft.com
.azure-devices.net	IP Address	10.2.2.0/24	Https:443	FQDN	*.azure-devices.net

The Firewall logging seemed a lot better after adding the extra rules. You now have configured the bare minimum for allowing the Windows 365 services to you hosts. But that doesn’t mean you are ready. Users are still not able to browse the internet of access any of the other Microsoft 365 services. So, you will need to configure additional rules. We did create a rule to browse to www.microsoft.com, but if you want to go to www.google.com your connection will be blocked. The next step would be op further configure the firewall rules depending on the needs of your organization.

I hope this blog was helpful, if you have any questions or some parts needs additional clarification please let me know in the comments.