Microsoft Entitlement Management – Create an Access Package

Reading Time: 11 minutes


In this post I will explain the purpose of Microsoft Entitlement Management and a step by step set up guide.

What is Entitlement Management?
An employee joins a company or a new team and has no idea what groups, applications, and SharePoint Online sites they require access to perform their job. When the employee finally figures out what access is required, they face difficulty locating the right individuals to approve their access. Furthermore, the employee may not have been able to locate all the resources they require access to. But it gets worse because once users find and receive access to a resource, they may hold on to access longer than is required. The end result is that a lot of time is wasted and can cause frustration when an employee is not able to be productive in their role.

Entitlement management can help address these challenges. This service can control who can gain access to applications, groups, Teams and SharePoint sites, with multi stage approval, and ensure users don’t retain access indefinitely through time limited assignments and recurring access reviews. You can give users access automatically to those resources, based on the user’s properties like department or cost centre, and remove a user’s access when those properties change. You can delegate to non-administrators the ability to create access packages. These access packages contain resources that users can request.

When a user who isn’t yet in your directory requests access, and is approved, they’re automatically invited into your directory and assigned access. When their access expires, if they have no other access package assignments, their B2B account in your directory can be automatically removed. We need to ensure that we grant employees the right level of access they need to be productive and remove their access when it’s no longer needed.

