Network Custom Routing

This next video discusses different options available within Azure networking to configure custom routing and building out a more complex networking architecture. Azure provides default routes based on virtual network configuration for a most common network flows. First, routes are set up within each subnet and within each virtual network, so any machine within the virtual network can route to any other. Second, a route is provided for outbound internet access for any virtual machine within a subnet.

Third option, whenever you connect to different virtual networks, either using side-to-side VPN or virtual network peering, routes between the networks are set up for you automatically. And then last, whenever you connect a virtual network to an on-prem network using site-to-site VPN or ExpressRoute, an additional route is setup to enable access to the on-premises network where you are still taking ownership and responsibility for setting up the reverse route from on-prem network into an Azure VNet.

Now consider the standard configuration for VNets in Azure. By default, we have traffic flowing into the network directly to the front end of your application and then traffic from those virtual machines to the back end subnet, for example, a database server. The user-defined routes are allowing you to alternate those traffic path, for example, to insert a security appliance into the network path.

So what you’re going to do is deploying an additional user-defined route, including a network virtual appliance like a firewall, a bastion host, as we call it. And instead of using the default route that I talked about before, we’re now going to force all traffic from, in this example, the web virtual machine subnet to the database subnet passing through the user-defined route and not using the default one any longer.

Now to configure user-defined routing, you start by creating a routing table resource. Within this resource, it’s giving you a list of all the subnets, both of which you need to configure. You specify new routes by giving the route name, the destination address, prefix, and the next-hop. The next-hop determines where traffic destined for that address prefix will be sent to. Possible next-hop types are the local virtual network, a virtual network gateway, the public internet, a virtual appliance, or a null destination, which can be used to black hole certain traffic.

If you choose the virtual appliance next-hop type, you will also have to configure the IP address of the inbound interface of that specific appliance. Associating subnets with the routing table is pretty straightforward. Simply selecting the subnets from the routing table blade in the Azure portal should allow you to configure it. The subnet itself needs to reside in the Azure region where you configure the routing table.

Now I already talked about a virtual appliance. So it’s basically deploying a virtual machine running some kind of firewall and operating system. It could be a Linux machine or any of the third-party firewall vendors who are also providing virtual appliance alternatives in the Azure marketplace. So the example here shows traffic that can be directed so that it flows through the firewall device when entering or leaving the network.

In the diagram, we have two networks, the FrontEnd and the BackEnd, where each has a custom routing table associated with it. The FrontEnd table has two rules. The two internet rule has been configured for the default route denoted by the IP address 00.00 and directs any traffic not matching an existing route to the public internet. The two BackEnd routes in turn is identifying any traffic matching the BackEnd subnet and directs all this traffic to the FrontEnd of the firewall appliance.

On the BackEnd network, the routing table directs all outbound traffic to the BackEnd interface of the firewall so no dead routes in the routing table. Unlike rules and network security group, you don’t have to explicitly define any priority setting. Instead, priority is determined by which rule has the longest prefix match for the traffic in question. For example, the FrontEnd routing table will match a packet 210.10.2.45 against the two BackEnd rule rather than the two internet rule. Whilst both rules technically match the packet, the two BackEnd rule has the tighter, more specific match. And that’s the one that will be used.

And that’s about it on the different virtual network connectivity configuration options. Now to make it a bit more practical, let me show you how to configure an Azure custom route using routing tables. So let me start with creating a new Azure routing table. So similar to the creation of any other Azure resource, we start with creating a resource and selecting Routing Table. Let’s call this one the Apress Routing Table. And we’re going to use the same resource group that we already used before.

Lastly, we define the region where we want to create this routing table. Once my routing table has been deployed as the resource, we can now continue and adding an actionable routing object. So from here, we’re going to select Routes, and we’re going to add a new one. So this could be routing to internet, for example, where my address prefix could be the 10.0. And the next-hop could be the virtual network gateway if I’m using VPNs, another virtual network. And since I defined it as route to internet, I’m going to use it in that scenario.

So now we have our routing options available. Let’s go back to the virtual network. So from our resource group, don’t worry too much about all the other resources, because the one that I need is my application VNet. So what I can do from here in my subnet options is selecting the specific subnet I’m going to use. And up here, I can link it to that new routing table option that I configured before. Saving the settings. And the result is that all traffic that’s destined to the internet will now specifically go through that route.

In this video, you learned about Azure VNets providing a default route to set up traffic destinations. You also learned about Azure VNets supporting customer network routing options. And lastly, by using virtual appliances using multiple NICs, one can create a more complex-routed network topology. Where you might think of custom routing as a security option with Azure networking, it’s not completely wrong. But I’ll talk about network security features specifically in the next video.