Les Geleerd: Probleemoplossing bij Azure Firewall, Application Gateway en Route Tabellen

Azure-netwerken kunnen een complex ecosysteem zijn, vooral wanneer je werkt met Application Gateways (AppGW), firewalls en routeringsconfiguraties. Een recent probleemoplossingsproces binnen onze eigen omgeving heeft waardevolle inzichten opgeleverd in mogelijke valkuilen en best practices bij het instellen van Azure-netwerkcomponenten. Deze blog beschrijft de inzichten die zijn opgedaan bij het oplossen van een probleem waarbij verkeer via een firewall werd gerouteerd, wat resulteerde in HTTP 502-fouten. 

Het probleem 

In dit scenario zijn een Application Gateway (AppGW) en een backendserver binnen hetzelfde Virtual Network (VNet) geïmplementeerd, waarbij het verkeer via een Azure Firewall werd gerouteerd met User Defined Routes (UDR’s). Volgens de documentatie van Microsoft zou deze opzet moeten werken. Echter, na het implementeren van de route-tabellen begon het systeem HTTP 502-fouten terug te geven. 

Bevindingen 

• De AppGW kon de backend server bereiken, maar de antwoorden kwamen niet terug. De verbindingstest van de Application Gateway gaf aan dat de verbinding succesvol was, maar het werkelijke verkeer faalde. 
• De firewalllogs toonden geen geblokkeerd verkeer, wat suggereert dat de antwoorden de firewall nooit bereikten
• Een tweede backend pool in een apart VNet werkte goed, wat aangaf dat het probleem specifiek was voor de intra-VNet routing. 

Probleemanalyse en onderzoek binnen de community 

De probleemoplossing omvatte meerdere leden uit de community en richtte zich op het analyseren van verschillende belangrijke gebieden: 

Route-tabellen controleren: 

• Controleren of de UDR’s correct waren geconfigureerd en/ of specifiekere routes de standaardroutes overschreven. 
• Verifiëren of het verkeer naar de volgende hop (de private IP van de firewall) in beide richtingen werd gestuurd.
• Bevestigen dat de routeringsintentie in Virtual WAN (vWAN) was ingesteld op privéverkeer.

Firewalllogs en effectieve routes: 

• Flowlogs en effectieve routes op de NIC van de VM werden bekeken om te bevestigen hoe de pakketten zich bewogen. 
• Controleren of het verkeer de firewall überhaupt bereikte, wat in dit geval niet leek te gebeuren.
• Asymmetrische routing werd als een mogelijke oorzaak beschouwd.

DNS- en applicatieregels: 

• Zorgen dat de aangepaste DNS correct de backend IP-adressen kon resolven. 
• Controleren of de firewall de DNS resolving beïnvloedde
• De health-probes en errorlogs van de Application Gateway werden onderzocht op fouten.

Regelvolgorde en verwerkingslogica van de firewall: 

• De verwerkingslogica van de firewallregels van Microsoft stelt dat regels in een specifieke volgorde worden toegepast: 
• NAT-regels → Netwerkregels → Applicatieregel
• Een belangrijke observatie was dat er geen netwerkregel bestond voor de vereiste communicatie
• In plaats daarvan werd het verkeer onterecht door een applicatieregel afgehandeld, die het verkeer naar de front-end domeinnaam van de AppGW stuurde.
• Dit leidde tot een DNS lookup die naar de AppGW zelf werd gerouteerd, wat resulteerde in een lus en de waargenomen 502-fouten.

De oplossing 

Na meerdere rondes van debuggen en een grondige analyse van de routeringsconfiguraties ontdekten we dat een cruciale netwerkregel ontbrak in de firewall. Deze regel had expliciet verkeer van de AppGW-subnet naar de backend VM-subnet moeten toestaan. In de afwezigheid hiervan, viel de firewall terug op een applicatieregel, die de front-end domeinnaam terug resolvde naar de AppGW en per ongeluk een misroute veroorzaakte. Het toevoegen van de juiste netwerkregel aan de firewall loste het probleem onmiddellijk op. 

Belangrijke Lessen 

Het is belangrijk om ervoor te zorgen dat netwerkregels voorrang krijgen boven applicatieregels bij het beheren van verkeer tussen subnets. Een grondige controle van de firewalllogs is cruciaal, omdat de aanwezigheid of afwezigheid van logs vaak wijst op een routeringsprobleem in plaats van een firewall blok. In dit geval werd het probleem geïdentificeerd toen we zagen dat alleen het front-end domein als applicatie-hit werd geregistreerd, terwijl geen van de andere domeinen van de Application Gateway werd weergegeven in de applicatieregel-logs. Het gebruik van effectieve routes op subnets is essentieel om het verwachte verkeersverloop te verifiëren. Het gedrag van DNS-resolutie moet zorgvuldig worden beoordeeld, vooral wanneer firewalls verantwoordelijk zijn voor naamoplossingen. Ten slotte, als Azure Virtual WAN (vWAN) wordt gebruikt, is het belangrijk te begrijpen hoe dit interacteert met routeringsintentie en firewallregels. 

Tot slot 

Deze ervaring benadrukte hoe onderling verbonden de Azure-netwerkcomponenten zijn en hoe verkeerde configuraties op één laag onverwacht gedrag kunnen veroorzaken op een andere laag. De probleemoplossing omvatte het systematisch uitsluiten van mogelijke oorzaken door middel van flowlogs, route-tabellen en verwerkingslogica van regels om tot de oplossing te komen. Een speciale dank aan alle bijdragers die betrokken waren bij het debuggen van dit probleem en zo de kracht van gezamenlijke probleemoplossing in cloudnetwerken aantonen! Voor meer informatie over de verwerkingslogica van Azure Firewall-regels, verwijzen we naar de officiële documentatie van Microsoft. 

Happy troubleshooting!