AKS Egress Traffic zu On-Prem wird von Azure Firewall ohne Logs verworfen (silent drop)

allo Community,

wir haben ein kritisches Konnektivitätsproblem, bei dem ausgehender Traffic von unserem AKS-Cluster zu einem On-Premises-Ziel von der Azure Firewall stillschweigend verworfen wird, und wir benötigen dringend Hilfe bei der Ursachenforschung.

Architektur-Überblick:

• Quelle: Ein AKS Cluster mit Pod-Netzwerk (10.x.x.x/16). Der Cluster befindet sich in einem Spoke-VNet.

Zentraler Hub: Das Spoke-VNet ist mit einem Secured Virtual Hub verbunden.

Firewall: Im Hub ist eine Azure Firewall integriert, die über Routing Intent den gesamten privaten Traffic absichert.

Ziel: Ein On-Premises-Netz, das über eine Site-to-Site VPN-Verbindung an den Hub angebunden ist.

Fehlerbild:

Funktionierender Pfad: Traffic von einer Azure-VM im gleichen Umfeld zum On-Prem-Ziel funktioniert problemlos. In den Azure Firewall Logs sind für diesen Traffic entsprechende "Allow"-Einträge sichtbar.

Fehlschlagender Pfad: Traffic von einem AKS-Test-Pod zum selben On-Prem-Ziel endet immer in einem Timeout.

Bisherige Analyse & Beweise:

Routing korrekt: Durch die Routing Intent-Policy geht sämtlicher privater Traffic, inkl. AKS-Pods, durch die Azure Firewall.

On-Prem-Seite OK: Da der Traffic von der VM funktioniert, sind VPN-Tunnel und On-Prem-Firewall-Konfig grundsätzlich in Ordnung.

Firewall-Regel existiert: In der Azure Firewall Policy gibt es eine explizite Allow-Regel vom Pod-CIDR zum On-Prem-Netz.

Der Knackpunkt – Keine Logs: Abfragen der Firewall Logs zeigen für Quell-IPs aus dem Pod-Netz absolut keine Einträge (weder Allow noch Deny), obwohl während der Tests kontinuierlich Traffic erzeugt wurde.

Schlussfolgerung: Alle Beweise deuten darauf hin, dass die Azure Firewall Pakete aus dem Pod-Netz zwar annimmt (aufgrund des erzwungenen Routings), diese aber stillschweigend verwirft, bevor sie von der Regel-Engine oder dem Logging-System erfasst werden.

Frage: Hatte jemand schon einmal ein ähnliches Problem? Gibt es bekannte Besonderheiten oder Konfigurationen in der Azure Firewall (insbesondere im Secured Virtual Hub), die dazu führen können, dass Traffic aus einem bestimmten Quell-CIDR ohne Logs verworfen wird?allo Community,

wir haben ein kritisches Konnektivitätsproblem, bei dem ausgehender Traffic von unserem AKS-Cluster zu einem On-Premises-Ziel von der Azure Firewall stillschweigend verworfen wird, und wir benötigen dringend Hilfe bei der Ursachenforschung.

Architektur-Überblick:

Quelle: Ein AKS Cluster mit Pod-Netzwerk (10.x.x.x/16). Der Cluster befindet sich in einem Spoke-VNet.

Zentraler Hub: Das Spoke-VNet ist mit einem Secured Virtual Hub verbunden.

Firewall: Im Hub ist eine Azure Firewall integriert, die über Routing Intent den gesamten privaten Traffic absichert.

Ziel: Ein On-Premises-Netz, das über eine Site-to-Site VPN-Verbindung an den Hub angebunden ist.

Fehlerbild:

Funktionierender Pfad: Traffic von einer Azure-VM im gleichen Umfeld zum On-Prem-Ziel funktioniert problemlos. In den Azure Firewall Logs sind für diesen Traffic entsprechende "Allow"-Einträge sichtbar.

Fehlschlagender Pfad: Traffic von einem AKS-Test-Pod zum selben On-Prem-Ziel endet immer in einem Timeout.

Bisherige Analyse & Beweise:

Routing korrekt: Durch die Routing Intent-Policy geht sämtlicher privater Traffic, inkl. AKS-Pods, durch die Azure Firewall.

On-Prem-Seite OK: Da der Traffic von der VM funktioniert, sind VPN-Tunnel und On-Prem-Firewall-Konfig grundsätzlich in Ordnung.

Firewall-Regel existiert: In der Azure Firewall Policy gibt es eine explizite Allow-Regel vom Pod-CIDR zum On-Prem-Netz.

Der Knackpunkt – Keine Logs: Abfragen der Firewall Logs zeigen für Quell-IPs aus dem Pod-Netz absolut keine Einträge (weder Allow noch Deny), obwohl während der Tests kontinuierlich Traffic erzeugt wurde.

Schlussfolgerung:
Alle Beweise deuten darauf hin, dass die Azure Firewall Pakete aus dem Pod-Netz zwar annimmt (aufgrund des erzwungenen Routings), diese aber stillschweigend verwirft, bevor sie von der Regel-Engine oder dem Logging-System erfasst werden.

Frage:
Hatte jemand schon einmal ein ähnliches Problem? Gibt es bekannte Besonderheiten oder Konfigurationen in der Azure Firewall (insbesondere im Secured Virtual Hub), die dazu führen können, dass Traffic aus einem bestimmten Quell-CIDR ohne Logs verworfen wird?