DNS Request Routes auf Sophos Firewall konfigurieren

Mit DNS Request Routes kann man auf der Sophos Firewall festlegen, welcher DNS-Server für bestimmte Domains oder Netze verwendet werden soll. Das ist besonders nützlich, wenn die Firewall öffentliche DNS-Server nutzt, interne Namen aber über einen internen DNS-Server aufgelöst werden müssen.

Typische Beispiele sind Active Directory Domains, interne Applikationen, Reverse-Lookups oder VPN-Umgebungen.

Wenn Sophos DNS Protection mit Sophos Firewall eingesetzt wird, werden DNS Request Routes noch wichtiger. Öffentliche Domains gehen dann zum DNS-Protection-Dienst, interne Domains aber weiterhin zum lokalen DNS-Server oder Domain Controller. Ohne diese Trennung können interne Anwendungen, AD-Anmeldungen oder Reverse-Lookups plötzlich wie Netzwerkprobleme wirken.

Orientierung und Design

DNS Request Routes funktionieren nur dann zuverlässig, wenn klar ist, welcher Resolver welche Anfrage sieht. Deshalb sollte man zuerst DNS-Design, Client-DNS, interne Zonen und Routingpfad auseinanderhalten.

DNS Request Route, DNS-Server oder DHCP Option?

DNS Request Routes werden oft mit globalen DNS-Servern oder DHCP-Optionen verwechselt. Die Funktionen lösen unterschiedliche Probleme.

• Globale DNS-Server: Standardauflösung der Firewall für Internet-DNS, allgemeine FQDN-Auflösung, Updates und Cloud-Dienste.
• DNS Request Route: leitet bestimmte Domains oder Reverse-Zonen an definierte DNS-Server weiter. Typisch sind Active Directory, interne Domains, Standort-DNS und Split DNS.
• DHCP Option: verteilt DNS-Server oder Suchdomänen an Clients. Das ist relevant, wenn Clients direkt einen bestimmten DNS-Server verwenden sollen.

Eine DNS Request Route ändert also nicht automatisch die DNS-Konfiguration aller Clients. Die Route steuert, wohin die Sophos Firewall selbst oder Clients, die die Firewall als DNS-Forwarder verwenden, bestimmte DNS-Anfragen weiterleiten. Wenn Clients direkt einen internen DNS-Server verwenden sollen, passt eher eine DHCP Option auf Sophos Firewall.

Welches DNS-Design passt?

Vor dem Anlegen einer DNS Request Route sollte klar sein, welcher Resolver im jeweiligen Netz verwendet wird. Die Route hilft nur, wenn die Sophos Firewall die Anfrage auch sieht.

• Clients fragen die Sophos Firewall: Die Firewall leitet öffentliche Domains global weiter und interne Domains per DNS Request Route. Das passt gut für kleine und mittlere Standorte, DNS Protection sowie Gast- oder Clientnetze.
• Clients fragen interne DNS-Server direkt: Domain Controller oder DNS-Server lösen intern auf und leiten extern weiter. Das passt für klassische Active-Directory-Netze mit Windows-DNS als zentralem Resolver.
• VPN-Clients fragen die Firewall: Die Firewall nutzt Request Routes für interne Domains. Das passt für Remote Access mit einfachem DNS-Pfad über die Firewall.
• VPN-Clients fragen interne DNS-Server direkt: DNS läuft über VPN zum Domain Controller oder DNS-Server. Das passt für grössere AD-Umgebungen, wenn Clients dieselbe DNS-Logik wie im LAN nutzen sollen.

In gemischten Umgebungen ist eine kurze DNS-Skizze sehr hilfreich: Clientnetz, zugewiesener DNS-Server, Suchdomäne, interne DNS-Zonen, DNS Request Routes und Routingpfad zum Zielserver. Ohne diese Übersicht wird später oft an der Request Route gearbeitet, obwohl der Client die Firewall gar nicht als DNS-Resolver nutzt.

Wann braucht man DNS Request Routes?

DNS Request Routes sind sinnvoll, wenn:

• interne Hostnamen wie server01.firma.local aufgelöst werden müssen
• Reverse-Lookups für interne IP-Netze funktionieren sollen
• VPN-Benutzer interne Namen verwenden sollen
• mehrere Standorte eigene DNS-Zonen haben
• die Firewall selbst interne Systeme per FQDN erreichen muss
• öffentliche DNS-Server keine internen Namen kennen

Ohne DNS Request Route fragt die Firewall den global konfigurierten DNS-Server. Wenn dort die interne Domain nicht bekannt ist, schlägt die Auflösung fehl.

