Cloud-based virtual networks are software based, and they provide a standard way to organize and isolate Virtual Machines running in the cloud. A virtual network controls addressing, DNS settings, security policies, and routing tables.
Virtual Networks which are commonly referred to as “v-nets”, are isolated from one another. Due to the isolation, you can create networks for development, testing, and production that use the same address blocks.
To allow even further isolation, v-nets support subnets, which allow you to segment the network. Subnets will allow you to break out VMs by their purpose, which is common with tiered architectures. For example, if you have an application broken out into front-end and back-end tiers, then you might want to create two subnets, one for the front-end VMs, and another for the back-end tier.
If you're familiar with traditional networking components then you're going to feel right at home working with v-nets. So, if you're looking to learn more, then start in on the first lesson!
|Lecture||What you'll learn|
|Intro||What will be covered in this course|
|Overview||The componets of virtual networks|
|Creating a v-net||Creating a virtual network part 1|
|Completing the v-net||Creating a virtual network part 2|
|Application Gateway||The application load balancer|
|User defined routes||Using route tables|
|Traffic Manager||DNS based load balancing|
|Hybrid networking||VPNs and express route|
|Final thoughts||Wrapping up the course|
Welcome back! In this lesson we’ll cover another aspect of networking within Azure, namely user-defined routes.
In previous lessons we built out virtual networks with multiple subnets, and you may have noticed that the VMs in the front-end and back-end subnets were able to communicate with each other by default.
Also, the VMs were able to communicate with the public internet via their public IP address.
The reason why this communication is possible is because of route tables, which are lists of rules about how traffic flows.
Route tables control how traffic flows between VMs in the same subnet; between VMs in different subnets of the same v-net; between VMs and the internet; between multiple v-nets, and between v-nets and on-premises resources through a VPN.
By default, all traffic is allowed within a v-net, 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 v-net.
One frequent use-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 use-case, they lack insight into the packets, and don’t allow for traffic redirection . So if you use network security group rules to allow traffic between subnets, then it will allow all traffic that matches the rules, regardless of what that traffic is.
So, in cases where you’d like to know what’s happening in those packets, before sending them to your instances, you’d use user-defined routes to send the traffic through a firewall. You could define a custom routes table that lets you redirect incoming requests to some sort of virtual appliance that can filter out malicious packets and forward the rest along to wherever they were originally heading.
When creating a custom route for a routing table, there are three main values to consider. The first is the destination CIDR block for the traffic, which all custom routes require. If the destination’s address falls into this range, the this rule will apply.
Then there is the “next hop.” This tells Azure where to route the traffic before it gets to the destination defined above.
The available options are:
Which represents the local virtual network. This is used to forward the packet on to another subnet in the v-net.
The next option is the Virtual Network Gateway
This represents an Azure site-to-site VPN.
Next is the Internet
This represents the default Internet gateway provided by the Azure Infrastructure
Then there’s the Virtual Appliance option.
This allows you to use a virtual appliance that you’ve added to your Azure virtual network.
And finally, there’s the None option.
This can be used to stop the traffic dead in its tracks right here. The packets will not be forwarded at all.
The next setting is the is nexthop value. This is the IP address of the device specified if “Virtual Appliance” is specified.
And that’s all there is to creating a User Defined Route. Useful as they may be, they’re just not complex enough to talk about any more.
So that’s going to wrap up this lesson. In the next lesson we’ll cover geographically distributed applications with Traffic Manager.
So, let’s keep learning in the next lesson!
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.