Sophos Firewall als NTP-Relay: NTP per NAT weiterleiten

In vielen Netzwerken sollen Clients, Server, Switches, Access Points oder Spezialgeräte einfach die Gateway-IP als Zeitserver verwenden. Auf Sophos Firewall läuft in diesem Szenario aber kein vollständiger interner NTP-Server, der selbst die Zeit für Clients bereitstellt.

Der praktische Workaround ist ein NTP-Relay per NAT. Geräte senden NTP an die Firewall-IP, und die Sophos Firewall leitet diese Anfragen an einen echten externen oder internen Zeitserver weiter. Die Firewall wird dadurch nicht zur eigentlichen Zeitquelle, sondern übersetzt und erlaubt den passenden Traffic.

Das ist besonders nützlich, wenn Geräte fest auf die Gateway-IP konfiguriert sind, wenn eine frühere UTM-Umgebung ersetzt wurde oder wenn man NTP-Ziele zentral kontrollieren möchte. Für neue DHCP-Designs ist oft sauberer, den richtigen Zeitserver direkt per DHCP-Option zu verteilen. Die Grundlagen dazu stehen in Sophos Firewall DHCP Options konfigurieren.

⚠️ Wichtig: Die Sophos Firewall sollte dadurch keinen offenen NTP-Dienst für das Internet bereitstellen. Quellzonen, Quellnetze, Zielserver und Firewall-Regel müssen bewusst eingeschränkt werden. WAN als Source Zone ist für dieses Muster normalerweise falsch.

Welche Variante passt?

NTP per NAT ist ein pragmatisches Muster, aber nicht immer die beste Architektur.

Für diesen Artikel sind zwei Varianten wichtig:

• Variante A: Interne Geräte nutzen die Firewall-IP als NTP-Server, die Firewall leitet an einen externen NTP-Server weiter.
• Variante B: Interne Geräte nutzen die Firewall-IP als NTP-Server, die Firewall leitet an einen internen NTP-Server weiter. Zusätzlich muss der interne NTP-Server selbst nach extern synchronisieren dürfen.

Die zweite Variante braucht deshalb zwei NAT-Regeln und zwei Firewall-Regeln. Das ist der Punkt, der bei vielen Kurznotizen zu diesem Thema fehlt.

Voraussetzungen

Vor der Konfiguration sollten diese Punkte klar sein:

• Welche internen Netze dürfen NTP verwenden?
• Welche IP-Adresse verwenden Clients als NTP-Ziel, zum Beispiel die Gateway-IP?
• Welcher echte NTP-Server soll verwendet werden?
• Soll ein interner Zeitserver oder ein externer Dienst wie time.google.com oder pool.ntp.org genutzt werden?
• Darf die Firewall DNS für FQDN-Ziele zuverlässig auflösen?
• Wird die eigene Systemzeit der Firewall korrekt synchronisiert?

Für zeitkritische Funktionen wie MFA, WAF-Authentifizierung, Zertifikate, Logs, VPN und SIEM-Korrelation ist korrekte Zeit wichtig. Wenn die Firewall selbst falsche Zeit hat, sollte zuerst die Systemzeit geprüft werden, bevor Client-NTP umgeleitet wird.

Die Schritte in diesem Artikel orientieren sich an Sophos Firewall 22.0. Menüpfade und Feldnamen können sich bei älteren oder neueren SFOS-Versionen leicht unterscheiden. Die Konfiguration gehört in die Sophos Firewall WebAdmin-Oberfläche oder in eine sauber geprüfte API-/CLI-Automation. In Sophos Central wird dieses NAT-/Firewall-Regelwerk normalerweise nicht als eigenständige NTP-Relay-Konfiguration gepflegt.

Die Beispiele sind bewusst als IPv4-Setup beschrieben, weil Sophos die Host-Anlage in der offiziellen Anleitung ebenfalls mit IP version: IPv4 zeigt. In IPv6- oder Dual-Stack-Umgebungen sollte man dieses Muster nicht einfach kopieren, sondern zuerst klären, ob Clients wirklich NTP über IPv6 benötigen, welche Firewall- und NAT-Funktionen dafür im eingesetzten SFOS-Release gelten und ob DHCPv6, Router Advertisements oder ein direkter interner Zeitserver die sauberere Lösung sind.

