Do not let ExpressRoute, VPN and SDWAN traffic bypass your firewall

I have recently expanded my SDWAN in hub-and-spoke networks design guide to include SDWAN-to-firewall routing. Initially I didn’t have this point, but recent conversations have made me realize that not everybody understand this.

The main difficulty in this topic is related to the fact that you cannot inspect the effective routes of your Virtual Network Gateways. Why is this important? Well, because that routing is going to determine where traffic goes to. It could go through the firewall or it could bypass it.

Azure gateways and Azure Firewall

Let’s start with the classical design of VPN or ExpressRoute gateways and Azure Firewall. Before adding any route table to the topology, the Virtual Network Gateways will have these effective routes:

How to verify that? Unfortunately in Azure you cannot see the effective routes of Microsoft-managed injected services, but you can deploy a small Virtual Machine in a small subnet in your hub, and inspect the effective routes there. They will be the same as the effective routes in every other subnet in the hub, including the GatewaySubnet and the AzureFirewallSubnet.

Now, how would you send traffic from the gateway to the firewall? Easy, you might say. Let’s configure a static route containing a summary for the spokes (10.1.0.0/16 in my topology):

However, with this configuration you would be bypassing the firewall, since the system routes injected by the VNet peerings are still there (10.1.1.0/24 and 10.1.2.0/24) and will be preferred to your static summary because they are more specific.

And no, there is no way in Azure to prevent those system routes coming from the VNet peerings from being created.

The right way

If you want the gateways to send traffic from on-premises to the firewall, and not directly to the spokes, you will have to get rid of every individual system route for the spokes 10.1.1.0/24 and 10.1.2.0/24. You will have to create a User-Defined Route for each of those prefixes:

Now all the traffic from the gateway to the spokes will be flowing through the firewall, since there are no system routes left that can bypass the firewall.

Workloads in the hub

What about the system route for the actual hub VNet? Some years ago I wrote this article about how to override this without creating asymmetric routing: Don’t let your Azure Routes bite you. The TL;DR is that you shouldn’t create a route in your GatewaySubnet for the whole hub’s space (10.1.0.0/24 in this example), but instead use the prefixes of the subnets where your hub workloads are.

What about NVAs?

If you have NVAs for either your firewall or your hybrid connectivity (for example, SD-WAN appliances), the concept is exactly the same:

One advantage of NVAs (Network Virtual Appliances) is that you can inspect the effective routes in the NICs of your SDWAN and firewall devices, so this scenario will be easier to troubleshoot (at least from this perspective).

Wrapping up

Although this route table in the gateway subnet or the SDWAN subnet can look difficult to maintain, this design is simpler and more cost effective than the alternative (deploying VPN gateways or SDWAN appliances in their own VNet). If you are curious to see what that would look like, check design option 2b in my SDWAN in hub-and-spoke networks design guide.

I hope this was useful!