Besonders wichtig ist dieser Unterschied bei Remote Access. Wenn VPN-Clients die Firewall als DNS-Server verwenden, kann eine DNS Request Route dafür sorgen, dass interne Domains trotzdem beim richtigen Domain Controller oder DNS-Server landen. Wenn VPN-Clients dagegen direkt interne DNS-Server erhalten, muss zusätzlich geprüft werden, ob Routing, Firewall-Regeln und DNS-Suffixe auf dem Client stimmen.

Voraussetzungen

• Zugriff auf den WebAdmin der Sophos Firewall
• Interner DNS-Server ist erreichbar
• Domain oder Netz ist bekannt
• Firewall-Regeln erlauben DNS-Traffic zum Zielserver
• Bei Standortvernetzung: Routing zum DNS-Server funktioniert
• Der betroffene Client verwendet entweder die Firewall als DNS-Server oder erhält bewusst einen anderen DNS-Server

⚠️ DNS-Probleme wirken oft wie Routing-, VPN- oder Applikationsprobleme. Vor grösseren Änderungen sollte man prüfen, ob der Zielserver per IP erreichbar ist und ob nur die Namensauflösung fehlschlägt.

DNS Request Route konfigurieren

Die Konfiguration ist technisch einfach, wird aber schnell unübersichtlich, wenn Domains, Reverse-Zonen, VPN-Clients und mehrere Standorte zusammenkommen.

DNS Request Route für eine Domain erstellen

Eine Domain-Route sorgt dafür, dass Anfragen für eine bestimmte Domain an einen definierten DNS-Server gesendet werden.

Beispiel:

• Host/domain name: firma.local
• DNS-Server: 10.10.10.10

Vorgehen:

1. In der Sophos Firewall anmelden.
2. Network öffnen.
3. DNS auswählen.
4. Zum Bereich DNS request route wechseln.
5. Eine neue DNS Request Route hinzufügen.
6. Bei Host/domain name die interne Domain eintragen, zum Beispiel firma.local.
7. Bei Target servers den internen DNS-Server auswählen oder über Create als Host anlegen.
8. Speichern.

Danach fragt die Firewall für diese Domain den angegebenen DNS-Server.

Mehrere Target Servers verwenden

Unter Target servers kann man mehr als einen DNS-Server hinzufügen. Das ist sinnvoll, wenn es mehrere interne DNS-Server gibt oder wenn DNS über eine Standortverbindung redundant erreichbar sein soll.

Mögliche Zielserver:

• interne DNS-Server im lokalen Netzwerk
• DNS-Server auf der anderen Seite einer VPN-Verbindung
• DNS-Server an einem anderen Standort
• öffentliche DNS-Server, wenn eine bestimmte Domain bewusst extern aufgelöst werden soll

Die Reihenfolge ist relevant. Die Firewall fragt die ausgewählten Hosts in der Reihenfolge ab, in der sie in der Liste stehen. Pro DNS Request Route können bis zu acht IP-Adressen hinterlegt werden. Mehr Zielserver bedeuten aber nicht automatisch bessere Redundanz, wenn die Server unterschiedliche Zonenstände, unterschiedliche Weiterleitungen oder unterschiedliche Erreichbarkeit über VPN haben.

Bei mehreren Target Servers sollte man nicht nur Redundanz eintragen, sondern auch die Zuständigkeit prüfen. Wenn der erste DNS-Server die Zone zwar kennt, aber veraltete Einträge liefert, wird die Request Route technisch funktionieren und fachlich trotzdem falsche Antworten zurückgeben.

Split DNS für VPN und Standorte

Split DNS bedeutet, dass derselbe Name je nach Standort oder Netz unterschiedlich aufgelöst wird. Ein internes Portal kann intern zum Beispiel auf eine private IP zeigen, während derselbe Name extern auf eine öffentliche Adresse oder gar nicht aufgelöst wird.

Auf der Sophos Firewall sind dafür drei Punkte entscheidend:

1. Die passende DNS Request Route für die interne Domain.
2. Eine Firewall-Regel, die DNS von der Firewall oder vom Client zum internen DNS-Server erlaubt.
3. Ein Routingpfad zum DNS-Server, besonders bei Site-to-Site-VPN, SSL VPN oder Sophos Connect.

Für Remote-Access-Umgebungen sollte man zusätzlich prüfen, welche DNS-Server und Suchdomänen der Client erhält. Bei Sophos Connect passt dazu Sophos Connect auf Sophos Firewall konfigurieren. Bei klassischen SSL-VPN-Setups passt Sophos Firewall SSL VPN Remote Access einrichten.

