Using Azure Firewall as a Network Virtual Appliance (NVA)

[DJBartles]

Purpose:

The purpose of this post is to demonstrate using Azure Firewall to control network traffic routing between Hub and Spoke networks in a Hub and Spoke Network Architecture.  The Hub & Spoke Azure Architecture has become a common network topology for Azure deployments.  The Cloud Adoption Framework describes this architecture in great depth.  As with anything in cloud computing, there are several functional options to accomplish just about any goal but in this writing we will be focusing on how you can use the Azure Firewall as your routing device, also known as a Network Virtual Appliance, or NVA.  We will walk through the process of building a Hub and Spoke Network Architecture that includes Spoke-to-Spoke routing.  The key components that we will use to build this architecture are Azure Firewall, Route Tables (or UDR’s), and Virtual Network Peering (Vnet Peering).

This architecture can be used in many situations.  A common scenario would be an enterprise network that may have resources that run between two or more Virtual Networks.  In this scenario, there may be a web front-end, an application and a data tier that may need to communicate between with one another across those virtual networks.  If these tiers are in different Virtual Networks, then routing will need to occur in order for network traffic to be able to cross those Virtual Network boundaries (e.g., data tier communicating with app or web tier).  This writing will describe how to setup a solution to accomplish these goals.

Assumptions: Knowledge of creating Azure virtual machines and Azure virtual networks, as well as user-defined routes and peering is assumed.  The firewall rules described in this writing will allow all outbound traffic from resources in Spoke1 and Spoke2.  This configuration is for demonstration purposes only.  Depending on the security posture needed for a production environment, this configuration would likely be more tightly controlled from the firewall.  For our demonstration purposes, this configuration is being used for functionality and convenience.

Here are the required items to deploy this solution:

Resource Group:

• Just one named AzureFW

Virtual Networks:

• Hub
  • Address Space: 10.200.0.0/16
  • Subnet named AzureFirewallSubnet : 10.200.1.0/24
  • Subnet named hub-subnet: 10.200.0.0/24
• Spoke1
  • Address Space: 10.201.0.0/16
  • Subnet named spoke1-subnet: 10.201.0.0/24
• Spoke2
  • Address Space: 10.202.0.0/16
  • Subnet named spoke2-subnet: 10.202.0.0/24

Virtual Network Peering:

• Hub peers with Spoke1 (bi-directional)
  • Forwarding must be enabled
• Hub peers with Spoke2 (bi-directional)
  • Forwarding must be enabled

Route Tables: 

• RT-Spoke1
  • Attached to default subnet in Spoke1-Vnet.
  • Routes:
    • 0.0.0.0/0: Next Hop: <<Azure Firewall Private IP>>
  • RT-Spoke2
    • Attached to default subnet in Spoke2-Vnet.
    • Routes:
      • 0.0.0.0/0: Next Hop: <<Azure Firewall Private IP>>

Azure Firewall:

• NAT Rule Collection:
  • Rule 1, priority 1000 allow:
    • Spoke1-RDP, allow traffic from any source to destination firewall public IP address on port 3389 which is translated to Spoke1 VM private IP address on port 3389
  • Network Rule Collections:
    • Rule 1, priority 2000, allow:
      • Spoke1-Outbound, allow all traffic from source 10.201.0.0/24 to any destination, all ports
      • Spoke2-Outbound, allow all traffic from source 10.202.0.0/24 to any destination, all ports

Virtual Machines:

• (3) Windows VM’s
  • (1) VM in Hub VNet, hub-subnet
  • (1) VM in Spoke1 VNet, spoke1-subnet
  • (1) VM in Spoke2 Vnet, spoke2-subnet

Step-by-step:

1. Create the three virtual networks as outlined above:  one hub and two spokes.  Also create two Azure Virtual Machines of any size and without public IP addresses and place one on each spoke virtual network. 

2. Peer Spoke1 with the hub and peer Spoke2 with the hub.  Do NOT peer Spoke1 and Spoke2.  Enable the following settings on each peering:

Note: If you have a VPN gateway on the hub network and wish to use it to connect to an on-premise network, select “Use this virtual network’s gateway” on the hub peering. 

 When complete, the peering should indicate Connected:

3. Create an Azure Firewall resource and place it in the hub virtual network.  Assign an existing public IP address or add a new one.  Since we are using the Azure Firewall as the virtual appliance, there is no need to enable Forced Tunneling to be able to send traffic to a secondary virtual appliance. 

Azure Portal -> search for and click Firewalls -> click Add:

When the firewall resource is created, access it (Azure Portal -> search for and click Firewalls -> click the newly created firewall) and click Overview.  Make note of the firewall’s public and private IP addresses as starred below:

1. Create a user-defined route (UDR) route for Spoke1.  The route will point all traffic (0.0.0.0/0) to the Azure Firewall private IP address gathered in step 3.  To complete this step, you will need to create a Route Table with the following settings:

• Routes
  • Address Prefix: 0.0.0.0/0
  • Next Hop Type: Virtual Appliance
  • Next Hop Address: <<Private IP of Azure Firewall>>
• Subnets
  • Associate to the subnet for Spoke1, in our example 10.201.0.0/24

The completed routes should look like this:

5. Create a similar route for Spoke2 and associate it to that subnet.  It should look like this:

• Routes
  • Address Prefix: 0.0.0.0/0
  • Next Hop Type: Virtual Appliance
  • Next Hop Address: <<Private IP of Azure Firewall>>
• Subnets
  • Associate to the subnet for Spoke2, in our example 10.202.0.0/24.

6. Within Azure Firewall, create a NAT rule collection for the Spoke1 VM with priority 1000.  This will allow inbound RDP to the chosen VM.  Note the Destination Address in the rule is the firewall’s public IP address gathered in step 3 and the Translated address is the Spoke1 VM private IP address.  Use port 3389 for both the Destination and Translated ports.  This rule effectively says, “For inbound traffic to my firewall’s public IP address on port 3389, translate it to my Spoke1 VM private IP address also on port 3389.”

Note:  Allowing RDP to a VM is fine in our test setting but in a production environment another more secure arrangement (such as using a jump box) would be a better practice.

Azure Portal -> search for and click Firewalls -> click the newly-created firewall -> under Settings click Rules -> click NAT rule collection -> click Add NAT rule collection -> configure the rule using the settings below -> click Add to save the rule.

7. Still in Azure Firewall, create a Network rule collection for the spokes with priority 2000 that will allow RDP traffic between the spokes and any destination. 

Note it is possible to create just one rule to accomplish this but creating two rules, one per spoke, allows for changes to just one spoke, i.e., if you wanted to allow traffic from just one spoke to the other but not the internet. 

In the firewall under Settings click Rules -> click Network rule collection -> click Add network rule collection -> configure the rule using the settings below -> click Add to save the rule.

8. Now that everything is in place, let’s test it by using RDP to connect to the Spoke1 VM.  Note to do this, you connect to the Spoke1 VM using the firewall public IP address in your RDP client.  The sole NAT rule collection we created will send the traffic to the Spoke1 VM.  Once logged in, perform the following tests:

1. Ping the Spoke2 VM.
2. Tracert to the Spoke2 VM -> verify the firewall private IP is the first hop, noting that sometimes the IP listed will not be the actual firewall IP but an IP in the same firewall subnet.
3. Tracert to bing.com -> very the firewall private IP is the first hop (again, could be IP on same subnet)
4. Open a web browser and visit https://whatismyipaddress.com/.  Verify the public IP address this site returns matches the firewall’s public IP address listed on the firewall’s Overview page.

These tests show that intra-spoke and internet traffic goes through the Azure Firewall. 

Conclusion:

If all tests are successful you have used Azure Firewall to route virtual network traffic between hub and spokes as well as the internet.  Not only have you made your network more secure, but you have avoided a complex NVA solution and configuration.

Note the Azure Firewall has many deployment options, including using the Firewall Manager with Secure Virtual Networks and Hub Virtual Networks, each of which offers different security and deployment options.  For further information, see the documentation for Azure Firewall and Azure Firewall Manager (links for both services found below).

Happy routing!

Further Reading:

• Cloud Adoption Framework
• Azure Firewall
• Azure Firewall Manager
• Implement a hub-spoke network topology - Azure Reference Architectures | Microsoft Docs
• How to configure virtual hub routing - Azure Virtual WAN | Microsoft Docs
• Tutorial: Secure your hub virtual network using Azure Firewall Manager | Microsoft Docs

Authors: @DJBartles / @PatrickHorn