Azure Networking Unplugged: Lessons from the Field

Greetings! Welcome to my contribution to this year’s Azure Back to School event. Thanks as always to the event organisers – Dwayne Natwick and Derek Smith.

This year I’ve opted to discuss one of my favourite areas which is of course – Azure Networking. I thought I would put together a post consisting of some of my top tips and best practices from having worked in this field for many years now. My hope is that you will find this post beneficial when it comes to designing or troubleshooting secure Azure network solutions, so without further ado let’s get into it!

Use a hub-and-spoke network topology

This is a key design decision that should be taken early in the design phase of any project. If you’ve already deployed your virtual networks then I would still encourage you to consider rearchitecting your VNETs if this is feasible to do so. Why? Quite simply, this one is tried and tested and should be a standard practice in most cases.

The concept is simple: Use a hub network as a central connectivity hub. This contains whatever you need to get to and from Azure and to secure the environment from a networking standpoint. Generally, this will be your firewall of choice and any gateways required. If you are using Azure Route Server, Azure Bastion or DNS services like DNS Private Resolver then these will usually be best placed in the hub VNET also but that’s about it from my experience. The concept of placing shared compute services into the hub VNET really doesn’t make much sense nowadays. There’s really no benefit to this and if anything, it makes your network less secure as you are increasing the attack surface of your main connectivity network that all of your endpoints connect to. It also increases routing complexity and the likelihood of introducing routing conflicts or asymmetric routing. All workloads, be they shared services or not should go into a spoke VNET and be peered to the hub VNET only.

How do I implement this:

To implement this approach, start by establishing a dedicated virtual network to serve as your hub. This is where you’ll deploy core network infrastructure such as Azure Firewall or a network virtual appliance, VPN or ExpressRoute gateways, Azure Bastion, Azure Route Server, and DNS Private Resolver—essentially, anything that provides connectivity or network security for your environment.

For each workload, environment, or business unit, create a separate spoke VNET, ensuring that spokes are not directly peered with each other unless there’s a specific need. If you are introducing a firewall in your hub VNET then you will need to add route tables to your subnets and steer traffic via user-defined routes to your firewall IP address as a next hop (more on this shortly).

I generally recommend using a dedicated route table and a dedicated NSG for every subnet and avoid re-using these resources. This layered approach ensures that your network remains secure, manageable, and scalable as your Azure footprint grows without having to reconfigure these resources as you scale.

1. Create the hub VNET:
   • Deploy a dedicated VNET for the hub.
   • Add subnets for Azure Firewall/NVA, VPN/ExpressRoute Gateway, Bastion, Route Server, and DNS Private Resolver as needed.
2. Create the spoke VNETs:
   • Deploy a separate VNET for each workload, environment, or business unit.
   • Spokes should not be peered directly with each other unless required for specific scenarios.
3. Configure user-defined routes (UDRs):
   • Add route tables and UDRs in spoke subnets to route all traffic through the hub’s firewall.
   • Set the next hop to the firewall’s IP address.
4. Apply NSGs and security policies:
   • Use Network Security Groups (NSGs) at the subnet level for additional segmentation.
   • Restrict direct Internet access from spokes; only allow via the firewall.

Route all of your traffic through the firewall

This is another decision that should be made early in the design phase of any project however, implementing this at a later point is not necessarily too difficult and worth considering. Quite often, I see firewalls in Azure being utilised only for North/South traffic, i.e. traffic entering or leaving Azure. Nowadays, it’s imperative that we implement Zero Trust solutions and in order to do this we really should be filtering all lateral traffic in Azure. Therefore, I recommend including East/West traffic in your firewall filtering. This can be all traffic flowing between your Azure VNETs or better still, all traffic within the same VNET also.

Key Benefits:

1. Centralised Security & Monitoring:
   Routing all traffic through a firewall gives you a single point to monitor, log, and control traffic. This is essential for auditing, compliance, and rapid incident response.
2. Consistent Policy Enforcement:
   You can enforce security policies centrally, reducing the risk of “shadow IT,” accidental open ports, or inconsistent rules across your environment.
3. Simplified Troubleshooting:
   With a single choke point, it’s much easier to trace flows, spot anomalies, and audit changes. You know exactly where to look when something isn’t working as expected.
4. Zero Trust Enablement:
   Filtering both North/South and East/West traffic is a foundational step for implementing Zero Trust networking in Azure.

How do I implement this:

This is easy to implement but unfortunately often very misunderstood. You will need to update your route tables and include user-defined routes for all VNETs. Unfortunately, there’s no cheat code here. You can’t use supernets as a “send all to firewall” and this is down to how Azure routing selects a route via longest prefix match.

A common misconception here is that adding a route to the firewall for the destination prefix ‘0.0.0.0/0’ will send all traffic to the firewall. This is not the case. Any routes that Azure has learned via the system, e.g. its own VNET or any peered VNETs or routes learned via BGP will be more specific and win here bypassing the firewall. Therefore if you really want all traffic going via the firewall, you need to add an equal or more specific route prefix which is usually the prefix of the address space of the destination network.

If you are ever unsure here then help is at hand, you can either view the effective routes of any Azure Virtual Machine (as long as you have sufficient permissions) and see for yourself the routes that Azure will use or better yet you can use the Next Hop tool in Network Watcher and Azure will tell you where the traffic is going.

