Hey everyone,
I ran into a strange issue recently with our hub-spoke architecture in Azure, where the traffic doesn't seem to follow the expected path. We have an Azure Firewall in the hub VNet that's peered with a spoke. This firewall is mainly meant for managing ingress traffic.
In one of our spoke subnets, we host an Azure Container Apps environment. I noticed that a call from this Container App was failing, and interestingly, there's no Route Table associated with its subnet. I assumed the traffic would head straight out to the public internet instead.
However, after digging through NSG logs and running a request to ipfy from my Container App, I found that the traffic was actually egressing through the Azure Firewall IP instead! I've scoured the documentation and it mentions certain default routing behaviors, but Azure Firewall isn't explicitly mentioned. Have I stumbled upon an undocumented feature or is there something else going on?
Thanks for your help!
5 Answers
It might be that BGP routes got propagated somehow. I remember facing a similar issue when changes in the hub or on-premise setup affected all peered VNets. Keep that in mind!
Is your Azure Firewall set up in a VWAN with routing intent? That could definitely influence how traffic is directed. Worth checking!
Just a heads-up, Azure is phasing out default internet access. It's smart to route all internet egress traffic through your Azure Firewall or a NAT Gateway to future-proof your setup.
That's an odd one! But is there a specific reason you wouldn't want your traffic to go through the firewall? It might not be a bad thing after all.
What are the network settings for your Container App? I came across some similar concerns with Azure's networking that might help. Also, double-check that you haven’t set up any User Defined Routes (UDRs) directing traffic to a virtual appliance.
Related Questions
Cloudflare Origin SSL Certificate Setup Guide
How To Effectively Monetize A Site With Ads