Quick Reference

Für erfahrene Admins ist die Kurzlogik schnell erklärt: Clients senden UDP 123 an die Firewall- oder Gateway-IP. Eine DNAT-Regel setzt das Ziel auf den echten NTP-Server um, eine Firewall-Regel erlaubt genau diesen Traffic, und der Log Viewer bestätigt anschliessend Firewall Rule ID und NAT Rule ID.

Externer NTP-Server: Eine DNAT-Regel leitet NTP von der Firewall-IP auf das FQDN- oder Host-Objekt des externen NTP-Servers. Eine Firewall-Regel erlaubt NTP von den betroffenen internen Quellen Richtung WAN. Kritisch ist die Original Destination: Dieses Feld sollte auf die Firewall- oder Gateway-IP zeigen.

Interner NTP-Server: Es braucht zwei Bewegungen. Erstens darf der interne NTP-Server selbst per SNAT/MASQ nach extern synchronisieren. Zweitens leitet eine DNAT-Regel Client-Anfragen von der Firewall-IP auf den internen NTP-Server. Beide Regelpaare sollten separat im Log Viewer geprüft werden.

Die Regelposition sollte für die erste Umsetzung bewusst hoch gesetzt werden, typischerweise Top oder oberhalb breiter LAN-to-WAN- und allgemeiner NAT-Regeln. Danach kann man die Position in ein bestehendes Regelkonzept einsortieren, solange Log Viewer und Packet Capture weiterhin zeigen, dass die erwartete Regel zuerst greift.

Variante A: Externen NTP-Server verwenden

Diese Variante passt, wenn Clients die Firewall-IP als NTP-Server verwenden sollen und kein eigener interner Zeitserver vorhanden ist. Die Firewall übersetzt die NTP-Anfrage auf einen externen Zeitserver, zum Beispiel 1.sophos.pool.ntp.org, time.google.com oder einen bewusst gewählten Provider-Zeitserver.

FQDN-Host für den externen NTP-Server erstellen

Der Menüpfad lautet:

Hosts and services > FQDN host

Vorgehen:

1. Add auswählen.
2. Name vergeben, zum Beispiel NTP_1_sophos_pool.
3. Unter FQDN den externen NTP-Server eintragen, zum Beispiel 1.sophos.pool.ntp.org.
4. Speichern.

Wenn statt FQDN ein interner oder externer Zeitserver mit fixer IP verwendet wird, kann ein normales Host-Objekt sinnvoller sein. Wichtig ist, dass das Ziel später in NAT- und Firewall-Regel eindeutig wiedererkennbar ist.

NAT-Regel für den externen NTP-Server erstellen

Die NAT-Regel sorgt dafür, dass NTP-Anfragen an die Firewall-IP auf den externen Zeitserver umgeschrieben werden. Der Menüpfad lautet:

Rules and policies > NAT rules

Vorgehen:

1. Add NAT rule > New NAT rule auswählen.
2. Rule name setzen, zum Beispiel DNAT_Client_NTP_to_External.
3. Rule position auf Top setzen oder oberhalb breiter NAT-Regeln platzieren.
4. Original source auf das betroffene interne Netz setzen, zum Beispiel LAN_NET oder IOT_NET.
5. Original destination auf die Firewall- oder Gateway-IP setzen, die Clients als NTP-Server verwenden.
6. Bei Original service Any entfernen und NTP auswählen.
7. Bei Translated source (SNAT) MASQ auswählen.
8. Bei Translated destination (DNAT) den FQDN-Host oder Host des externen NTP-Servers auswählen.
9. Bei Inbound interface das interne Interface oder die betroffenen internen Interfaces auswählen.
10. Speichern.

