<\/p>\n\n\n\n
![\"\"](\"https:\/\/aidanfinn.com\/wp-content\/uploads\/2025\/02\/image-14-1024x333.png\")
<\/a><\/figure>\n\n\n\nLook at that beauty. You’ve got Azure networks in the middle (hub) and the right (spoke). And on the left is the remote network connected by some kind of site-to-site networking. The deployment even has the rarely used and pricey Network SKU of DDoS protection. Fantastic! Security is important!<\/p>\n\n\n\n
And to re-emphasise that security is important, the firewall (it doesn’t matter what brand you choose in this scenario) is slap-bang in the middle of the whole thing. Not only is that firewall important, but all traffic will have to go through it – nothing happens in that network without the firewall controlling it.<\/p>\n\n\n\n
Except, that the firewall is seeing absolutely no traffic at all.<\/p>\n\n\n\n
Packets Route Directly From Source To Destination<\/h2>\n\n\n\n
At this point, I’d like you to (re-)read my post, Azure Virtual Networks Do Not Exist<\/a>. There I explained two things:<\/p>\n\n\n\n In our above firewall scenario, let’s consider two routes:<\/p>\n\n\n\n The client sends traffic from the remote site across the site-to-site connection. The physical part of that network is the familiar flow that you’d see in tracert. Things change once that packet hits Azure. The site-to-site connection terminates in the NVA\/virtual network gateway. Now the packet needs to route to the service in the spoke. The scenario is that the NVA\/virtual network gateway is the source (in Azure networking) and the spoke service is the destination. The packet leaves the NIC of the NVA\/virtual network and routes directly (via the underlying physical Azure network) directly to the NIC of one of the load-balanced VMs in the spoke. The packet did not route through the firewall. The packet did not go through a default gateway. The packet did not go across some virtual peering wire. Repeat it after me:<\/p>\n\n\n\n Packets route directly from source to destination.<\/p>\n<\/blockquote>\n\n\n\n Now for the response. The VM in the spoke is going to send a response. Where will that response go? You might say “The firewall is in the middle of the diagram, Aidan. It’s obvious!”. Remember:<\/p>\n\n\n\n Packets route directly from source to destination.<\/p>\n<\/blockquote>\n\n\n\n In this scenario, the destination is the NVA\/virtual network gateway. The packet will leave the VM in the spoke and appear in the NIC of the NCA\/virtual network gateway.<\/p>\n\n\n\n It doesn’t matter how pretty your Visio is (Draw.io<\/a> is a million times better, by the way – thanks for the tip, Haakon). It doesn’t matter what your intention was. Packets … route directly from source to destination.<\/p>\n\n\n\n You might be saying, “Duh, Aidan, User-Defined Routes (UDRs) in Route Tables will solve this”. You’re sort of on the right track – maybe even mostly there. But I know from talking to many people over the years, that they completely overlook that there are two (I’d argue three) other sources of routes in Azure. Those other routes are playing a role here that you’re not appreciating and if you do not configure your UDRs\/Route Tables correctly you’ll either change nothing or break your network.<\/p>\n\n\n\n In the on-premises world, we use cables to connect network appliances. You can’t get from one top-of-rack switch\/VLAN to another without going through a default gateway. That default gateway can be a switch, a switch core, a router, or a firewall. Connections are made possible via cables. Just like water flow is controlled by pipes, packets can only transit cables that you lay down.<\/p>\n\n\n\n If you read my Azure Virtual Networks Do Not Exist<\/a> post then you should understand that NICs in a VNet or in peered VNets are a mesh of NICs that can route directly to each other. There is no virtual network cabling; this means that we need to control the flows via some other means and that means is routing.<\/p>\n\n\n\n One must understand the end state, how routing works, and how to manipulate routing to end up in the desired end state. That’s the obvious bit – but often overlooked is that the resulting security model should be scaleable, manageable, and predictable.<\/p>\n","protected":false},"excerpt":{"rendered":" In this post, I want to explain why routing is so important in Microsoft Azure. Without truly understanding routing, and implementing predictable and scaleable routing, you do not have a secure network. What one needs to understand is that routing is the security cabling of Azure. My Favourite Interview Question Now and then, I am … Continue reading “Routing Is The Security Cabling of Azure”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":18983,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"_wpcom_ai_launchpad_first_post":false,"footnotes":""},"categories":[5],"tags":[170,242,324,326,289,281],"class_list":["post-24102","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-azure","tag-azure","tag-firewall","tag-routing","tag-user-defined-routing","tag-virtual-network","tag-vnet"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n
![\"\"](\"https:\/\/aidanfinn.com\/wp-content\/uploads\/2025\/02\/image-2-1024x421.png\")
<\/a><\/figure>\n\n\n\n\n
\n
\n
User-Defined Routes – Right?<\/h2>\n\n\n\n
Routing Is The Security Cabling of Azure<\/h2>\n\n\n\n