Der Fall: HTTPS vom Client zum App-Server
Unser Beispiel nutzt die Quell-IP 10.10.0.10, die Ziel-IP 10.20.0.10, TCP und Zielport 443. Der modellierte Pfad führt von Arbeitsplätze über die DMZ zur Serverzone. Die erste Firewall heißt FW-EDGE.
| Position | Quelle → Ziel | Dienst | Aktion |
|---|---|---|---|
| 1 | 10.10.0.0/24 → 10.20.0.10 | TCP 443 | Blockieren |
| 2 | 10.10.0.0/24 → 172.16.10.10 | TCP 443 | Erlauben |
| 3 | 10.10.0.0/24 → 10.20.0.10 | TCP 443 | Erlauben |
Regel 1 passt und blockiert. Regel 3 würde ebenfalls passen, wird aber nicht mehr ausgewertet. Regel 2 hat eine andere Zieladresse.
In wenigen Schritten selbst ausprobieren
- Öffne das Beispiel über den Button und wähle dort Beispielprojekt laden. Es wird als neues Projekt angelegt.
- Unter Pfadanalyse sind die genannten Adressen, TCP und Port 443 voreingestellt. Klicke auf Analysieren. Das Ergebnis ist „Blockiert“.
- Öffne Firewall-Regeln und wähle FW-EDGE. Verschiebe „HTTPS zum App-Server blockieren“ mit dem Abwärtspfeil zweimal hinter die Freigaberegel.
- Starte dieselbe Analyse erneut. Jetzt greifen zuerst die Freigabe auf FW-EDGE und anschließend die Freigabe auf FW-CORE: „Erlaubt“.
Was du daraus mitnehmen kannst
Eine spezifische Ausnahme hinter einer bereits passenden allgemeinen Regel bleibt wirkungslos. Prüfe beim Aufräumen deshalb immer Quelle, Ziel, Protokoll, Port und Reihenfolge gemeinsam. Deaktivierte Regeln werden übersprungen; ohne Treffer gilt die Standardaktion des Übergangs.