⚠️ Original Destination nicht offen lassen: Wenn die Original Destination nicht auf die Firewall- oder Gateway-IP begrenzt wird, kann die Regel je nach restlichem NAT-Design deutlich breiter wirken als geplant. Dann wird unter Umständen nicht nur Traffic an die Firewall-IP weitergeleitet, sondern NTP-Traffic aus dem Netz transparenter umgebogen. Für ein kontrolliertes Relay sollte die Regel nur greifen, wenn Clients wirklich die Firewall- oder Gateway-IP als NTP-Ziel verwenden.

In der Detailansicht sollte man besonders auf vier Punkte achten: Die Original Destination muss wirklich die Firewall- oder Gateway-IP sein, der Service muss auf NTP beziehungsweise UDP 123 begrenzt bleiben, das Translated Destination muss auf den geplanten Zeitserver zeigen, und SNAT sollte zum Rückweg passen.

Wenn NAT-Grundlagen oder DNAT-Felder unklar sind, hilft NAT auf Sophos Firewall verstehen: SNAT, DNAT, MASQ, PAT. Dort ist auch erklärt, warum NAT keine Firewall-Freigabe ersetzt.

Firewall-Regel für externes NTP erlauben

Nach der NAT-Regel braucht es eine passende Firewall-Regel. Damit wird NTP-Traffic aus den internen Netzen zum Zielserver erlaubt. Der Menüpfad lautet:

Rules and policies > Firewall rules

Vorgehen:

1. Add firewall rule > New firewall rule auswählen.
2. Rule name setzen, zum Beispiel LAN_to_External_NTP.
3. Rule position auf Top setzen oder oberhalb allgemeiner LAN-to-WAN-Regeln platzieren, wenn diese sonst vorher greifen.
4. Log firewall traffic aktivieren.
5. Source zones auf die internen Zonen setzen, zum Beispiel LAN, DMZ oder eine IoT-Zone. WAN und Any sind für dieses Muster falsch.
6. Source networks and devices auf die betroffenen Netze oder Geräte setzen. Nicht pauschal Any, wenn nur bestimmte Netze NTP verwenden sollen.
7. Destination zones auf WAN setzen.
8. Services auf NTP setzen.
9. Action auf Accept setzen.
10. Speichern.

In offiziellen oder vereinfachten Beispielen sieht man bei Source networks and devices manchmal Any. Für eine Laborumgebung ist das bequem, im produktiven Betrieb aber selten die beste Wahl. Sauberer ist ein konkretes Netzobjekt wie LAN_NET, IOT_NET oder eine kleine Hostgruppe, damit später klar ist, welche Geräte diese NTP-Weiterleitung überhaupt nutzen dürfen.

Die Regel wird vor allem über Source Zone, Source Network, Service, Regelposition und NAT-Ziel eingegrenzt. Wenn zusätzlich Destination networks verwendet werden soll, sollte man die Wirkung danach im Log Viewer prüfen, weil DNAT-Regeln die sichtbare Zieladresse in der Analyse verändern können.

Bei der Regel sollte man nicht nur auf Funktion, sondern auch auf Lesbarkeit achten. Ein Name wie LAN_to_NTP_time_google oder IOT_to_NTP_internal ist später verständlicher als eine generische Regel mit Any.

Für die Einführung ist Logging auf dieser Regel hilfreich. Im Log Viewer sollte man nach dem Test erkennen, aus welchem Client-Netz die Anfrage kam, welche Firewall Rule ID gegriffen hat und ob zusätzlich die erwartete NAT Rule ID sichtbar ist. Wenn keine Rule ID oder die falsche Regel erscheint, ist die Reihenfolge oder das Match der Regel wichtiger als die NTP-Konfiguration selbst.

Für Regelaufbau, Reihenfolge, Services und Logging passt zusätzlich Sophos Firewall-Regeln verstehen und richtig konfigurieren.

Variante B: Internen NTP-Server verwenden

Diese Variante passt, wenn ein interner Domain Controller, Linux-Zeitserver oder anderes internes System die Zeitquelle für Clients sein soll, die Clients aber weiterhin die Firewall-IP als NTP-Server verwenden.

Hier braucht es zwei Regelpaare:

Host für den internen NTP-Server erstellen

Der Menüpfad lautet:

Hosts and services

Vorgehen:

