Custom Routes, or user defined routing, is part of the az-303 certification for becoming an Azure Solution Architect. In this video I tell why you would want a custom route, and then demonstrate how to create one based on a use case.
I have provisioned a virtual network with the default IP address range
10.0.0.0/16. Within this range I created 4 subnets,
AzureBastionSubnet, all with a small IP address range of
/29. Azure Bastion needs at least a range of
/27, and we use it to login to the virtual machines that I created inside the subnets. All VMs are of the same type Windows Server 2016 Datacenter. On the virtual machine that I named
c-vm, I installed the Internet Information Service IIS.
Pre setup of custom routes
Here’s want we can do, but probably shouldn’t be allowed to. We send a GET request from
c-vm to access the IIS directly on port 80.
Connection from a-vm to c-vm
Imagine that we have to protect the workload or data that is running on
c-vm. Every package that is going into this virtual machine can potentially be harmful and damage what’s stored there. If we can’t trust
a-vm, maybe it’s a better idea to not access
a-vm sending harmful packages to c-vm
What we can do instead is to inspect the traffic to another virtual machine
c-vm trusts. This
b-vm can run software that checks all incoming traffic before forwarding it to
Using another VM to inspect packages
The virtual machine
a-vm will still send its traffic to
c-vm. To be able to get
b-vm inspect the traffic, we will re-route the traffic coming from
subnetA where the VM
a-vm is running, to
b-vm that can do its work before forwarding all packages to
c-vm. To keep it simple, we will let
b-vm forward all traffic to
c-vm without inspecting the packages first.
We will create a route table with a route that applies for the traffic within
subnetC. Bastion can’t be part of this route. Otherwise we couldn’t use it as a jump host anymore.
Diagram for Azure Route Table
To demonstrate that we can (for now) access the IIS that is running on
c-vm, I used Azure Bastion to login to
a-vm, and send a request to the private IP address of
c-vm. This works fine as expected as we haven’t done anything yet.
Accessing IIS from a-vm
I will now re-route the traffic to go through
b-vm by first creating an Azure Route table.
Create Azure Route table
The only parameters we need to set here is the resource group, region, and a name. Then we click on Create.
Configure Azure Route table
We can now create a route which needs an
Address prefix. It’s the IP address range for that the route will apply to. In our case we set
10.0.1.0/27 which includes all the subnets except the one for Bastion.
Configuring a route 1
As Next hop address, we set the private IP address of
Configuring a route 2
After we have created a route, we should see it in the route table.
Route table with one route
Right now we have created a route table and a route. What’s left is to associate the route to subnet
subnetA where the VM
a-vm is running.
Associate subnet to route
If we would test again, we wouldn’t be able to access
a-vm because we haven’t told
b-vm what to do yet. The VM
b-vm shall forward all traffic to the IP address that was originally requested from the client, in our case
a-vm. We do this in the IP configurations of the VM
Forward traffic in IP configurations
All is set now, and we can try to send a request again from
c-vm. The traffic is now going through
Sending a request vi b-vm