Unraveling the Mystery of Azure’s Numerous Default Routes

Have you ever noticed that when you create a subnet in Azure without attaching a route table, you still see a bunch of default routes? Curious about what 25.176.0.0/13 or 198.18.0.0/15 are, and why their next hop is set to None?

Understanding the Situation

Imagine you’ve just launched a virtual machine and placed it in a subnet that doesn’t have a custom Route Table. When you inspect the VM’s network interface card (NIC) and look at the Effective Routes, you might anticipate finding just the standard private address ranges (like 10.0.0.0/8, 172.16.0.0/12) and a generic default route (0.0.0.0/0). Instead, you get a long list like this:

What’s all this about? At first glance, those ranges can look bewildering. Here’s a summary of the unusual addresses, excluding the main default route and your VNet’s IP range:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
100.64.0.0/10
104.146.0.0/17
104.147.0.0/16
127.0.0.0/8
157.59.0.0/16
198.18.0.0/15
20.35.252.0/22
23.103.0.0/18
25.148.0.0/15
25.150.0.0/16
25.152.0.0/14
25.156.0.0/16
25.159.0.0/16
25.176.0.0/13
25.184.0.0/14
25.4.0.0/14
40.108.0.0/17
40.109.0.0/16

Next Hop: None

One thing you’ll notice is that most of these routes have their next hop set to None.

Azure networking is powered by software rather than traditional routers. When your VM sends traffic, the Azure NIC (and its underlying fabric) determines the optimal path. If a route says the next hop is None, that simply means the traffic gets dropped—it never leaves the VM, almost like vanishing into a black hole. This behavior can act like a basic firewall, silently discarding traffic you don’t want to allow.

If you check Microsoft’s documentation, you’ll find more context and explanations.

RFC-1918 Private Address Spaces

You’re probably familiar with these classic private IP address blocks:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

These are intended for internal networking only. So, why does Azure block traffic to them by default? The logic is: if there’s no explicit route to these ranges, there’s usually no legitimate reason for VMs to communicate with them outside their current VNet. As a security-first measure, Azure drops such traffic unless specific routing is configured.

Should you use some of these ranges within your VNet or linked VNets, Azure will automatically prefer those local routes over the broader drop routes.

RFC-6598 Carrier-Grade NAT

The address block 100.64.0.0/10 is reserved for use by ISPs providing carrier-grade NAT services—essentially used by providers connecting customer equipment to their infrastructure. Since you likely don’t need to communicate with these service provider addresses, Azure blocks this range by default.

Microsoft-Owned IP Ranges

The range 20.35.252.0/22 is registered in Redmond, Microsoft’s headquarters. Other subnets in the 20.235.x.x space are designated for Exchange Online U.S. Government services. This could imply that Microsoft uses these routes to shield sensitive cloud services from potential tenant attacks by defaulting their next hop to None.

104.146.0.0/17 and 104.147.0.0/16 also belong to Microsoft, located in Boydton, Virginia, which hosts the Azure East US region. The exact usage remains unclear, but these seem associated with Office 365 or SharePoint Online.

The 157.59.0.0/16 subnet is another Microsoft block in Redmond and, according to rare documentation, relates to internal cluster communications.

23.103.0.0/18 is another Microsoft-held subnet, widely used by different Exchange Online services, both for the public and government.

Then there’s a series of mysterious blocks:

• 25.148.0.0/15
• 25.150.0.0/16
• 25.152.0.0/14
• 25.156.0.0/16
• 25.159.0.0/16
• 25.176.0.0/13
• 25.184.0.0/14
• 25.4.0.0/14

All these are registered to Microsoft in London, though their specific uses are not public knowledge. Based on their consistent routing behavior, they’re likely tied to internal Microsoft services or protected cloud infrastructure.

Finally, 40.108.0.0/17 and 40.109.0.0/16 are assigned to SharePoint Online and OneDrive, ensuring that only allowed traffic can reach these services.

Other Special Network Ranges

Certain address blocks are tightly defined by standards such as RFC-5735.

127.0.0.0/8 is the well-known loopback range. The standard says that none of these addresses should ever be routed on the public network, so blocking them makes sense.

198.18.0.0/15 is reserved for network device testing, often used in industry labs and not meant for global internet forwarding or routing.

How User-Defined Routes (UDRs) Change Things

If you introduce your own Route Table to the subnet—even a simple User-Defined Route like:

• Prefix: 0.0.0.0/0
• Next Hop: Internet

When you look at the Effective Routes on your VM, you’ll notice that Azure removes its own default 0.0.0.0/0 route and applies your custom rule, while still leaving the other special-purpose routes untouched.

But, if you adjust the UDR just a bit:

• Prefix: 0.0.0.0/0
• Next Hop: Virtual Appliance
• Next Hop IP Address: {Your firewall’s private IP}

Suddenly, Azure drops all those built-in block routes! It seems that when you set up an overarching firewall route for all outbound traffic (using 0.0.0.0/0), Azure defers to your firewall for filtering and security, trusting that you’ll block unwanted traffic appropriately. However, if you specify any other prefix, Azure reinstates its own internal block routes as a safeguard.