1. Add auswählen.
2. Name setzen, zum Beispiel NTP_Server_Internal.
3. IP version auf IPv4 setzen, falls IPv4 verwendet wird.
4. Type auf IP setzen.
5. IP address des internen NTP-Servers eintragen.
6. Speichern.

Regelpaar 1: Interner NTP-Server synchronisiert nach extern

Zuerst muss der interne NTP-Server selbst einen externen Zeitserver erreichen können, falls er nicht bereits anderweitig synchronisiert wird.

NAT-Regel:

1. Rules and policies > NAT rules öffnen.
2. Add NAT rule > New NAT rule auswählen.
3. Rule name setzen, zum Beispiel SNAT_Internal_NTP_to_WAN.
4. Rule position auf Top setzen oder passend oberhalb breiter NAT-Regeln platzieren.
5. Original source auf den Host NTP_Server_Internal setzen.
6. Bei Original service Any entfernen und NTP auswählen.
7. Bei Translated source (SNAT) MASQ auswählen.
8. Speichern.

Firewall-Regel:

1. Rules and policies > Firewall rules öffnen.
2. Add firewall rule > New firewall rule auswählen.
3. Rule name setzen, zum Beispiel Internal_NTP_to_WAN.
4. Log firewall traffic aktivieren.
5. Source zones auf die Zone des internen NTP-Servers setzen, zum Beispiel LAN.
6. Source networks and devices auf NTP_Server_Internal setzen.
7. Destination zones auf WAN setzen.
8. Services auf NTP setzen.
9. Speichern.

Regelpaar 2: Clients über Firewall-IP zum internen NTP-Server führen

Danach wird die eigentliche Weiterleitung gebaut: Clients senden NTP an die Firewall-IP, die Firewall leitet an den internen NTP-Server weiter.

NAT-Regel:

1. Rules and policies > NAT rules öffnen.
2. Add NAT rule > New NAT rule auswählen.
3. Rule name setzen, zum Beispiel DNAT_Client_NTP_to_Internal.
4. Rule position auf Top setzen oder oberhalb allgemeiner NAT-Regeln platzieren.
5. Original source auf die betroffenen internen Client-Netze setzen.
6. Original destination auf die Firewall- oder Gateway-IP setzen, die Clients als NTP-Ziel verwenden.
7. Bei Original service Any entfernen und NTP auswählen.
8. Bei Translated source (SNAT) MASQ auswählen.
9. Bei Translated destination (DNAT) NTP_Server_Internal auswählen.
10. Speichern.

Auch hier ist Original destination entscheidend: Die Regel soll nur NTP-Anfragen übersetzen, die an die Firewall- oder Gateway-IP gerichtet sind. Wenn dieses Feld zu breit bleibt, kann die Firewall auch NTP-Anfragen erfassen, die Clients eigentlich direkt an einen anderen Zeitserver senden wollten.

Firewall-Regel:

1. Rules and policies > Firewall rules öffnen.
2. Add firewall rule > New firewall rule auswählen.
3. Rule name setzen, zum Beispiel LAN_to_Internal_NTP.
4. Log firewall traffic aktivieren.
5. Source zones auf die internen Client-Zonen setzen. WAN und Any vermeiden.
6. Source networks and devices auf die betroffenen Client-Netze setzen.
7. Destination zones auf die Zone des internen NTP-Servers setzen, zum Beispiel LAN oder DMZ.
8. Services auf NTP setzen.
9. Speichern.

Wenn zusätzlich ein Destination network gesetzt wird, sollte man danach gezielt testen, ob die Firewall-Regel nach DNAT weiterhin matched. Für die erste Abnahme sind Quellnetz, Zielzone, Service, NAT-Regel und Log Viewer meistens die klareren Kontrollpunkte.

Wenn der interne NTP-Server selbst Domain Controller ist, sollte man besonders vorsichtig scopen. Nicht jedes Client-Netz muss jeden Domain Controller direkt erreichen. NTP kann erlaubt sein, ohne gleich breite Domain-Controller-Zugriffe zu öffnen.

Betrieb, Sicherheit und Prüfung

IPS und Security Features einordnen

