1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. 70-534 - Architect ARM Networking

User-defined routes


Start course


This course covers the Architect ARM Networks part of the 70-534 exam, which is worth 5 - 10% of the exam. The intent of the course is to help fill in an knowledge gaps that you might have, and help to prepare you for the exam.


Welcome back. In this lesson I'll cover another aspect of networking within Azure, namely, user-defined routes.

In the previous lesson, I showed a diagram that detailed out two different subnets inside of a VNet, and I mentioned that virtual machines can communicate cross-subnet by default. Also, I showed that virtual machines can communicate with the public Internet, when I connect it to Ubuntu VM via SSH using its public IP address.

The reason why this communication is possible is because of the route tables, which are lists of rules about how traffic can flow. Route tables control how traffic flows between virtual machines in the same subnet, between VMs and different subnets on the same VNet, between virtual machines and the Internet, between multiple VNets, and between VNets and on-premises resources through a VPN.

By default, all traffic is allowed within a VNet, even if the machines are on different subnets. However, by adding user-defined routes within your route table, you can control the flow of packets inside of the VNet.

One frequent case for user-defined routes is to send all traffic between two subnets through a firewall appliance to ensure that no malicious traffic moves between the two.

Network Security Group rules don't work for this used case because they lack insight into the packets. So, if you use Network Security Group rules to allow traffic between two subnets, then it allows all traffic that matches the rules, regardless of what the traffic is.

So, in cases where you'd like to know what's happening in those packets before sending them onto your instances, you'd use user-defined routes. You could define a custom routes table that allows you to redirect incoming requests to some sort of virtual appliance that can filter out malicious packets, and forward the rest along to whatever they were originally heading to.

When creating custom route for routing table, there are three main values to consider. The first is the destination CIDR of the traffic, which all custom routes require. If the destination's address falls into this range, then the rule is going to apply. And then there is the next hop which tells Azure where to route the traffic before it gets to the destination defined above.

The available options here are Virtual network, which represents local virtual network. This is used to forward the packet onto another subnet in the VNet. The next option is the Virtual network gateway, and this represents an Azure site-to-site VPN.

The next option is the Internet, which represents the default Internet gateway provided by the Azure infrastructure. Then there is the Virtual appliance option. This allows you to use a virtual appliance that you've added to your Azure virtual network.

And the final option is the None option, which can be used to stop traffic dead in its tracks. This will make sure that no packets are forwarded at all. The next setting is the next hop value. This is the IP address of the device-specified, if the virtual appliance is the specified next hop.

And that's pretty much all there is to creating a user-defined route. Now, useful as they may be, they're just not complex enough to keep talking about anymore.

So, that's going to wrap up this lesson. In the next lesson, I'll cover the Azure application gateway. So, if you're ready to keep learning, then let's get started on the next lesson.

About the Author

Learning paths15

Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.