Pre-requisites
To use entitlement management, you must have one of the following licenses:

  1. Microsoft Entra ID P2 or Microsoft Entra ID Governance licenses (Entra Governance provides additional capabilities compared to Entra ID P2. Visit the following link for a comparison. Entra ID Licenses Comparison
  2. Enterprise Mobility + Security (EMS) E5 license

    Prerequisite role:
  1. Global administrator or Identity Governance Administrator


Configuring Entitlement Management Step by Step

Now that we have a basic understanding of Entitlement Management, let’s go through and create an access package and allow a user to access the package.

  1. Login to entra.microsoft.com or access portal.azure.com. For the purpose of this post, I will be using entra.microsoft.com

  2. From the left pane, expand Identity > Identity Governance > Click Entitlement Management


3. We first create a catalog but what is the purpose of a catalog? Let’s find out.

A catalog serves as a container for resources and access packages. When you want to group related resources and access packages together, you create a catalog. The person who creates the catalog becomes its initial owner. The resources we will add later in this post must exist inside a catalog. Let’s create an empty catalog for now and cover the rest later.

Click Catalogs and Click +New Catalog


4. I’ll be creating a catalog for the Sales team

I will be enabling this catalog and enabling access for internal and external users so users from external directories can also request access. You could also disable this catalog until you are ready to publish. This will ensure that it’s not visible to users until you are ready.


5. Click Create and an empty catalog will be deployed in a few seconds. The catalog includes no access packages and resources for now.

6. Now we add resources to the catalog. The resources can include applications, SharePoint sites and Groups. There is a new addition coming soon at the time of writing this post, and that’s the capability to add Microsoft Entra Roles. Access the Sales Catalog created earlier.

7. From the left pane, click resources


8. Click + Add Resources


9. For the purpose of this demo, I’ll be adding a Group, Application and a SharePoint site.


Note: Groups synced from on-premises can not be added as a resource

10. When done, click the Add button found towards the left bottom corner.

11. Allow the resources to be added. This takes a few seconds


12. Now that I have added the resources to the catalog and because I was the one who created the catalog, I become the owner by default. I will now add another owner to the catalog so I can share the responsibility with a group of owners.

From the left pane, click Roles and Administrators


13. I have the options to add different admins to a number of roles, including, catalog owner, catalog reader, add access package manager and add access package assignment manager.

I’ll be adding another catalog owner, click + Add catalog owner


14. For the purpose of this demo, I’ll be adding an existing group of users

15. If there is a need to disable or enable the Catalog so it is not visible to users, or if you wish to change the description, click the overview option available in the left pane.


Create Access Package

16. Now we need to advertise and make our catalog available to users. This is where we introduce an access package. From the left pane, click Access package and + New access package


17. Give your access package a name, for the purpose of this demo, I’ll be naming the access package Sales Access Package.

18. Give the access package a suitable description

19. Click Next: resource roles

20. Next, I click Groups and Teams and the one group I added to the catalog should be visible. At this point you can set the role for the group. For example, a user who requests access to this package will become an owner of the group or member. I’ll be selecting Member.

Note: if you only see the option of owner, you may have selected a dynamic group. The member option is not available by design.


We are also able to configure permissions for the other resources, SharePoint sites and Apps as shown in the image below.


21. Click applications and the one App I added to the Catalog earlier is visible. Finally I add the SharePoint site from the catalog, as you can see the Catalog includes resources I can select. Similar to going through and shopping for clothes in a catalog. 🙂

Note: if you wish to add more resources at this point, you can enable the option to see all groups and Teams, or all apps, or all SharePoint sites. Below is an example where I can enable a check box to view all Groups and Teams which were not originally added to the Sale Catalog.


21. When ready, click next to move onto the Request tab


22. This is where we configure who in our organisation can request this package, as in access to the SharePoint site, a group and one application. This is known as the policy.

  • For users in your directory
    This option only allows users in your Entra ID to request access.

  • For users not in your directory
    You add a connected organisation for the Microsoft Entra directory or domain you want to collaborate with. A connected organisation is another organisation that you have a relationship with. In order for the users in that organisation to be able to access your resources, such as your SharePoint Online sites or apps, you’ll need a representation of that organisation’s users in that directory. Because in most cases the users in that organisation aren’t already in your Microsoft Entra directory, you can use entitlement management to bring them into your Microsoft Entra directory as needed.

  • None (administrator direct assignments only)
    Administrators will need to verify that the users are eligible for that access package based on the existing policy requirements. Otherwise, the users won’t successfully be assigned to the access package.

23. I select For users in your directory


24. After enabling the option in step 23 above, a further option to select users or groups who can request this package becomes available. As shown in the image below.


25. Click the option + Add users and groups

26. Select a group of users who will be allowed to request access to this package. This could include groups created in Entra ID or synced from on-premises. You can also configure whether guests are allowed or excluded from requesting this package.

27. Next, I configure require approval to Yes, which makes further approval options visible. When users request for this package, someone in the organisation can review and approve/deny access. I’ll be configuring approvals as per the below,

  • Require approval: Yes
  • Require requester justification: Users must provide a justification to request an access package. Justification is visible to other approvers and the requestor.
  • How many stages: How many people in your organisation need to approve before the package/resources are made available to the user requesting access. I could have one, two or three people approve access before the package is made available to the user.

28. For the purpose of this demo, I require one approver and that approver will be me. It is recommended to add a group instead of an individual user as an approver.

We could also select the user’s manager to approve access. A manager must be added to the users account for this to work.


29. The next option is, Decision must be made in how many days? this is set to 14 days by default.

The approver must review and make a decision within 14 days. If a request is not approved within this time period, it will be automatically rejected. Minimum is one day and maximum 14 days. Feel free to lower the days as needed.

30. Next option: Require approver justification – The approver must provide a justification for their decision. Justification is visible to other approvers and the requestor.


31. Click Show advanced request setting

A further option: If no action taken, forward to alterative approver

This option allows the approval request to be forwarded to an alternative approver if the original approver does not respond on time.


32. Finally, we have the choice to enable or disable new requests. When disabled, no new requests can be made using this policy. Select Yes to enable this access package to be requested as soon as it’s created.


Required Verified IDs: this is a feature which requires a Microsoft Entra ID Governance license. Sometimes you may want users to present additional identity proofs during the request process such as a training certification, work authorisation, or citizenship status. As an access package manager, you can require that requestors present a verified ID containing those credentials from a trusted issuer. Approvers can then quickly view if a user’s verifiable credentials were validated at the time that the user presented their credentials and submitted the access package request. As an access package manager, you can include verified ID requirements for an access package at any time by editing an existing policy or adding a new policy for requesting access. I published a post about Verified ID at the following link, What is Microsoft Entra Verified ID? | Cloud Build

33. Next, we move onto the Requester information tab. If needed we can ask questions to collect more information from the requestor and specify whether the question is mandatory or optional.


34. Click next to move to the lifecycles tab.

On the Lifecycle tab, you specify when a user’s assignment to the access package expires. You can also specify whether users can extend their assignments and if further approval is required. In the Expiration section we have the following options.

  • Access package assignments expire 
    We can set to number of days, number of hours, a particular date or never expires.

  • Assignments expire after number of days.
    Depending on the option set above, this field changes. I selected Number of days, therefore, I need to specify the number of days before access expires for the user.

  • Users can request specific timeline
    If enabled, users requesting this access package will be able to submit a custom start or end date for their access. Their request cannot extend beyond the timeline defined in the policy for the access package.

  • Allow users to extend an access
    When enabled, users will be able to request extension of their access to this package before their access expires.

  • Require approval to grant extension
    If an extension is requested, same approval settings used to approve initial access will apply.

  • Require access reviews
    When switched to Yes, further options are visible as shown in the image below. To reduce the risk of stale access, you should enable periodic reviews of users who have active assignments to an access package in entitlement management. You can enable reviews when you create a new access package or edit an existing access package assignment policy. Microsoft Entra ID P2 or Microsoft Entra ID Governance licenses are required for all approvers. Approvers can include Global administrator, Identity Governance administrator, Catalog owner, or Access package manager.

    I have set access reviews to no for the purpose of this demo


35. Finally, we move to the last tab, Custom Extensions

Custom extension are part of the Entra ID Governance license.

Custom extensions allows the use of Logic Apps to automate certain tasks. For example, you could use custom extensibility and an Azure Logic App to automatically send notifications to end users on Microsoft Teams when they receive or are denied access to an access package. Or a user is sent a custom email, for example a company wants to send an email to the sales team when a user is granted the sales team access package, so they are aware that a new sales member has joined the team. Or when a new user is approved for access to the Sales team Access Package, a Logic App is automatically triggered which also assigns that person to the appropriate deals and contacts within Sales Force. Likewise, when someone is removed from the Access Package, a different Logic App is automatically triggered and does the reassignment for the Salesforce artifacts they were responsible for. Automating these processes allows the team to focus more on getting actual work done rather than managing access. And more!


36. Click Review and Create.

Review your choices and click create.

In the next post we will go through the process of requesting the access package as a user and go through the approval process. Click the following link to continue, Microsoft Entitlement Management – Request Access to an Access Package | Cloud Build.

Microsoft Entitlement Management – Request Access to an Access Package

Reading Time: 3 minutes


In the previous post I went through the process of creating an access package step by step. I would recommend having a read at the following link, Microsoft Entitlement Management – Create an Access Package | Cloud Build

In this post, I will perform the steps as an internal requestor named Patti Fernandez and request access to the newly created access package created as part of the previous blog post.

  1. Open your access package


2. From the left pane click Overview


3. You could request access via the unique access link available under the field My Access portal link


4. Or the user requesting access could visit https://myaccess.microsoft.com

Previously I created a package and granted a group permission which included a user named Patti Fernandez

I visit https://myaccess.microsoft.com and login as Patti Fernandez

5. From the left pane, click Access packages


6. and there is the Sales Access Package I created earlier. Under the column Actions, click Request.


7. Before clicking continue, I have the opportunity to check the resources I will be granted access to by clicking the Resources tab. I can also copy the link and share with a colleague.

Click continue


8. As per my request policy I configured earlier, I am asked to provide a justification. I also allowed users to specify if they require access to a package between certain dates so the option is available for the requester if they wish to input a custom date.

Click Submit Request


9. I now need to wait for approval. Why? because I specified that approval was required before a user could gain access to the package. The approver was me. I’ll receive an email to notify me a request is pending approval.


10. I login to https://myaccess.microsoft.com as the approver

11. From the left pane, click Approvals.


12. Review the access and approve or deny. Click Submit


The user is granted access to the resources I specified in the access package.

I hope you found this post useful. See you at the next post.

Azure Route Tables Explained

Reading Time: 16 minutes


In this post, I discuss the differences between Azure default routes and user defined routes (UDR), including the configuration options available when creating a user defined route.

When we create Virtual Networks in Azure, the Azure platform automatically creates a route table for each subnet located inside a Virtual Network. To simplify, a route table is like a set of instructions. For example, a Virtual Machine asks the route table for directions. “Hello Route table, how do I get to this destination?”. The route table provides the Virtual Machine with the next hop, such as, if you wish to get to this destination, this is how you get there.

The default route table automatically created by Azure includes a number of default system routes. These system routes can not be modified or deleted, however, you can override the routes by creating custom routes, also known as User Defined Routes (UDR’s). These are routes created by the user, as in you, and can be modified and deleted as needed. I’ll cover UDR’s later in this post.

Note: This post is intended to provide a basic understanding of route tables. It is important to carefully plan your routing in your production environment, as incorrect routing configuration could lead to major issues.


How to view the Azure system default routes

One of the ways to view the default routes automatically created by Azure is as follows,

1. Locate a Virtual Machine in the Azure Portal
2. From the left pane, under settings, click Networking.


3. Click the network interface located under the IP configuration drop down menu as shown below.


4. From the left pane, scroll down and click Effective Routes, located under the Help section.


Allow a few seconds for the route table to load. We’ll study the default routes in the next section.



What is visible inside the Route Table

We see a number of active default routes, I have taken a small snippet and displayed it below.


The routes in the diagram are as follows.

Source: Default
These are default routes created by Azure and can not be modified or deleted.

State: Active
The state of the route. In the image above, active, meaning the route is enabled.

Address Prefixes: 10.2.0.0/16 and Next Hop of Virtual Network
The address space used for my Virtual Network is 10.2.0.0/16. That’s the IP address name space I configured when I created the Virtual Network. When I configured this address space, Azure automatically created a default route. You may have heard or read that resources inside an Azure VNET (Virtual Network) including resources in different subnets within a VNET can communicate with each other by default. This is the default route which allows that communication to happen.

For example, the below image displays one Virtual Network named VNET1. The VNET (Virtual Network) includes Subnet1 and Subnet 2. Each Subnet includes one Virtual Machine (VM1 and VM2). By default VM1 and VM2 can communicate with each other inside VNET1. If we were to deploy additional Virtual Machines to Subnet1 or Subnet2, all VM’s would be able to communicate with each other. This is the default behavior made possible by this default route.


Address Prefixes: 0.0.0.0/0 and Next Hop of Internet
When we build a new Virtual Machine (VM) in Azure, did you know that the Virtual Machine has outbound internet connectivity enabled by default? Meaning that I could logon to that Virtual Machine and browse the internet such as cloudbuild.co.uk and other websites. How? This is the default route which allows outbound Internet. This is like a catch all route, so if a route is not already located in the route table, Azure will route traffic for any address not specified by an address range within a Virtual Network to the Internet. In simple terms, “if a route does not exist, send it to Internet via 0.0.0.0/0”. However, there is one important exception to note, if the destination is for one of Azure’s services, Azure routes the traffic directly to the service over Azure’s private backbone network, rather than routing the traffic to the Internet.

You may be thinking, “resources have outbound internet connectivity by default. Is this secure?”. If you have had this thought, it’s good to know that you have security in mind, and you’re right, this is not secure by default. However, this default behavior is due to change in September 2025. Check out the following post for details, Default outbound access for VMs in Azure will be retired September 2025.

Next Hop: None
Traffic destined to these address prefixes is dropped, it goes no where and will not leave the subnet. For example, when I created my VNET, I used an address space of 10.2.0.0/16 and we can see a default route for that in the route table above. I did not configure any other IP address name spaces such as 10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16, therefore Azure creates a default route to drop this traffic. Why? because I am not using these private IP ranges. However, if at a later date, I do decide to use one of these IP ranges in my VNET, Azure will automatically amend the next hop of none, to Virtual Networking. So none refers to not allowing traffic destined for that address prefix out of the subnet.

So that is an overview of the default routes, however, there is something to keep in mind. As you enable additional services such as VNET Peering and Virtual Network Gateway to name a couple, Azure will continue to create default system routes. For example, If I was to peer two Virtual Networks, VNET1 to VNET2. Let’s say VNET1 is located in the region UK South and VNET2 in region UK West. I have a requirement to connect the Virtual Networks together to allow resources in VNET1 to communicate with resources in VNET2. Peering would allow me to connect the Virtual Networks and the Azure platform will create a new default route automatically to allow resources to communicate with each other between the Virtual Networks. Below is a route which is created by Azure after I peer to another VNET configured with an IP address name space of 10.3.0.0/16. This address space belongs to the VNET I established a peer with meaning resources in VNET1 know how to get to resources in the peered Virtual Network of VNET2.



What if we want to override a default route or create additional routes?

We know that the default routes can not be deleted or modified. However, we can create custom routes also known as a User Defined Route (UDR) to override the default routes.

When we create custom/user defined routes, they are combined with the default system routes. However, if there are conflicting route assignments, user defined routes override the default routes. For example, we have a default system route of 0.0.0.0/0 with next hop to the Internet. This means traffic from a server is allowed to access the internet outbound. We decide to override this route because we want to route our traffic to a Firewall instead of being allowed unrestricted access to the Internet. We could create a custom route of 0.0.0.0/0 with a next hop of Virtual Appliance, and specify a firewall IP address. We now have a conflict because we have two routes with 0.0.0.0/0. One route to the Internet and one to a Firewall. In this case the default system route would change from active to invalid, and the custom route sending traffic to the firewall will take priority and display a status of active. As show in the image below.

We will discuss custom/user defined routes including next hop choices in the next sections.


Azure Custom/User Defined Routes Explained

As explained earlier in this post, we can create custom/user defined routes to override the default system routes or create new routes in addition to the default routes. Let’s dig a little deeper.

Let’s say in our scenario we deploy a simple hub spoke topology as shown in the diagram below.



We know that by default VM1 and VM2 are allowed outbound internet connectivity. Can you remember which default route allows this routing to take place? Remember the default system route 0.0.0.0/0 with next hop of Internet? That’s the one. We also know that Virtual Machines in a VNET can communicate by default, so in VNET1 shown in the image above, VM1 and VM2 both residing in different subnets can communicate with each other. Can you remember which default system route allows this communication to happen within a Virtual Network? We discussed this further up in this post. I’ll let you go and check. 🙂


Creating a custom route table to route traffic to a Firewall
What if there was a requirement to override the default system route of allowing Virtual Machines to route out to the Internet using the default route of 0.0.0.0/0 and next hop Internet. As an example, let’s say in the diagram below, we wanted to route traffic for VM1 located in VNET1 to a firewall deployed in HubVNet. How would we do this? We would go into the Azure Portal, create a route table and add a custom/user defined route. We’ll cover how to do this in the next section below.

Note: you could also use other methods to deploy resources in Azure such as Powershell, CLI, ARM Templates, Azure Bicep or third party tools such as Terraform. I am focusing on deploying via the Azure Portal in this post.


Let’s go through the process of creating a route table and custom routes.

1. In the Azure Portal, search for Route tables


2. Click Route tables to create a new one
3. Input the details as required. I have inputted a few details below for demo purposes.

Propagate gateway routes: If you plan to associate the route table to a subnet in a virtual network that’s connected to your on premises network through a Virtual Network Gateway, and you don’t want to propagate your on premises routes to the network interfaces in the subnet, set Virtual Network Gateway route propagation to No.

When you disable route propagation, the system doesn’t add routes to the route table of all subnets with your Virtual Network Gateway routes. This process applies to both static routes and BGP (Border Gateway Protocol) routes. Connectivity with VPN connections is achieved using custom routes with a next hop type of Virtual Network Gateway. Route propagation shouldn’t be disabled on the GatewaySubnet. The gateway will not function with this setting disabled. If you set Propagate gateway routes to NO and associate the route table to the spoke subnets, the VMs in those subnets do not get the Virtual Network Gateway routes.

4. Click Review + Create
5. Once created, open the newly created Route Table. It will be an empty table without any routes.
6. Let’s create a User Defined Route. From the left pane, click Routes


7. Click the +Add button


8. We have a few options as shown in the image below.


In the next section we will go through these user defined route configuration options.


Azure User Defined Route configuration options explained


Route name: give the route a suitable name.

Destination Type:


We have two options available in the drop down as shown above. We have,

IP Addresses (Address prefixes)
Here you type the destination IP address range. Where is the resource such as the Virtual Machine wanting to go? For example, in the image below, resources in VNET1/Subnet1 are required to communicate with resources located in VNET2/SubnetA. We would specify the address space of VNET2/SubnetA as 10.2.1.0/24, along with some additional configuration we cover later in this post. For now let’s focus on the text highlighted red in the diagram below, destination 10.2.1.0/24.


Why do we need to create a route for VM1 to communicate with VM3 through HubVNET?
VNET peering is non-transitive by default, which means that traffic from VNET1 won’t be able to reach a resource in VNET2 through a VNET in the middle. As shown in the diagram below.

Another example which may help to understand non-transitive. We have three letters A B C. Non-transitive in this example would mean that A and B can talk to each other. B and C can talk to each other. However if A wanted to talk to C or C wanted to talk to A, they could not go through B to reach each other. The same applies with VNET peering. We would need to create a user defined/custom route for this communicate between VNET1 and VNET2 to be possible as per the diagram below.



Service Tag:
From the destination type drop down, we have another option of Service Tag. A service tag includes a group of IP addresses from an Azure service. Microsoft manages the addresses included in the service tag and automatically updates the service tag as addresses change. Therefore, minimising the complexity of frequent updates to user defined routes and reducing the number of routes you need to create. In simple terms, a service tag is a group of IP addresses managed by Microsoft. If new IP’s are added or decommissioned, Microsoft manage this process so we don’t have to. If there was a requirement for you to route traffic to an Azure Service, you wouldn’t need to specify the IP ranges for that service as you could use a built in managed service tag which already includes all the required IP addresses.



Next hop type
The next hop type determines the type of device that traffic is forwarded to when it matches the address prefix/destination type of the route. For example, if the resource wants to reach a specific Virtual Machine in another Virtual Network, how does it get there? Firstly the destination is matched and then the traffic is forwarded to the next hop type such as a Firewall.

Let’s go through the options in the Next hop type drop down list.


Next hop: Virtual Network Gateway


You’ll notice that when you click Virtual Network Gateway, the option to type a Next hop address is greyed out. This is by design. Going off topic slightly but still related, when we configure peering between Virtual networks, there are configuration options available which we must configure if we require for the VNETs to use an Azure Virtual Network Gateway. I won’t be going into details on VNET peering, but I have created a post explaining VNET peering configuration at the following link Azure Virtual Network Peering Options Explained.

Back to next hop of Virtual Network Gateway, to allow for this to work we need to configure two settings.

1. Configure VNET peering options as documented in the link I shared above.
2. Create a User Defined Route

But why use Virtual Network Gateway as a next hop? you may need to route traffic from a VNET to on premises through a Virtual Network Gateway. You may already be aware that one of the use cases of a Virtual Network Gateway is to connect your Azure environment to on-premises. Or you could use a Virtual Network Gateway to forward traffic from one VNET to another in a hub spoke topology. Example, a Virtual machine in VNET1 needs to communicate with a Virtual Machine in VNET 2 via a VNETHub. A Gateway located in the VNETHub could be used as a forwarder to route traffic from VNET1 to VNET2.

Next hop: Internet

Next hop of Internet is one we came across earlier. There was a default route of 0.0.0.0/0 with a next hop of Internet.  If you don’t override this route, Azure routes all traffic destined to IP addresses not included in the address prefix of any other route, to the Internet. You may wish to route the traffic to Network Virtual Appliance such as a Firewall or an inspection/logging appliance.

However, if needed, you can specify Internet as a next hop when you want to explicitly route traffic destined to an address prefix directly out to the Internet, or if you want traffic destined for Azure services with public IP addresses kept within the Azure backbone network. As explained earlier in this post, if traffic is destined for Azure services with public IP addresses, that traffic is kept within the Azure private backbone network and does not route out to the Internet.

Next hop: Virtual Appliance
A virtual appliance is a Virtual Machine that typically runs a network application, such as a firewall. You can use a next hop of Virtual Appliance also known as a Network Virtual Appliance (NVA) to route traffic to an Azure Firewall, Cisco Firewall, Palo Alto Firewall, Traffic Inspection Appliance, and more. Azure supports a number of third party appliances available from the Azure Market Place. You can also access the market place from the Azure portal at portal.azure.com


For example, as per the image below, we have a route table associated with VNET1/Subnet1 with a destination of 10.2.1.0/24 which belongs to VNET2. We have a HubVNet between both Virtual Networks. We know that VNET peering is non-transitive so we associate a route table to VNET1/Subnet1 instructing resources that if there is a requirement to communicate with resources in VNET2/SubnetA, the next hop is a virtual appliance. The virtual appliance in this case is an Azure Firewall located in HubVNet.



Next hop: None

Specify none when you want to drop traffic to an address prefix, rather than forwarding the traffic to a destination. None also represents a black hole. Packets forwarded to a black hole will not be forwarded at all. You will also notice a number of default routes with a next hop of none. This is because Azure creates system default routes for reserved address prefixes with None as the next hop type. If you decide to add another address prefix in your Virtual Network in future, Azure will amend the default route from none to Virtual Network. In the image below the option to specify a next hop address is greyed out as we’re dropping the traffic, it’s going no where, so we don’t need to specify an address.


Next hop: Virtual Network

We came across next hop of Virtual Network earlier. Can you remember where? It was a default system route created automatically which allows resources to communicate with each other inside a Virtual Network. We also have the option available when creating a User Defined Route with the Next hop address greyed out, as shown in the image below.


A question you may have, if there is already a system route which allows resources to communicate inside a Virtual Network, why would you want to create a user defined route with next hop of Virtual Network?

The default route we visited earlier allows all traffic within the IP address name space of 10.2.0.0/16 to communicate with each other. Azure automatically added this route for all subnets within the VNET, so if I created three subnets in my VNET, all subnets will include a default route with next hop to Virtual Network of 10.2.0.0/16. For example, I have the subnets below configured in VNET1,

Subnet1 10.2.1.0/24
Subnet2 10.2.2.0/24
Subnet3 10.2.3.0/24

According to the default route shown in the image below, all resources inside the three Subnets above can communicate with each other within VNET1. This means that traffic sent to any address between 10.2.0.1 and 10.2.255.254 would be routed within the Virtual Network. If I created additional Subnets in future, they would automatically be allowed to communicate with resources in Subnet1, Subnet2 and Subnet3.


But this does not answer why we would want to create a user defined route with next hop of Virtual Network. Let’s move onto a scenario with a possible use case.


Scenario

1. We have a requirement to force all traffic from 10.2.0.0/16 to a Network Virtual Appliance (NVA) for inspection and logging purposes. We must override the default route of next hop of Virtual Network. The virtual appliance is located in the same VNET, but in a different subnet. You may be thinking, we could add a route as follows, destination 10.2.0.0/16 with next hop of the IP address of the Virtual appliance.

Correct, but let’s add a little twist to this scenario,

2. Traffic destined for addresses between 10.2.0.1 and 10.2.0.254 (10.2.0.0/24) remains within SubnetA, rather than being routed to the virtual appliance, because there is no requirement for inspecting or logging the traffic. So the aim here is that if machines within SubnetA communicate with each other within the subnet, there is no requirement to route this traffic to a Virtual Appliance.

The diagram below sums up the above scenario. Traffic from SubnetC needs to be routed to the NVA located in SubnetB for packet inspection/logging. Traffic between VM1 and VM2 inside SubnetA is not routed to the NVA, however, if VM1 or VM2 need to communicate outside of SubnetA, such as communicating with VM3 or VM4 in SubnetC, then that traffic needs to be routed to the NVA first.

How would you accomplish this?


First, we create a User Defined Route with a destination of 10.2.0.0/16 and next hop of virtual appliance 10.2.1.4 as shown in the image below. This route would override the default system route of 10.2.0.0/16 with next hop of Virtual Network.


Below is an image showing what the routes would look like once we apply the route table to SubnetA. As you can see the default route has become invalid and all traffic for 10.2.0.0/16 now routes through an Network Virtual Appliance which has an IP address of 10.2.1.4.


This routes all traffic inside the Virtual network 10.2.0.0/16 to a Network Virtual appliance.

However, we have one more requirement. We don’t require traffic communicating inside Subnet A 10.2.1.0/24 (between Virtual Machines) to be routed to the NVA. But, according to the route we created earlier, all traffic from all subnets will be routed to the NVA.

To resolve scenario 2, we create another route as shown in the image below. The image shows a User Defined Route with destination of 10.2.0.0/24 (SubnetA) and next hop Virtual Network.


This is what the route table looks like now,


We now have two active routes. Traffic for the address prefix 10.2.0.0/16 is routed to the Virtual Appliance. Traffic for the address prefix 10.2.0.0/24 (SubnetA) keeps traffic within the Subnet.

So which user defined route will apply first as both meet the criteria? It’s the one with the longer prefix, in this case CIDR notation 10.2.0.0/24 has a longer prefix and takes priority when traffic is destined for IP’s in the range of 10.2.0.1 – 10.2.0.254 which belongs to SubnetA.

When outbound traffic is sent from a subnet, Azure selects a route based on the destination IP address, using the longest prefix match algorithm. For example, a route table has two routes: One route specifies the 10.2.0.0/24 address prefix, while the other route specifies the 10.2.0.0/16 address prefix. Azure directs traffic destined for 10.2.0.5 to the next hop type specified in the route with the 10.2.0.0/24 address prefix. This process occurs because 10.2.0.0/24 is a longer prefix than 10.2.0.0/16, even though 10.2.0.5 falls within both address prefixes.

So what if there was an IP of 10.2.1.7? Azure directs traffic destined for 10.2.1.7 to the next hop type specified in the route with the 10.2.0.0/16 address prefix. This process occurs because 10.2.1.7 isn’t included in the 10.2.0.0/24 address prefix, making the route with the 10.2.0.0/16 address prefix the longest matching prefix.

If you wish to learn more about longest prefix matching, the following article explains the process in detail. Longest Prefix Match Routing (I am not affiliated with this company).


How to associate a route table to a subnet
Once you have created a route table with your user defined routes, you can attach a route table to a subnet. A route table can be associated to zero or more subnets. Route tables aren’t associated to Virtual Networks. You must associate a route table to each subnet you want the route table associated to.

To associate a route table with a subnet,

1. Search and click Route tables


2. Click the route table you want to associate to a subnet

3. From the left pane, under Settings, click subnets.


4. Click Associate


5. Locate the Subnet and and click OK


and that’s it. I hope you found the post useful.

See you at the next one