NTP ist technisch ein kleiner UDP-Dienst, aber UDP 123 wird in der Praxis auch für Missbrauch, Fehlkonfigurationen oder unerwünschte externe Ziele relevant. Wenn eine Network-Protection-Lizenz vorhanden ist, kann eine passende IPS-Policy auf der Firewall-Regel sinnvoll sein.

Wichtiger als möglichst viele Security Features ist bei NTP zuerst ein enges Design:

• Source Zone nur intern: verhindert, dass die Firewall wie ein öffentlicher NTP-Relay wirkt.
• Source Networks konkret: begrenzt NTP auf Clients, Server oder Geräte, die diese Weiterleitung wirklich brauchen.
• Destination Server festlegen: verhindert beliebige externe Zeitserver und macht Logs auswertbar.
• Service nur NTP: vermeidet eine zu breite UDP-Regel.
• Logging aktivieren: zeigt im Log Viewer, ob Firewall Rule ID und NAT Rule ID wie erwartet greifen.

IPS sollte man deshalb als zusätzliche Kontrolle verstehen, nicht als Ersatz für eine saubere Regel. Wenn die NTP-Regel nur wenige interne Netze zu einem definierten Zeitserver erlaubt, ist der wichtigste Sicherheitsgewinn bereits durch Scope und Nachvollziehbarkeit erreicht. Wenn sehr viele Netze, unklare Geräte oder IoT-/OT-Bereiche beteiligt sind, wird eine gezielte IPS-Policy interessanter.

⚠️ IPS benötigt eine passende Network-Protection-Lizenz. Wenn IPS auf einer sehr breit genutzten Regel aktiviert wird, sollte man Logs und Performance beobachten. Für einfache NTP-Weiterleitung ist sauberes Scoping wichtiger als eine unnötig breite Security-Feature-Kombination.

Wenn eine eigene IPS-Policy für diesen Zweck verwendet wird, sollte sie nicht pauschal auf alle internen Netze kopiert werden. Sinnvoller ist eine kleine Regel mit klarer Quelle, definiertem NTP-Ziel, aktivem Logging und anschliessender Kontrolle im Log Viewer.

Andere Security Features sollte man bei NTP bewusst zurückhaltend behandeln. Web Filtering, TLS Inspection, Application Control oder Malware Scan helfen für diesen einfachen UDP-Dienst normalerweise nicht bei der eigentlichen NTP-Funktion. Wenn solche Profile auf einer Sammelregel aktiv sind, sollte geprüft werden, ob NTP besser in eine eigene, kleine Regel ausgelagert wird.

NTP mit DHCP sauber verteilen

Wenn die Clients ihre Netzwerkkonfiguration per DHCP erhalten, sollte man prüfen, ob eine NAT-Weiterleitung überhaupt nötig ist. Für viele Umgebungen ist es sauberer, den gewünschten NTP-Server direkt per DHCP zu verteilen.

Wenn ein Domain Controller oder ein zentraler Zeitserver vorhanden ist, kann DHCP-Option 42 direkt auf diesen Server zeigen. NAT ist vor allem dann sinnvoll, wenn Geräte bereits fest die Gateway-IP verwenden oder sich schwer umkonfigurieren lassen. Für DHCP-Sonderoptionen ist Sophos Firewall DHCP Options konfigurieren der bessere Einstieg.

Firewall-Systemzeit separat prüfen

Die NTP-Weiterleitung für Clients ist nicht dasselbe wie die Systemzeit der Sophos Firewall. Beides sollte getrennt geprüft werden:

• Firewall-Systemzeit: relevant für Log Viewer, Zertifikate, MFA, VPN, WAF-Authentifizierung, Reports, Syslog und Supportanalyse.
• Client-NTP per NAT: Geräte im internen Netz erhalten Zeit über die Gateway-IP oder eine umgeleitete NTP-Adresse.

Wenn die Firewall selbst eine falsche Uhrzeit oder Zeitzone hat, können Logeinträge schwer korrelierbar sein, Zertifikatsprüfungen fehlschlagen oder zeitbasierte Authentifizierung wie TOTP/MFA Probleme machen. Dann sollte zuerst die Firewall-Systemzeit und der NTP-Zugriff der Firewall korrigiert werden. Erst danach ist es sinnvoll, Client-NTP per NAT zu validieren.

