Using Azure Firewall to secure RDS and RDmi on Azure

Recently Microsoft released the public preview version of Azure Firewall. Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. It is a stateful firewall as a service with built-in high availability and unrestricted cloud scalability. Using Azure Firewall, you can create, enforce, and log application and network connectivity policies across subscriptions and virtual networks. It also integrates with the Azure platform, portal UI and services.

How does the Azure Firewall relate to Network Security Groups (NSG)? NSG and Azure Firewall are complementary providing better in-depth network security. An NSG provides distributed network layer traffic filtering to limit traffic to resources within virtual networks. Azure Firewall is a fully stateful centralized network firewall as-a-service, providing network and application level protection across virtual networks.

This public preview supports the following features

- Outbound FQDN filtering

- Network traffic filtering rules

- Outbound SNAT support

- Azure Monitor logging

Time to put this Preview Release to the test! In this blog post I’m test-driving Azure Firewall Preview by testing a specific Use Case, to secure outbound traffic from a Remote Desktop Services environment. This blog post describes how to leverage Azure Firewall to secure Remote Desktop Services sessions running on Azure. The setup in this blog post based on RDS on Azure IaaS but is also applicable to the upcoming Remote Desktop modern infrastructure (RDmi). In fact, the deployment is exactly the same since both RDS on IaaS as well as RDmi use RD Session Hosts running in your Azure Subscription based on IaaS.

The first step is to enable your Azure Subscription to use the Public Preview of Azure Firewall.
Logon to Azure RM using PowerShell and run the following two commands:

Register-AzureRmProviderFeature -FeatureName AllowRegionalGatewayManagerForSecureGateway -ProviderNamespace Microsoft.Network

Register-AzureRmProviderFeature -FeatureName AllowAzureFirewall -ProviderNamespace Microsoft.Network

The registration can take ~30 minutes to complete, but in my case, it took ~10 minutes. You can check the status of the registration by running these two commands. Once completed it should state registered.

Get-AzureRmProviderFeature -FeatureName AllowRegionalGatewayManagerForSecureGateway -ProviderNamespace Microsoft.Network

Get-AzureRmProviderFeature -FeatureName AllowAzureFirewall -ProviderNamespace Microsoft.Network

Once the status shows registered, run the following command to finish the registration

Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Network

Before we can create the Azure Firewall, a new subnet must be created. For the purpose of this lab environment I’m creating a new subnet within my existing Vnet where a separate subnet with my RDS deployment already resides. For production deployments, a hub and spoke model is recommended, where the firewall is in its own VNet, and workload servers are in peered VNets.

The screenshot below shows the creation of the Subnet for the Azure Firewall. Note that the subnet name must be names AzureFirewallSubnet otherwise you will not be able to deploy the Azure Firewall.

Next, we can go ahead and create the Azure Firewall, which is available from the Azure Marketplace.

We need to specify the parameters. Make sure you select the existing Vnet where as part of a previous step, the subnet called AzureFirewallSubnet was created. Also, I noticed that the Azure Firewall needs to be created in the same ResourceGroup as the existing Vnet.

You can of course also use a JSON template to create the Azure Firewall. Below is code snippet of how to create the Azure Firewall using JSON.

After the creation of the firewall, we need to create a new route table to make sure outbound traffic from the Subnet will go through the Azure Firewall.

Next, we associate the Route Table to subnet where our destination servers are located. In this example I selected the Subnet where the RD Session Host servers are running.

And finally, we need to add the route. For this example, we set the prefix to 0.0.0.0/24 and point it to the private IP-address of the Azure Firewall. This basically means that all outgoing traffic will flow through the Azure Firewall. Note that although the Azure Firewall is more of a managed service, we need to select virtual appliance here.

Now that the Azure Firewall and Route are in place, we can start defining rules in the firewall. For this use case we want to control traffic from the RD Session Host to the internet. For this example let’s say we are publishing a browser as a RemoteApp on RDS and want to control, basically whitelist, the URL’s the user can browse to, ultimately creating a “secure browser”.

In order to do so, we create the rule below. This basically says, anything from within the Subnet that we want to control is allowed http and https access to *github.com. Anything else will be rejected.

In this environment the RD Session Host server is a member of an Active Directory domain, where the Domain Servers are within a subnet within the same vnet. In scenarios where you are using an external DNS service, you also need to create a rule to allow DNS services. This can be done using a Network. Rule, the screenshot below shows an example of what that could look like.

And that’s it. We have just created a basic secure browser environment. Let’s logon to RDS as an end user and take a look at some of the results.

In this scenario, the RD Session Host server that is part of an RDS on Azure IaaS deployment is located on the Subnet with the Route and thus the Firewall in place.

We log on to Remote Desktop Services web client (HTML5) (which recently went to Preview 0.9.0 release)

And we open the Github published application.

We now running a secure browser with github.com from within a locally running chrome. Isn’t that what you’ve always wanted to do? Run IE inside Chrome? :) This is just an example of course, we could have also used mstsc or RD Web Access as well.

But anyway, let’s put the Azure Firewall to the test and browse to a different URL, amazon.com. We can now see the Azure Firewall at work, blocking that traffic based on the rules we defined.

This completed my first test. Obviously, this is just the first preview release of the Azure Firewall and we’ve only looked at a specific feature (Outbound FQDN filtering) to get some hands-on experience. It is however great to see Azure Networking evolving, and I’m looking forward to future features!