Reverse DNS für interne Netze

Eine Reverse-DNS-Request-Route leitet PTR-Abfragen für ein internes IP-Netz an den DNS-Server weiter, der die passende Reverse Lookup Zone kennt. Das hilft, wenn Logs, Reports oder Dienste aus einer IP-Adresse wieder einen Hostnamen machen sollen.

Beispiel:

• Netz: 172.16.16.0/24
• DNS-Server: 172.16.16.10
• Reverse-Zone: 16.16.172.in-addr.arpa

Für Reverse-Lookups erstellt man ebenfalls eine DNS Request Route unter Network > DNS > DNS request route. Bei Host/domain name trägt man aber nicht die normale Domain ein, sondern die Reverse-Zone.

Beispiel für 172.16.16.0/24:

16.16.172.in-addr.arpa

Die Reihenfolge der Oktette ist dabei umgekehrt. Aus dem Netz 172.16.16.0/24 wird also 16.16.172.in-addr.arpa.

Für grössere Netze kann die Reverse-Zone breiter sein. Beispiel: Für 172.16.0.0/16 wäre es 16.172.in-addr.arpa. Entscheidend ist, wie die Reverse Lookup Zone auf dem internen DNS-Server angelegt wurde.

Wenn auf dem internen DNS-Server keine PTR-Zone oder keine PTR-Records existieren, hilft auch die Request Route nicht. Die Firewall kann die Anfrage nur an den richtigen DNS-Server senden, aber sie erzeugt keine Reverse-DNS-Einträge auf dem DNS-Server.

Bei IPv6-Umgebungen mit Provider-Präfix sollte man DNS ebenfalls früh mitdenken. Wie Clients ihre IPv6-Adresse erhalten und welche Rolle Router Advertisement und DHCPv6 spielen, steht in IPv6 Prefix Delegation auf Sophos Firewall konfigurieren.

Tests und Betrieb

Nach der Konfiguration sollte man IP-Erreichbarkeit, DNS-Auflösung und Client-DNS getrennt testen. So erkennt man schneller, ob das Problem wirklich bei der Request Route liegt.

Tests und Validierung

Nach der Konfiguration sollte man die Namensauflösung testen:

• Kann die Firewall den internen Namen auflösen?
• Funktioniert die Auflösung aus VPN- oder Benutzerzonen?
• Ist der DNS-Server per Ping oder TCP/UDP 53 erreichbar?
• Gibt es Einträge im DNS- oder Firewall-Log?

Falls die Auflösung nicht funktioniert, sollte man zuerst prüfen:

• Ist die Domain korrekt geschrieben?
• Verwendet der Client wirklich die Sophos Firewall oder den richtigen DNS-Server?
• Blockiert eine Firewall-Regel DNS?
• Fehlt eine Route zum DNS-Server?
• Antwortet der DNS-Server auf Anfragen von der Firewall?

Ein sinnvoller Test trennt IP-Erreichbarkeit und DNS-Auflösung:

1. Zielsystem per IP testen, zum Beispiel Ping, TCP-Port oder Applikation.
2. DNS-Server selbst per IP erreichen.
3. Namen über die erwartete DNS-Quelle auflösen.
4. Danach erst die Applikation über den Namen testen.

Wenn der Zugriff per IP funktioniert, aber per Name nicht, liegt der Schwerpunkt bei DNS Request Route, DNS-Suffix, Client-DNS oder Reverse Lookup. Wenn der Zugriff per IP schon fehlschlägt, sollte man zuerst Routing, Firewall-Regel, NAT oder VPN prüfen. Für diese Abgrenzung helfen Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture und Sophos Firewall Regel greift nicht: Ursachen prüfen.

Testbefehle für Firewall und Clients

Auf der Sophos Firewall kann die Device Console helfen, DNS aus Sicht der Firewall zu testen:

dnslookup server01.firma.local
dnslookup example.com

Auf Clients sollte man zusätzlich prüfen, welcher Resolver wirklich verwendet wird.

Windows:

ipconfig /all
nslookup server01.firma.local
nslookup server01.firma.local <firewall-ip>
Resolve-DnsName server01.firma.local

macOS:

scutil --dns
dig server01.firma.local
dig @<firewall-ip> server01.firma.local

Linux:

resolvectl status
dig server01.firma.local
dig @<firewall-ip> server01.firma.local