Für SIEM- oder Syslog-Umgebungen ist dieser Punkt besonders wichtig: Die Firewall kann NTP-Traffic korrekt weiterleiten und trotzdem falsche Zeitstempel an ein SIEM senden, wenn ihre eigene Uhrzeit oder Zeitzone nicht stimmt.

Für die Logweiterleitung passt Sophos Firewall Syslog an SIEM senden. Bei MFA-Problemen sollte zusätzlich MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren einbezogen werden.

NTP testen und Fehler eingrenzen

Nach dem Speichern sollte man nicht nur prüfen, ob die Regel existiert. Entscheidend ist, ob ein Client wirklich NTP synchronisieren kann und ob die erwartete NAT- und Firewall-Regel trifft.

Für beide Varianten beginnt der Test gleich: Ein Client aus dem betroffenen Netz verwendet die Firewall- oder Gateway-IP als NTP-Server. Danach wird eine Zeitsynchronisation ausgelöst oder kurz gewartet, bis der Client NTP sendet.

In Log Viewer filtert man nach Service NTP oder UDP 123.

Bei Variante A sollte sichtbar werden:

• Der Client kommt aus dem erwarteten internen Netz.
• Die NTP-Firewall-Regel für externes NTP trifft.
• Die DNAT-Regel zur externen Zeitquelle passt.
• Das Ziel ist der geplante externe NTP-Server.

Bei Variante B sollten zwei Dinge geprüft werden:

• Der interne NTP-Server darf selbst NTP nach extern senden.
• Die Clients werden per DNAT von der Firewall-IP auf den internen NTP-Server geführt.

Wenn der Log Viewer nicht eindeutig zeigt, welche Regel greift, hilft Diagnostics > Packet capture. Dort sollte man prüfen, ob Pakete vom Client an UDP 123 auf der Firewall ankommen und ob danach Pakete zum erwarteten externen oder internen Zeitserver weitergehen.

Wenn keine Logs sichtbar sind, kann die Anfrage am Client gar nicht gesendet werden, die Firewall-Regel loggt nicht, oder der Traffic nimmt einen anderen Pfad. Für die systematische Prüfung passt Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

Bei Firewall-eigenen NTP-Problemen ist zusätzlich der NTP-Client-Log relevant. Die Logübersicht steht in Sophos Firewall Troubleshooting: Services und Logs.

Kurze Abnahme

Vor produktivem Abschluss sollten fünf Punkte stimmen:

1. Clients verwenden wirklich die Firewall- oder Gateway-IP als NTP-Server.
2. Die NTP-Regeln erlauben nur die vorgesehenen internen Quellnetze.
3. Im Log Viewer sind die erwartete Firewall Rule ID und NAT Rule ID sichtbar.
4. Die Firewall-Systemzeit stimmt separat.
5. Nach DHCP-, VLAN-, NAT- oder Regeländerungen wird NTP erneut getestet.

Typische Fehler

• WAN als Source Zone erlaubt: Die Firewall kann ungewollt wie ein offener NTP-Relay wirken. Source Zones auf interne Zonen begrenzen.
• Any bei Source und Destination: Die Regel ist schwer kontrollierbar. Quellnetze und Zielserver konkret definieren.
• NAT-Regel vorhanden, aber keine Firewall-Regel: Traffic wird übersetzt, aber nicht erlaubt. Log Viewer auf Rule ID und NAT ID prüfen.
• Firewall-Regel ohne Logging: Fehleranalyse wird unnötig schwer. Log firewall traffic mindestens während Test aktivieren.
• FQDN-Ziel löst nicht auf: Das DNAT-Ziel wird nicht erreicht. DNS-Auflösung der Firewall prüfen.
• Client nutzt anderen NTP-Server: Die Regel wird nie getroffen. Client-Konfiguration oder DHCP-Option prüfen.
• Zeitserver antwortet nicht: Der Client bleibt unsynchronisiert. Zielserver, Routing und UDP 123 prüfen.

FAQ