# 11.5 Fehlersuche bei Firewalls, NAT und DMZ Bei Problemen mit Firewalls, NAT und DMZ reicht es nicht, nur zu prüfen, ob ein Server grundsätzlich erreichbar ist. Man muss die komplette Verbindungskette prüfen: Client DNS Routing Firewall-Regel NAT-Regel Zielsystem Dienst Rückweg Logs Merksatz: Firewall-Fehlersuche bedeutet: Quelle, Ziel, Port, Richtung, NAT und Logs prüfen. --- **Grundidee der Fehlersuche** Bei Firewall- und NAT-Problemen ist die wichtigste Frage: Wo wird der Verkehr unterbrochen? Dazu prüft man Schritt für Schritt: Kommt die Anfrage beim richtigen Ziel an? Wird sie erlaubt oder blockiert? Wird sie richtig übersetzt? Antwortet der Dienst? Kommt die Antwort zurück? Merksatz: Nicht raten, sondern den Weg der Verbindung nachvollziehen. --- **Die wichtigsten Angaben vor der Fehlersuche** Vor der Fehlersuche braucht man genaue Informationen. Wichtige Fragen: Wer ist die Quelle? Was ist das Ziel? Welcher Dienst wird genutzt? Welcher Port wird genutzt? TCP oder UDP? In welche Richtung geht die Verbindung? Intern oder extern? Gibt es NAT? Gibt es eine DMZ? Gibt es einen Reverse Proxy? Welche Fehlermeldung erscheint? Merksatz: Ohne Quelle, Ziel, Port und Richtung ist Firewall-Fehlersuche ungenau. --- **Quelle bestimmen** Die Quelle ist das System, das die Verbindung startet. Beispiele: Client im LAN externer Benutzer im Internet Server in der DMZ VPN-Client Monitoring-Server Admin-PC Anwendungssystem Wichtig: Die tatsächliche Quell-IP kann durch NAT verändert werden. Merksatz: Quelle = wer startet die Verbindung? --- **Ziel bestimmen** Das Ziel ist das System oder der Dienst, der erreicht werden soll. Beispiele: Webserver Datenbankserver Reverse Proxy Mailgateway DNS-Server SMB-Freigabe VPN-Gateway RDP-Server Wichtig: Bei DNS-Namen muss geprüft werden, auf welche IP-Adresse der Name wirklich zeigt. Merksatz: Ziel = welches System soll erreicht werden? --- **Port und Protokoll bestimmen** Ein Port allein reicht nicht. Man muss auch wissen: TCP oder UDP? Beispiele: | Dienst | Protokoll | |---|---| | HTTPS | TCP 443 | | DNS | UDP/TCP 53 | | NTP | UDP 123 | | SMB | TCP 445 | | SSH | TCP 22 | | RDP | TCP 3389 | | SNMP | UDP 161 | | HTTP/3 | UDP 443 | Merksatz: TCP 443 und UDP 443 sind unterschiedliche Dinge. --- **Richtung bestimmen** Firewall-Regeln sind richtungsabhängig. Beispiele: LAN → WAN WAN → DMZ DMZ → LAN VPN → Servernetz Managementnetz → DMZ Gastnetz → Internet Ein häufiger Fehler ist, eine Regel in der falschen Richtung anzulegen. Merksatz: Regelrichtung nach dem Verbindungsaufbau bestimmen. --- **Zonen bestimmen** Viele Firewalls arbeiten mit Zonen. Beispiele: LAN WAN DMZ VPN Gastnetz IoT-Netz Servernetz Managementnetz Eine Regel muss zur richtigen Zone passen. Beispiel: WAN → DMZ ist nicht dasselbe wie DMZ → WAN. Merksatz: Firewall-Regeln gelten zwischen Zonen oder Interfaces. --- **DNS zuerst prüfen** Viele vermeintliche Firewall-Probleme sind eigentlich DNS-Probleme. Beispiele: Domain zeigt auf falsche öffentliche IP. Interner DNS zeigt auf externe IP. Split DNS ist falsch. DNS-Cache enthält alten Eintrag. AAAA-Record zeigt auf nicht erreichbare IPv6-Adresse. CNAME zeigt auf falschen Namen. Merksatz: Falsche DNS-Auflösung führt zur falschen Zieladresse. --- **Routing prüfen** Firewall-Regeln helfen nicht, wenn kein gültiger Weg zum Ziel existiert. Zu prüfen: Gibt es eine Route zum Zielnetz? Gibt es einen Rückweg? Ist das richtige Gateway eingetragen? Geht der Rückverkehr über dieselbe Firewall? Gibt es asymmetrisches Routing? Ist ein VPN-Routing beteiligt? Merksatz: Routing bestimmt den Weg, Firewall erlaubt oder blockiert ihn. --- **NAT prüfen** Wenn NAT beteiligt ist, muss geprüft werden: Wird die richtige Quelladresse übersetzt? Wird die richtige Zieladresse übersetzt? Stimmt der externe Port? Stimmt der interne Port? Stimmt TCP oder UDP? Zeigt NAT auf das richtige interne Ziel? Gibt es mehrere NAT-Regeln? Greift eine alte Regel vorher? Merksatz: NAT-Fehler entstehen oft durch falsches Ziel, falschen Port oder falsche Reihenfolge. --- **Firewall-Regel prüfen** Bei der Firewall-Regel prüft man: Quelle korrekt? Ziel korrekt? Dienst korrekt? Protokoll korrekt? Port korrekt? Richtung korrekt? Zone korrekt? Regel aktiv? Regel an richtiger Position? Logging aktiv? Wird die Regel überhaupt getroffen? Merksatz: Die tatsächlich getroffene Regel ist wichtiger als die gedachte Regel. --- **Regelreihenfolge prüfen** Viele Firewalls arbeiten von oben nach unten. Die erste passende Regel entscheidet. Problem: Eine allgemeine Blockregel kann eine spätere Erlaubnisregel verdecken. Beispiel: Regel 1: DMZ → LAN any blockieren Regel 2: DMZ-Webserver → DB-Server TCP 5432 erlauben Wenn Regel 1 zuerst greift, funktioniert Regel 2 nicht. Merksatz: Spezifische Erlaubnis vor allgemeine Blockregel setzen. --- **Logs prüfen** Firewall-Logs sind bei der Fehlersuche besonders wichtig. Sie zeigen: Quelle Ziel Port Protokoll Aktion Regelname Zeit Interface Zone NAT-Übersetzung Typische Aktionen im Log: allowed denied dropped rejected Merksatz: Logs zeigen, ob die Firewall erlaubt oder blockiert. --- **Keine Logs sichtbar** Wenn keine Logs sichtbar sind, kann das bedeuten: Verkehr kommt gar nicht bei der Firewall an. Falsche Firewall wird geprüft. Falsches Interface wird geprüft. Logging ist für Regel deaktiviert. DNS zeigt auf anderes Ziel. Routing geht anderen Weg. Client sendet gar keine Anfrage. Provider oder vorgeschaltetes Gerät blockiert. Merksatz: Kein Logeintrag heißt nicht automatisch: Firewall ist nicht beteiligt. --- **Dienst auf Zielsystem prüfen** Wenn Firewall und NAT korrekt aussehen, muss der Dienst selbst geprüft werden. Fragen: Läuft der Dienst? Lauscht der Dienst auf dem richtigen Port? Lauscht der Dienst auf der richtigen IP-Adresse? Blockiert die Host-Firewall? Gibt es Anwendungslogs? Antwortet der Dienst korrekt? Ist das Zertifikat passend? Ist die Anwendung richtig konfiguriert? Merksatz: Erlaubter Port heißt nicht, dass der Dienst funktioniert. --- **Host-Firewall prüfen** Neben der zentralen Firewall kann auch das Zielsystem selbst blockieren. Beispiele: Windows Defender Firewall Linux nftables iptables ufw firewalld lokale Sicherheitssoftware Cloud Security Group Typisches Fehlerbild: Netzwerkfirewall erlaubt, aber Zielsystem lehnt ab oder antwortet nicht. Merksatz: Auch die lokale Firewall des Zielsystems prüfen. --- **Rückweg prüfen** Eine Verbindung braucht Hinweg und Rückweg. Wenn der Rückweg fehlt, funktioniert die Verbindung nicht. Mögliche Ursachen: falsches Gateway falsche Route asymmetrisches Routing NAT-Zuordnung fehlt Antwort geht an falsche Firewall Zielsystem antwortet über anderes Interface Merksatz: Verbindung funktioniert nur, wenn Anfrage und Antwort den passenden Weg haben. --- **Asymmetrisches Routing** Asymmetrisches Routing bedeutet: Hinweg und Rückweg laufen über unterschiedliche Wege. Bei Stateful Firewalls ist das problematisch, weil die Firewall den Verbindungszustand nur auf einem Weg sieht. Folge: Antwortpakete können als ungültig blockiert werden. Merksatz: Stateful Firewalls brauchen zusammenpassenden Hin- und Rückweg. --- **Typisches Szenario: Externer Webdienst nicht erreichbar** Beispiel: Benutzer im Internet kann https://wiki.firma.de nicht öffnen. Prüfreihenfolge: 1. DNS zeigt auf richtige öffentliche IP? 2. Öffentliche IP gehört wirklich zum Anschluss? 3. Kein CGNAT? 4. Portweiterleitung TCP 443 korrekt? 5. Firewall-Regel WAN → DMZ oder WAN → Reverse Proxy korrekt? 6. Reverse Proxy erreichbar? 7. Backend erreichbar? 8. Zertifikat gültig? 9. Webserver-Logs prüfen. 10. Firewall-Logs prüfen. Merksatz: Öffentlicher Webdienst braucht DNS, NAT, Firewall, Proxy, Backend und Zertifikat. --- **Typisches Szenario: Intern funktioniert, extern nicht** Wenn ein Dienst intern funktioniert, aber extern nicht, liegen Ursachen oft bei: externem DNS öffentlicher IP Portweiterleitung Firewall-Regel WAN → DMZ CGNAT Providerblockade Reverse Proxy Zertifikat Dienstbindung nur auf interne IP Merksatz: Intern funktioniert, extern nicht: externe Erreichbarkeit prüfen. --- **Typisches Szenario: Extern funktioniert, intern nicht** Wenn ein Dienst extern funktioniert, aber intern über denselben Namen nicht, liegen Ursachen oft bei: Hairpin NAT fehlt Split DNS fehlt internes DNS zeigt falsch interne Firewall blockiert Zertifikat passt intern nicht interner Client geht falschen Weg Merksatz: Extern funktioniert, intern nicht: Hairpin NAT oder Split DNS prüfen. --- **Typisches Szenario: Portweiterleitung funktioniert nicht** Mögliche Ursachen: - falsche öffentliche IP - CGNAT - Double NAT - NAT-Regel fehlt - NAT-Regel zeigt auf falschen Host - falscher externer Port - falscher interner Port - TCP/UDP verwechselt - Firewall-Regel fehlt - Host-Firewall blockiert - Dienst läuft nicht - DNS zeigt falsch - Test aus internem Netz ohne Hairpin NAT Merksatz: Portweiterleitung braucht korrekte öffentliche IP, NAT, Firewall und Dienst. --- **Typisches Szenario: 502 Bad Gateway** Ein 502-Fehler tritt häufig bei Reverse Proxys auf. Mögliche Ursachen: Backend läuft nicht. Backend-Port falsch. Backend-Protokoll falsch. DNS-Name des Backends falsch. Container oder Server nicht erreichbar. Firewall blockiert Proxy → Backend. Backend antwortet ungültig. TLS zum Backend falsch konfiguriert. Merksatz: 502 bedeutet oft: Proxy erreicht Backend nicht korrekt. --- **Typisches Szenario: Zugriff auf Datenbank aus DMZ geht nicht** Beispiel: Webserver in DMZ soll Datenbank im Servernetz erreichen. Prüfen: Quelle: Webserver in DMZ Ziel: Datenbankserver im Servernetz Dienst: Datenbankport Richtung: DMZ → Servernetz Zusätzlich: Datenbankdienst läuft? Datenbank lauscht auf richtiger IP? Host-Firewall erlaubt? Benutzerrechte in Datenbank korrekt? Rückweg vorhanden? Merksatz: Datenbankzugriff aus DMZ braucht enge, gezielte Regeln. --- **Typisches Szenario: VPN-Benutzer erreicht internen Server nicht** Mögliche Ursachen: - VPN-Verbindung nicht korrekt aufgebaut - VPN-Client bekommt falsche IP - Route zum internen Netz fehlt - Firewall-Regel VPN → Servernetz fehlt - DNS für interne Namen fehlt - Split Tunnel falsch - Zielserver-Firewall blockiert - Benutzergruppe nicht berechtigt - NAT im VPN falsch Merksatz: VPN-Probleme mit Adresse, Route, DNS, Firewall und Berechtigung prüfen. --- **Typisches Szenario: Gastnetz erreicht LAN** Das ist ein Sicherheitsproblem. Mögliche Ursachen: - Firewall-Regel zu offen - falsche Zonen-Zuordnung - VLAN falsch konfiguriert - Gastnetz und LAN im selben Netz - Any-Any-Regel - Routing ohne Filter - alte Testregel vergessen Merksatz: Gastnetz darf nicht ins interne LAN führen. --- **Typisches Szenario: IoT-Geräte erreichen interne Server** Auch das kann ein Risiko sein. Mögliche Ursachen: - IoT-Netz nicht getrennt - Firewall-Regel zu breit - Geräte im falschen VLAN - mDNS oder Broadcast-Freigaben unkontrolliert - Any-Regel aktiv - fehlende Segmentierung Besser: IoT → Internet nur nötig IoT → LAN blockieren Admin-Netz → IoT gezielt erlauben Merksatz: IoT-Geräte nur kontrolliert kommunizieren lassen. --- **Typisches Szenario: DNS funktioniert nicht** Mögliche Ursachen: - UDP 53 blockiert - TCP 53 blockiert - falscher DNS-Server - DNS-Server nicht erreichbar - Firewall erlaubt nur externe DNS - interne DNS-Zone fehlt - Split DNS falsch - DNS-Cache veraltet - DHCP verteilt falschen DNS Merksatz: DNS braucht je nach Fall UDP und TCP 53. --- **Typisches Szenario: NTP funktioniert nicht** Mögliche Ursachen: - UDP 123 blockiert - falscher Zeitserver - DNS zum Zeitserver fehlerhaft - Zeitabweichung zu groß - NTP-Dienst läuft nicht - Firewall erlaubt nur TCP statt UDP - VM-Zeitquelle widerspricht NTP Folgeprobleme: Zertifikatsfehler Kerberos-Probleme falsche Logs Monitoringfehler Merksatz: NTP-Probleme können viele Folgefehler erzeugen. --- **Typisches Szenario: RDP funktioniert nicht** Mögliche Ursachen: - TCP 3389 blockiert - RDP am Zielsystem deaktiviert - Benutzer nicht berechtigt - Zielsystem ausgeschaltet - VPN nicht verbunden - Firewall-Regel fehlt - Host-Firewall blockiert - NLA-Problem - DNS zeigt falsch Sicherheit: RDP nicht direkt aus dem Internet veröffentlichen. Merksatz: RDP besser über VPN oder Gateway nutzen. --- **Typisches Szenario: SSH funktioniert nicht** Mögliche Ursachen: - TCP 22 blockiert - SSH-Dienst läuft nicht - SSH läuft auf anderem Port - falscher Benutzer - falscher Schlüssel - Passwortlogin deaktiviert - Host-Firewall blockiert - Zugriff nur aus Managementnetz erlaubt - Fail2ban blockiert Quelle Merksatz: SSH mit Port, Dienst, Benutzer, Schlüssel und Firewall prüfen. --- **Typisches Szenario: Mailserver empfängt keine Mails** Mögliche Ursachen: - MX-Record falsch - DNS zeigt falsch - TCP 25 blockiert - NAT-Regel fehlt - Firewall-Regel fehlt - Mailgateway down - Spamfilter lehnt ab - Zertifikat oder TLS-Problem - Provider blockiert Port 25 - Mailserver nicht zuständig für Domain Merksatz: Mail-Empfang braucht MX, DNS, SMTP, Firewall und Mailserverkonfiguration. --- **Typisches Szenario: Anwendung funktioniert nur teilweise** Mögliche Ursachen: - Hauptport erlaubt, Zusatzport fehlt - API erreichbar, Datenbank nicht erreichbar - Weboberfläche erreichbar, WebSocket blockiert - DNS erlaubt, NTP blockiert - FTP-Login geht, Datenports fehlen - Authentifizierung geht, LDAP-Gruppenabfrage blockiert Merksatz: Manche Anwendungen brauchen mehr als nur einen Port. --- **TCP und UDP nicht verwechseln** Ein häufiger Fehler ist, nur den Port zu betrachten. Beispiele: DNS kann UDP 53 und TCP 53 brauchen. NTP nutzt UDP 123, nicht TCP 123. SNMP nutzt UDP 161, nicht TCP 161. HTTP/3 nutzt UDP 443, während HTTPS klassisch TCP 443 nutzt. Merksatz: Portnummer ohne Protokoll ist unvollständig. --- **ICMP bei Fehlersuche** ICMP wird oft für Diagnose genutzt. Beispiele: Ping Traceroute Ziel nicht erreichbar Time Exceeded Fragmentierung nötig ICMP komplett zu blockieren, kann Fehlersuche erschweren und Netzwerkprobleme verdecken. Merksatz: ICMP ist mehr als Ping. --- **Ping reicht nicht aus** Ping zeigt nur, ob ICMP-Echo funktioniert. Ping sagt nicht: ob TCP 443 offen ist ob HTTP funktioniert ob Anmeldung klappt ob DNS korrekt ist ob Zertifikat passt ob Anwendung gesund ist Merksatz: Ping ist nur ein erster Hinweis, kein vollständiger Diensttest. --- **Porttest reicht nicht aus** Ein erfolgreicher Porttest zeigt: Zielport ist erreichbar. Er zeigt nicht automatisch: Anwendung antwortet korrekt Authentifizierung klappt Datenformat stimmt Zertifikat passt Reverse Proxy leitet richtig weiter Benutzer hat Rechte Merksatz: Offener Port heißt nicht: Anwendung funktioniert. --- **Typische Testwerkzeuge** | Werkzeug | Zweck | |---|---| | ping | einfache Erreichbarkeit prüfen | | traceroute / tracert | Weg zum Ziel prüfen | | nslookup | DNS prüfen | | dig | DNS detaillierter prüfen | | curl | HTTP/HTTPS/API testen | | nc | TCP/UDP-Port testen | | Test-NetConnection | Windows-Porttest | | openssl s_client | TLS-Zertifikat prüfen | | tcpdump | Paketmitschnitt | | Wireshark | Paketmitschnitt analysieren | | Firewall-Log | erlaubten oder blockierten Verkehr prüfen | | Serverlog | Dienstfehler prüfen | Merksatz: Werkzeug nach Fragestellung auswählen. --- **Paketmitschnitt** Ein Paketmitschnitt kann zeigen, ob Verkehr wirklich ankommt. Man sieht zum Beispiel: ARP DNS TCP-Handshake TLS-Handshake ICMP DHCP Wiederholungen Timeouts Reset-Pakete Wichtig: Bei TLS sieht man den Inhalt nicht einfach im Klartext. Merksatz: Paketmitschnitt zeigt den echten Verkehr. --- **TCP-Handshake prüfen** Bei TCP ist der Verbindungsaufbau wichtig. Vereinfacht: SYN SYN-ACK ACK Fehlerbilder: Nur SYN: Ziel antwortet nicht oder Firewall blockiert. SYN und RST: Ziel lehnt aktiv ab oder Dienst nicht offen. SYN, SYN-ACK, ACK: TCP-Verbindung wurde aufgebaut. Merksatz: TCP-Handshake zeigt, ob eine TCP-Verbindung entsteht. --- **Timeout** Timeout bedeutet: Es kommt keine Antwort innerhalb der erwarteten Zeit. Mögliche Ursachen: - Firewall droppt Pakete - Routingproblem - Ziel nicht erreichbar - Dienst antwortet nicht - Rückweg fehlt - Paket geht an falsches Ziel - Provider blockiert Merksatz: Timeout bedeutet oft: keine oder keine passende Antwort. --- **Connection Refused** Connection refused bedeutet: Zielsystem ist erreichbar, aber der Dienst nimmt auf dem Port keine Verbindung an. Mögliche Ursachen: - Dienst läuft nicht - falscher Port - Dienst lauscht nur lokal - Host-Firewall lehnt aktiv ab - Anwendung nicht gestartet Merksatz: Connection refused deutet auf Zielsystem oder Dienst hin. --- **Reset** Ein TCP Reset beendet oder verweigert eine Verbindung aktiv. Mögliche Ursachen: - Dienst lehnt Verbindung ab - Firewall sendet Reset - Anwendung beendet Verbindung - falsches Protokoll auf Port - Sicherheitsregel greift Merksatz: Reset ist eine aktive Ablehnung oder Beendigung. --- **Fehlersuche mit Logs kombinieren** Am besten kombiniert man: Client-Fehler DNS-Ergebnis Porttest Firewall-Log NAT-Log Serverlog Anwendungstest Beispiel: Client meldet Timeout. Firewall-Log zeigt Drop. Ursache: Firewall-Regel fehlt oder blockiert. Oder: Client meldet 502. Firewall erlaubt. Reverse-Proxy-Log zeigt Backend nicht erreichbar. Ursache: Backend oder interne Regel prüfen. Merksatz: Mehrere Hinweise zusammen ergeben die Ursache. --- **Fehler nach Änderung** Wenn ein Problem direkt nach einer Änderung auftritt, prüft man zuerst diese Änderung. Beispiele: neue Firewall-Regel NAT geändert DNS geändert Zertifikat erneuert Reverse Proxy angepasst Dienst neu gestartet Server-IP geändert VLAN geändert VPN-Gruppe geändert Update installiert Merksatz: Nach Änderung zuerst Änderung prüfen. --- **Änderungen dokumentieren** Firewall- und NAT-Änderungen sollten dokumentiert werden. Wichtige Angaben: - Datum - Zweck - Quelle - Ziel - Port - Protokoll - Richtung - NAT-Ziel - Verantwortlicher - Ticket - Testergebnis - Rollback-Möglichkeit Merksatz: Gute Dokumentation verkürzt spätere Fehlersuche. --- **Rollback** Rollback bedeutet: Änderung zurücknehmen, wenn sie Probleme verursacht. Bei Firewall-Änderungen wichtig: vorherigen Zustand kennen Backup der Konfiguration haben Wartungsfenster beachten Zugriff auf Firewall nicht selbst aussperren Notfallzugang sichern Merksatz: Vor kritischen Änderungen Rückweg planen. --- **Sich nicht selbst aussperren** Bei Firewall-Änderungen kann man sich selbst den Zugriff nehmen. Beispiele: Admin-Regel gelöscht. Managementnetz blockiert. VPN-Regel falsch gesetzt. Weboberfläche der Firewall nicht mehr erreichbar. Vorbeugung: Konfiguration sichern. lokalen Zugriff bereithalten. Änderung mit Zeitplan oder Rollback absichern. Managementzugriff nicht ungetestet ändern. Merksatz: Managementzugriff besonders vorsichtig ändern. --- **Checkliste: Firewall-Fehlersuche** 1. Fehlerbild genau aufnehmen. 2. Quelle bestimmen. 3. Ziel bestimmen. 4. Port und Protokoll bestimmen. 5. Richtung und Zone bestimmen. 6. DNS prüfen. 7. Routing prüfen. 8. NAT prüfen. 9. Firewall-Regel prüfen. 10. Regelreihenfolge prüfen. 11. Firewall-Logs prüfen. 12. Zielsystem-Firewall prüfen. 13. Dienststatus prüfen. 14. Anwendung testen. 15. Rückweg prüfen. 16. letzte Änderungen prüfen. 17. Ergebnis dokumentieren. Merksatz: Firewall-Fehlersuche ist eine Kette, kein einzelner Test. --- **Was man nicht vorschnell tun sollte** Nicht sofort: Any-Any-Regel erstellen. Firewall komplett deaktivieren. alle Ports öffnen. DMZ ins LAN freigeben. Adminport ins Internet öffnen. Logs ignorieren. DNS ungeprüft lassen. NAT und Firewall verwechseln. Warum? Solche Maßnahmen können Sicherheitslücken erzeugen und die eigentliche Ursache verdecken. Merksatz: Nicht Sicherheit opfern, nur um schnell einen Test zu machen. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Wie geht man bei Firewall-Fehlersuche systematisch vor? - Warum reichen Ping und Porttest nicht aus? - Warum muss man Quelle, Ziel, Port und Richtung kennen? - Warum ist DNS bei Firewallproblemen relevant? - Warum muss NAT zusätzlich zur Firewall geprüft werden? - Warum kann eine Portweiterleitung trotz NAT-Regel nicht funktionieren? - Was bedeutet Timeout? - Was bedeutet Connection Refused? - Was ist asymmetrisches Routing? - Warum sind Firewall-Logs wichtig? - Warum können interne und externe Tests unterschiedliche Ergebnisse liefern? - Warum sollte man nicht einfach Any-Any erlauben? - Warum ist Dokumentation bei Firewall-Regeln wichtig? --- **Typische Prüfungsfallen** Ping prüft nicht den Dienst. Porttest prüft nicht die Anwendung. DNS kann wie ein Firewallproblem wirken. NAT-Regel ist nicht Firewall-Regel. Firewall-Regel ist nicht NAT-Regel. TCP und UDP nicht verwechseln. Regelrichtung beachten. Zone beachten. Regelreihenfolge beachten. Rückweg beachten. Stateful Firewalls brauchen Verbindungszustand. Asymmetrisches Routing kann Verbindungen stören. Timeout und Connection Refused bedeuten nicht dasselbe. Host-Firewall zusätzlich prüfen. Dienst muss wirklich laufen. Logs sind zentrale Hinweise. Keine Any-Any-Regel als Dauerlösung. Änderungen dokumentieren. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | Quelle | System, das Verbindung startet | | Ziel | System, das erreicht werden soll | | Richtung | Weg zwischen Zonen oder Interfaces | | Zone | Sicherheitsbereich der Firewall | | NAT | Adressübersetzung | | PAT | Port- und Adressübersetzung | | Portweiterleitung | externer Port wird intern weitergeleitet | | Rückweg | Antwortweg zurück zur Quelle | | asymmetrisches Routing | Hin- und Rückweg sind unterschiedlich | | Timeout | keine Antwort innerhalb der Zeit | | Connection Refused | Ziel lehnt Verbindung aktiv ab | | TCP Reset | aktive Verbindungsbeendigung | | Firewall-Log | Protokoll erlaubter oder blockierter Verbindungen | | Host-Firewall | Firewall auf dem Zielsystem | | Hairpin NAT | interner Zugriff über öffentliche Adresse | | Split DNS | intern und extern unterschiedliche DNS-Antwort | | CGNAT | Provider-NAT, oft ohne eingehende Ports | | Rollback | Änderung zurücknehmen | | Any-Any | sehr breite Erlaubnisregel | --- **IHK-sichere Kurzformulierung** Bei der Fehlersuche an Firewalls, NAT und DMZ müssen Quelle, Ziel, Port, Protokoll, Richtung und Zone genau bestimmt werden. Zusätzlich sind DNS, Routing, NAT-Regeln, Firewall-Regeln, Regelreihenfolge, Host-Firewall, Dienststatus, Rückweg und Logs zu prüfen. Eine NAT-Regel übersetzt Adressen oder Ports, ersetzt aber keine Firewall-Regel. Ein erfolgreicher Ping oder ein offener Port beweist nicht, dass der Anwendungdienst korrekt funktioniert. Typische Ursachen für Fehler sind falsche DNS-Einträge, fehlende Portweiterleitungen, blockierende Firewall-Regeln, falsche Richtung, TCP/UDP-Verwechslung, fehlender Rückweg, CGNAT, Double NAT oder ein nicht laufender Dienst. --- **Merksätze** Erst Quelle bestimmen. Dann Ziel bestimmen. Dann Port und Protokoll bestimmen. Dann Richtung und Zone prüfen. DNS zuerst nicht vergessen. Routing findet den Weg. Firewall erlaubt oder blockiert den Weg. NAT übersetzt Adressen oder Ports. NAT ersetzt keine Firewall-Regel. Firewall-Regel ersetzt keine NAT-Regel. TCP und UDP nicht verwechseln. Regelreihenfolge beachten. Spezifisch vor allgemein. Logs zeigen, welche Regel greift. Kein Log kann bedeuten, dass Verkehr gar nicht ankommt. Host-Firewall zusätzlich prüfen. Dienst muss wirklich laufen. Rückweg muss stimmen. Timeout bedeutet: keine passende Antwort. Connection Refused bedeutet: Ziel lehnt aktiv ab. Ping reicht nicht aus. Porttest reicht nicht aus. Offener Port heißt nicht: Anwendung funktioniert. Intern und extern getrennt testen. Hairpin NAT oder Split DNS bei internen Tests beachten. CGNAT kann Portweiterleitungen verhindern. Any-Any nicht als schnelle Dauerlösung verwenden. Änderungen dokumentieren. Vor kritischen Änderungen Rollback planen.