<firewall-ip> steht dabei für die interne Interface-Adresse der Sophos Firewall im jeweiligen Netz. Wenn die Abfrage gegen die Firewall funktioniert, die normale Clientabfrage aber nicht, liegt das Problem meistens bei DHCP, VPN-Profil, DNS-Suffix, lokalem Resolver oder Browser-/System-DNS-Verhalten. Wenn auch die Abfrage gegen die Firewall fehlschlägt, sind Request Route, Target Server, Routing oder Firewall-Regel die nächsten Prüfpunkte.

Positiv- und Negativtest definieren

Eine DNS Request Route gilt erst dann als sauber getestet, wenn nicht nur der gewünschte interne Name funktioniert, sondern auch ein Gegenbeispiel geprüft wurde. Sonst bleibt unklar, ob die Route genau die interne Zone trifft oder ob DNS versehentlich zu breit umgeleitet wird.

Ein kurzer Testplan reicht meistens:

• Positivtest: Ein interner Name aus der Zielzone löst auf die erwartete private IP auf, zum Beispiel server01.ad.firma.local.
• Negativtest: Eine nicht betroffene öffentliche Domain läuft weiterhin über den vorgesehenen Standardpfad, zum Beispiel globaler DNS, DNS Protection oder interner Forwarder.
• Clienttest: Der Test wird aus dem betroffenen VLAN, VPN-Profil oder Standort ausgeführt, nicht nur direkt auf der Firewall.
• Logcheck: Firewall-Log, DNS-Log oder Packet Capture zeigen, dass die Anfrage den erwarteten Resolver erreicht.
• Regression: Nach einer Änderung an VPN, DHCP, DNS Protection oder Standort-Routing wird derselbe Test wiederholt.

Dieser kleine Negativtest verhindert typische Nebenwirkungen: öffentliche Domains werden intern beantwortet, DNS Protection wird umgangen, Split-DNS greift nur aus manchen Netzen oder ein VPN-Client nutzt weiterhin einen alten Resolver.

Betriebscheck

DNS Request Routes sollten möglichst spezifisch sein. Eine Route für die genaue interne Domain ist besser als eine zu breite Konfiguration. Für grössere Umgebungen lohnt sich eine kurze Dokumentation mit Domain, DNS-Server, Standort und Zweck, damit spätere Änderungen nachvollziehbar bleiben.

Praktische Dokumentation:

• Domain oder Reverse-Zone: zum Beispiel ad.firma.local.
• Target Servers: zum Beispiel 10.10.10.10 und 10.10.10.11.
• Zweck: zum Beispiel Active Directory DNS für Hauptstandort.
• Betroffene Netze: zum Beispiel LAN, Admin-VPN und Standort Zürich.
• Abhängigkeiten: zum Beispiel Site-to-Site-VPN, Domain Controller und Firewall-Regel für DNS.
• Test: zum Beispiel server01.ad.firma.local löst auf die erwartete interne IP auf.
• Negativtest: zum Beispiel example.com nutzt weiterhin den vorgesehenen Standardpfad.

Troubleshooting

Wenn DNS nicht funktioniert, sollte man nicht direkt die Request Route ändern. Häufig nutzt der Client einen anderen Resolver, eine Firewall-Regel blockiert DNS oder die Reverse-Zone existiert auf dem Zielserver nicht.

Typische Fehler

• Interner Name löst nicht auf: Häufig ist die Domain falsch, zum Beispiel firma.local statt ad.firma.local. Domain in der Request Route und Suchdomäne des Clients prüfen.
• VPN-Client löst interne Namen nicht auf: Der Client verwendet möglicherweise nicht die Firewall oder den falschen DNS-Server. VPN-DNS-Einstellungen, Client-DNS und Firewall-Regel prüfen.
• Firewall kann DNS-Server nicht erreichen: Route, VPN oder Firewall-Regel fehlt wahrscheinlich. Ping, Packet Capture und Route Lookup prüfen.
• Reverse Lookup funktioniert nicht: PTR-Zone oder PTR-Records fehlen. Reverse Lookup Zone auf dem internen DNS-Server prüfen.
• Einzelne Standorte liefern falsche Antworten: Falscher Target Server oder veraltete Zonendaten sind wahrscheinlich. Reihenfolge der Target Servers und DNS-Replikation prüfen.
• Öffentliche Namen werden plötzlich intern beantwortet: Die Request Route ist zu breit. Spezifischere Domain verwenden und Wildcard-Denken vermeiden.

Bei VPN-Umgebungen sollte man zusätzlich prüfen, ob die VPN-Clients die richtigen DNS-Server und Suchdomänen erhalten.

FAQ