1. Identify all VNETs and address spaces:
   • List every VNET and subnet that needs to route traffic through the firewall.
2. Create or update route tables:
   • For each spoke subnet, create a dedicated route table.
3. Add user-defined routes (UDRs):
   • Add a route for each destination network prefix (i.e. the prefix of the source VNET, any directly peered VNETs etc) and set the next hop to the firewall’s private IP address. If you add a route to 0.0.0.0/0 as well then this will provide a route path to all other networks and the Internet.
4. Associate route tables with subnets:
   • Associate the route table to the relevant spoke subnet for it to take effect.
5. Validate routing:
   • Use Effective Routes or Network Watcher’s Next Hop tool to confirm traffic is flowing through the firewall.

Avoid use of remote gateway and route propagation in spoke VNETs

This will depend on your design of course but let’s assume that you have a hub and spoke topology and you are routing everything via a firewall in your hub VNET as previously recommended. You also have a gateway in the hub VNET (which is where it should be also). This means that your firewall should be aware of all on premises BGP routes unless you have disabled gateway route propagation for some reason. Generally, if you are routing all traffic via your firewall then nothing else needs to learn these routes. Your Virtual Machines in your spoke VNETs only need to know how to get to the firewall and then the firewall takes over the routing (it’s a router in its own right) and will forward the traffic to the destination network. This means that you don’t need to enable the checkbox to use the hub VNET’s ‘remote gateway or route server’ in the VNET peering settings and you also don’t need to enable ‘Propagate gateway routes’ in the route table configuration of your spoke VNETs.

Key Benefits:

1. Centralised Security Enforcement:
   By ensuring that only the hub (and its firewall) learns on premises routes, you guarantee that all traffic between Azure and on premises is inspected and controlled at a single point. This prevents accidental bypassing of security controls.
2. Reduced Risk of Asymmetric Routing:
   Disabling route propagation in spokes avoids scenarios where traffic might take different paths on ingress and egress, which can break stateful inspection on firewalls and complicate troubleshooting.
3. Simplified Routing and Troubleshooting:
   With route propagation disabled, spoke VMs only need to know how to reach the firewall. This keeps routing tables simple and makes it much easier to trace and debug network flows.
4. Prevents Unintended Direct Connectivity:
   Not enabling remote gateway or route propagation in spokes ensures that spokes cannot directly learn on premises BGP routes, which could otherwise allow them to bypass the firewall and connect to on premises resources without inspection.

How do I implement this:

To ensure that all traffic between your Azure spokes and on premises resources is properly inspected and controlled, it’s important to keep gateway and route propagation settings tightly managed. The goal is to ensure that only the hub and specifically the firewall within the hub learns and acts on routing to on premises networks, while spoke VNETs remain simple and focused on sending all their traffic to the firewall.

1. Deploy your gateway and firewall in the hub VNET:
   • Place your VPN or ExpressRoute gateway in the hub, not in any spoke VNET.
   • Place your firewall of choice in the hub, not in any spoke VNET.
   • Ensure that gateway route propagation is enabled on the route table associated with the firewall subnet. This allows the firewall to learn on premises routes via BGP from the hub gateway.
2. Disable “Use Remote Gateway” on spoke VNET peerings:
   • When configuring VNET peering from each spoke to the hub, do not enable the “Use Remote Gateway” option. This prevents spokes from learning on premises routes via the hub’s gateway. Don’t worry; they can still use the gateway. This checkbox is just a route propagation setting which is not needed here.
3. Disable route propagation on spoke subnets:
   • In each spoke subnet’s route table, set “Propagate gateway routes” to “No.” This ensures that BGP-learned routes from on premises are not automatically added to spoke route tables. Technically, this is not necessary if #2 is implemented, but it’s good practice to perform this step anyway as an additional safeguard.
4. Configure UDRs in spokes to point to the firewall:
   • Add user-defined routes to the route table for each spoke subnet so that all traffic is sent to the firewall in the hub. Ensure you include either a specific route to each of your on premises networks or else add a route to 0.0.0.0/0 which will cover anything outside of Azure, i.e. on premises networks and the Internet.
   • The firewall will then handle further routing.
5. Verify effective routes:
   • Use the “Effective Routes” and “Network Watcher” on your Azure VMs in spoke subnets to confirm that only the necessary routes are present and that traffic is routed through the firewall.
6. Monitor and maintain:
   • Regularly review peering and route table configurations to ensure that no changes have inadvertently enabled route propagation or remote gateway usage in spokes. This is particularly important when creating new spoke VNETs.

Conclusion

Azure networking can be complex, but with the right design patterns and a focus on security, manageability, and scalability, you can avoid many of the common pitfalls I’ve seen in the field. Whether you’re building from scratch or rearchitecting an existing environment, sticking to proven approaches like hub-and-spoke, centralised firewalling, and careful route management will pay dividends in the long run – trust me on this!

Remember, there’s no “one size fits all” in cloud networking—every environment has its own quirks and requirements. But by applying these best practices and regularly reviewing your architecture, you’ll be well positioned to deliver simplified, secure, and future-proof solutions.

If you have any questions, want to share your own lessons learned, or just want to chat Azure networking, feel free to reach out or leave a comment. Thanks for reading, and enjoy the rest of Azure Back to School!