Many companies struggle with concepts of “cloud networks” and how it relates to their on-premises networks. How do you deploy a firewall in there, with multiple subnets? Do we need multiple VNET’s and what about those subnets? Well, this post is about what you actually need to understand prior to deploying 3rd party firewalls (and/or VNets) and how routing works inside a VNET, and finally the common mistake of comparing an Azure VNET to a Hyper-V/VMWare VNET.
It seems what most Networking Departments struggle with is the concept of Virtual Networks, and their subnets. I’m not sure who’s fault it is, but the confusion in my perception comes from the fact that many people view the Virtual Network as a VLAN or something like it as this was the case with many on-premises Hyper-V/VMware deployments. While in reality we should see the Azure Virtual Network more as a counterpart of the physical network in a datacenter. In can encompass multiple subnets that by default talk to each other but can be forbidden to do so to. It also means that extending the network with new subnets is relatively easy, that connecting multiple VNET’s is a bit harder (equal to creating site-2-site connections or cross-network connections).
So its with that mindset that when you deploy a firewall from the marketplace, that the firewall is actually connected to two subnets rather than two virtual networks. But I guess that it may seem scary that two subnets that used to be able to have a completely open connection are now controlled by a firewall which is not even in the direct path. So let’s see what happens when we actually deploy a 3rd party firewall.
By default each Subnet in a Virtual Network has a gateway. This gateway has the x.y.z.1 address in the subnet by default. (or the first usable IP in the subnet). The other IP’s (2/3) are reserved as well, which is why the first VM to be deployed into a subnet always gets x.y.z.4 as the IP address (or the 4th usable IP of the subnet).
When we deploy the firewall into the subnet, it will receive the .4 address and always the .1 as the default gateway. Which might be strange too, as with on-premises deployments the firewall is usually the default gateway. What actually happens is that through the use of User Defined Routes, we can control the traffic flow. The UDR is applied to the Azure Gateway (.1) to send all the traffic it receives to a different gateway; the 3rd party firewall. So in short, when you deploy a marketplace firewall into a subnet, the UDR on the default gateway will send all traffic back to the FW IP address in the subnet itself. (in our example: a VM sends traffic to the subnet gateway (.1) which then sends it to the FW (.4)).
The firewall itself then forwards the traffic to the Gateway again for further processing. Now to be completely clear, it’s not the Azure Gateway you deploy for Site2Site or Point2Site or ExpressRoute connections. It is the Subnet default gateway, similar to a layer 3 switch or router on your physical network to route between VLAN’s.
When configuring UDR’s you can set the source and destination for IP subnets. The destination can be a Virtual Appliance (read IP address you define), the Virtual Network (to reach other subnets in the same VNET), the Internet (for regular internet traffic) and the Virtual Network Gateway (the one you DO create yourself to make VPN’s).
So if you look at it from a logical perspective, the following picture is a standard VNET implementation using 3 subnets (one for the VPN gateway)
Say now that we want to add the firewall applicance where we have a separate DMZ, a separate internet and an “internal” zone. This would be a 3 legged firewall, but in this case we don’t have a direct public IP address that we can just plug-in.. instead, we need to create another subnet that will be used as the “internet” subnet. As it will only contain 1 NIC, it can be really small.
As you can see, the subnet Gateways are still there, and they do have a direct internet connection. It’s only the configuration of the UDR’s that control the traffic flow in such a way that traffic is sent to a particular IP address within a subnet.
Now this may seem as a complex, not very flexible solution, but less is true. Since the fact that we already have the built-in gateways, we can actually combine new subnets and gateways to send traffic to other subnets without the firewall having to have a NIC in that subnet. Similar to Layer 3 switches and Firewalls in your corporate network.
In the picture below, traffic from subnet C is always forwarded to the NIC wxyz. And it will arrive at that NIC on layer 3 basis (meaning the source IP of subnet C is maintained).
The traffic from subnet A and subnet B are always forwarded to the NIC interface of the Firewall within the same subnet. This may seem strange, but logically; the entire routing engine is given to the VM (read Firewall) itself, rather than the gateways on the subnets. The subnet level gateway will still be there, and they are actually responsible for forwarding the traffic towards the NIC’s.
So the first warning: NEVER CHANGE THE IP CONFIGURATION ON YOUR VM. The Azure network will take care of the routing for you. Obviously you will still be able to set your own routes inside the VM, but it’s actually better to use UDR’s for that, so you can view them centrally.
Now with the images above, your external IP’s are to be created on the Internet Zone and then either load balanced to your FW’s (if you have HA config) or directly on the interface of the VM in the Internet zone. The subnet UDR for Internet is the only UDR that actually has a default 0.0.0.0/0 route pointing with Internet as the next-hop.