Sophos Firewall als NTP-Relay: NTP per NAT weiterleiten

Wenn interne Geräte die Gateway-IP als NTP-Ziel verwenden müssen, kann Sophos Firewall ihre Anfragen per NAT an einen Zeitserver weiterleiten. Die Einstellung unter Administration > Time synchronisiert dagegen nur die Uhr der Firewall; sie stellt den Clients keinen NTP-Serverdienst bereit.

Der von Sophos dokumentierte Weg ist ein NTP-Relay per NAT. Geräte senden NTP an die Firewall-IP, und Sophos Firewall übersetzt Ziel und Quelle und leitet die Pakete an einen echten externen oder internen Zeitserver weiter. Die Firewall wird dadurch nicht zur Zeitquelle. Davon getrennt arbeitet sie selbst als NTP-Client, um ihre eigene Uhr zu synchronisieren.

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 hat deshalb zwei getrennte Datenpfade. Wenn die externe Synchronisierung des internen Zeitservers bereits passend erlaubt und übersetzt wird, wird das vorhandene Regelpaar geprüft und weiterverwendet; zusätzliche identische Regeln sind nicht nötig.

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?

Ein durchgängiges IPv4-Beispiel macht die Zuordnung deutlich:

• net_Internet-LAN: 10.10.11.0/24, Client-Eingang Port2 in Zone des internen Clientnetzes.
• host_internal-firewall-ip: Host 10.10.11.1, die von diesen Clients verwendete Firewall-IP.
• host_Google-NTP: FQDN time.google.com für Variante A und gegebenenfalls als externe Zeitquelle des internen Servers.
• NTP_Server_Internal: Host 192.168.20.10, erreichbar über Port3 in Zone DMZ, für Variante B.

Diese privaten Adressen, Objektnamen und Interfaces sind Beispiele und werden durch die tatsächlichen Werte ersetzt. Man wählt nur Netze, die das Relay benötigen, und deren tatsächliche Eingangsinterfaces; für IOT_NET wird bei Bedarf eine eigene, ebenso eng begrenzte Regel ergänzt. Die Netzwerk- und Hostobjekte werden unter Hosts and services > IP host angelegt. Für mehrere Gateway-IPs müssen die zugehörigen Quellnetze, Eingänge und Zieladressen konsistent zusammenpassen. Vor Änderungen werden bestehende NAT-/Firewall-Regeln, Reihenfolge und Client-Zeitquelle festgehalten; der echte Zeitserver muss erreichbar sein und Anfragen von der durch MASQ verwendeten Firewall-Adresse akzeptieren.

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 folgenden Schritte beziehen sich auf die offizielle Dokumentation für Sophos Firewall 22.0 (Quellenprüfung am 17.10.2026). Ein Gerätetest wurde für diese Anleitung nicht durchgeführt. Die NTP-Einstellungen der Firewall lassen sich nicht aus Sophos Fusion (ehemals Sophos Central) synchronisieren; sie werden in WebAdmin, per CLI oder API gepflegt. Die folgenden NAT- und Firewall-Schritte beziehen sich auf WebAdmin.

Die Beispiele sind bewusst als IPv4-Setup beschrieben; bei der Host-Anlage wird deshalb IP version: IPv4 gewählt. 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. Sophos lässt Original destination in seinem allgemeinen Relay-Beispiel auf Any; für das hier beschriebene Gateway-IP-Relay wird das Feld enger auf genau die von Clients verwendete Firewall-IP gesetzt. So werden direkte NTP-Anfragen an andere Ziele nicht unbemerkt umgebogen.

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.

host_internal-firewall-ip enthält die interne LAN-IP-Adresse der Sophos Firewall, hier 10.10.11.1. Diese Adresse tragen die Clients als NTP-Server ein. Ersetze den Beispielwert durch die interne Firewall-LAN-IP deines eigenen Clientnetzes und passe net_Internet-LAN (10.10.11.0/24), Eingangsinterface und Quellzone entsprechend an. Im gezeigten Aufbau ist der Eingang Port2 mit der Zone des internen Clientnetzes; Port1 gehört zur DMZ und wird hierfür nicht verwendet. Beide Regeln verwenden den vordefinierten Dienst NTP; ein zusätzlicher UDP-only-Dienst ist für diese Anleitung nicht erforderlich. Die Konfiguration ist ein nachvollziehbares Beispiel, kein Nachweis eines erfolgreichen Live-Tests. Wähle die in deiner Umgebung dem Clientnetz zugewiesene Zone; „interne LAN-Zone“ ist eine Beschreibung und kein vorgegebener Zonenname.

Lege unter Hosts and services > IP host > Add die folgenden beiden IPv4-Objekte an und speichere jeweils mit Save. Verwende vorhandene passende Objekte, falls sie bereits existieren.

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 time.google.com oder einen bewusst gewählten Provider-Zeitserver.

Google Public NTP (time.google.com) verwendet Leap Smear. Nicht mit Zeitquellen ohne Leap Smear mischen.

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 host_Google-NTP.
3. Unter FQDN den externen NTP-Server eintragen, zum Beispiel time.google.com.
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, im Beispiel net_Internet-LAN (10.10.11.0/24).
5. Original destination auf host_internal-firewall-ip setzen, im Beispiel 10.10.11.1.
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 Any entfernen und den tatsächlichen Client-Eingang auswählen, im Beispiel Port2. Sophos erlaubt hier alternativ Any; die konkrete Auswahl verhindert jedoch ein Match auf unbeabsichtigten Eingängen.
10. Translated service (PAT) auf Original belassen, damit UDP 123 unverändert bleibt. Outbound interface bleibt bei dieser DNAT-Regel Any; der geroutete Weg zum übersetzten Ziel bestimmt den Ausgang.
11. 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 NTP_LAN_to_Google.
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 die interne LAN-Zone, 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. Destination networks auf ein IPv4-Hostobjekt für die Firewall- oder Gateway-IP setzen, die Clients als NTP-Ziel verwenden, zum Beispiel host_internal-firewall-ip. Falls es noch fehlt, unter Hosts and services > IP host > Add mit Type: IP und genau dieser IP-Adresse anlegen. Es muss dieselbe Adresse wie bei Original destination der Client-DNAT-Regel sein, nicht der externe NTP-Host.
9. Services auf NTP setzen.
10. Action auf Accept setzen.
11. 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 net_Internet-LAN, IOT_NET oder eine kleine Hostgruppe, damit später klar ist, welche Geräte diese NTP-Weiterleitung überhaupt nutzen dürfen.

Bei eingehendem DNAT bestimmt Sophos zuerst das übersetzte Ziel. Destination zones verwendet dessen Zone, hier WAN; Destination networks verwendet dagegen das ursprüngliche Ziel, hier die Firewall- oder Gateway-IP. Der echte Zeitserver bleibt ausschliesslich Translated destination (DNAT). Das allgemeine Sophos-NTP-Beispiel nennt Destination networks nicht; diese Unterscheidung folgt den expliziten DNAT- und Loopback-Beispielen. Nach Änderungen eine neue NTP-Sitzung vom Client auslösen: Bestehende Sitzungen werden nicht erneut gegen geänderte NAT-Regeln ausgewertet. Vor der Freigabe Firewall Rule ID, NAT Rule ID und den eingehenden sowie weitergeleiteten Paketpfad wie im Prüfabschnitt kontrollieren; die Konfiguration allein belegt keine erfolgreiche Synchronisierung.

Bei der Regel sollte man nicht nur auf Funktion, sondern auch auf Lesbarkeit achten. Ein Name wie NTP_LAN_to_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 werden zwei Datenpfade mit ihren Regelpaaren geprüft; passende bestehende Regeln können weiterverwendet werden:

Host für den internen NTP-Server erstellen

Der Menüpfad lautet:

Hosts and services > IP host

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, im Beispiel 192.168.20.10.
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. Seine konfigurierte Upstream-Zeitquelle muss der echte Zeitserver sein, nicht die als Relay verwendete Gateway-IP. Eine Rückleitung zu ihm selbst kann nur entstehen, wenn sein Verkehr ebenfalls eine Relay-DNAT-Regel mit diesem Server als übersetztem Ziel trifft. Im obigen Beispiel verhindern Quellnetz und Eingangsinterface diesen Treffer auf die Client-DNAT-Regel; die falsch gewählte Gateway-IP liefert dann möglicherweise keine brauchbare Zeit.

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. Original destination auf die geplante externe Zeitquelle setzen, im Beispiel host_Google-NTP.
7. Bei Original service Any entfernen und NTP auswählen.
8. Bei Translated source (SNAT) MASQ auswählen; Translated destination (DNAT) und Translated service (PAT) bleiben Original.
9. Inbound interface auf den Eingang des internen Servers setzen, im Beispiel Port3; Outbound interface auf das tatsächlich verwendete WAN-Interface begrenzen. Bei mehreren WAN-Verbindungen müssen alle vorgesehenen Ausgänge berücksichtigt werden.
10. 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, im Beispiel DMZ.
6. Source networks and devices auf NTP_Server_Internal setzen.
7. Destination zones auf WAN setzen.
8. Destination networks auf dieselbe externe Zeitquelle wie in der SNAT-Regel setzen, im Beispiel host_Google-NTP. Hier gibt es kein DNAT; ursprüngliches und tatsächliches Ziel sind identisch.
9. Services auf NTP setzen, Action auf Accept.
10. Die Regel oberhalb allgemeiner Regeln platzieren, die sonst zuerst greifen würden, und 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, im Beispiel net_Internet-LAN.
6. Original destination auf die Firewall- oder Gateway-IP setzen, die Clients als NTP-Ziel verwenden, im Beispiel host_internal-firewall-ip.
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. Bei Inbound interface die betroffenen internen Client-Interfaces auswählen, im Beispiel Port2.
11. Translated service (PAT) auf Original belassen; Outbound interface bleibt bei dieser DNAT-Regel Any.
12. 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 die interne LAN-Zone oder DMZ.
8. Destination networks auf das IPv4-Hostobjekt für die ursprünglich angesprochene Firewall- oder Gateway-IP setzen, zum Beispiel host_internal-firewall-ip, wie bei Original destination der Client-DNAT-Regel. Nicht NTP_Server_Internal auswählen; dieser Host bleibt Translated destination (DNAT).
9. Services auf NTP setzen.
10. Action auf Accept setzen. Die Regel oberhalb allgemeiner Regeln platzieren, die sonst zuerst greifen würden, und speichern.

Auch hier stammt Destination zones vom übersetzten internen Ziel, während Destination networks die ursprüngliche Firewall- oder Gateway-IP enthält. Neue Client-Sitzung, Regel-IDs und Paketpfad sind für dieses Regelpaar separat zu prüfen. MASQ sorgt ausserdem für einen eindeutigen Rückweg über die Firewall, verbirgt gegenüber dem internen NTP-Server aber die ursprüngliche Client-IP. Wer die Client-IP am Zeitserver für Logging oder Zugriffskontrolle benötigt, sollte statt dieses Relay-Musters eine direkte Freigabe und eine passende Rückroute planen.

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: begrenzt den von dieser Relay-Regel erfassten Verkehr auf den definierten 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.

Wenn IPS für diese NTP-Regel verwendet wird, sollte die zugewiesene IPS-Policy ausdrücklich NTP-bezogene Signaturen (IPS-Patterns) enthalten. Damit richtet sich die zusätzliche Kontrolle gezielt auf Angriffe gegen NTP-Dienste; eine nur allgemein als passend bezeichnete Policy ersetzt diese Auswahl nicht.

⚠️ 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, sofern der jeweilige Client diese Option tatsächlich unterstützt und verwendet. Domänenmitglieder können stattdessen ihrer Domänen-Zeithierarchie folgen; die wirksame Zeitquelle wird deshalb am Client geprüft. 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 als NTP-Client separat konfigurieren

Die NTP-Weiterleitung für Clients ist nicht dasselbe wie die Systemzeit der Sophos Firewall. Unter Administration > Time stehen in SFOS 22.0 drei Einstellungen zur Wahl:

Unveränderte Ist-Ansicht der eigenen Firewall-Uhr: Use pre-defined NTP server, Europe/Zurich. Keine Client-Relay-Einstellung und kein Nachweis erfolgreicher Synchronisierung; Sync now und Apply wurden nicht betätigt.

• Use predefined NTP server ist der Default. Die Firewall nutzt NTPv3 und 0.sophos.pool.ntp.org.
• Use custom NTP server akzeptiert IPv4-, IPv6- oder DNS-Adressen; bis zu zehn Server werden in der angezeigten Reihenfolge geprüft.
• Do not use NTP server stellt Datum und Uhrzeit manuell ein und ist für den laufenden Betrieb nicht empfohlen.

Nach einer Serverauswahl kann man Sync now wählen und danach Apply. Current time aktualisiert sich nach Sync now erst, wenn WebAdmin neu geladen wird. Die Zeitzone wird auf derselben Seite passend zum Standort gesetzt.

⚠️ Auswirkung auf VPN: Wenn man die NTP-Zeitserver ändert, werden laut Sophos alle IPsec-Verbindungen neu aufgebaut. Die Änderung gehört deshalb in ein passendes Wartungsfenster.

Beide Datenpfade sollten 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.

Den Log viewer öffnet man rechts oben in WebAdmin. Im Firewall-Modul kann man über Add filter nach Regel, IP oder Port filtern; alternativ findet die Freitextsuche 123, Client-IP oder Regelname. Sitzungslogs erscheinen nicht zwingend sofort: Die Firewall protokolliert die Sitzung beim internen Destroy-Ereignis. Bei UDP wartet man gegebenenfalls auf das Sitzungsende; UDP hat keinen TCP-Verbindungsabbau.

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. Unter Configure begrenzt der BPF-Ausdruck port 123 die Aufnahme auf NTP. Nach dem Einschalten von Packet capture sollte das eingehende Paket die Client-IP, die Firewall-IP und UDP 123 zeigen; das weitergeleitete Paket zeigt das übersetzte Ziel. NAT ID und Rule ID müssen den erstellten Regeln entsprechen. Incoming und Forwarded belegen den Weg, Consumed würde dagegen ein für die Firewall selbst bestimmtes Paket kennzeichnen; Violation und Reason erklären einen Drop.

Eine erfolgreiche Weiterleitung allein bestätigt noch keine Zeitsynchronisierung. Zusätzlich muss der NTP-Status am Client eine gültige Antwort und einen synchronisierten Zustand zeigen; bei Variante B wird auch der Synchronisierungsstatus des internen Zeitservers geprüft. Im Paketmitschnitt erwartet man eine Antwort vom echten Zeitserver und auf dem Rückweg zum Client wieder die angesprochene Gateway-IP als Absender. Fehlt die Antwort, werden zuerst Erreichbarkeit, Rückweg und die Zugriffskontrolle des Zeitservers für die MASQ-Adresse geprüft.

Als Negativtest sendet ein Client aus einem nicht freigegebenen internen Netz eine neue NTP-Anfrage an die Gateway-IP. Die erstellte Client-DNAT-Regel und die zugehörige Freigabe dürfen dafür nicht treffen. Wird die Anfrage trotzdem weitergeleitet, sucht man nach einer früheren oder breiteren NAT-/Firewall-Regel. Eine Anfrage eines freigegebenen Clients direkt an eine andere NTP-Adresse darf ebenfalls nicht durch diese Gateway-IP-DNAT-Regel umgebogen werden. Ob direktes NTP erlaubt oder blockiert wird, bestimmt die übrige Firewall-Policy; dieses Relay allein erzwingt keine zentrale Zeitquelle für jeden Verkehr.

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.

Rollback

Wenn das Relay Probleme verursacht, zuerst die neu erstellte Client-DNAT-Regel deaktivieren und einen neuen NTP-Test auslösen. Danach die zugehörige Firewall-Regel deaktivieren. Bei Variante B werden SNAT- und WAN-Firewall-Regel des internen Zeitservers nur entfernt, wenn dieser sie nicht mehr für seine eigene Synchronisierung benötigt. Erst wenn keine Treffer und keine Abhängigkeiten mehr bestehen, können Regeln und die ausschliesslich dafür angelegten Hostobjekte gelöscht werden. Clients müssen anschliessend direkt einen erreichbaren NTP-Server erhalten, beispielsweise per DHCP-Option 42; sonst verlieren sie ihre Zeitquelle.

FAQ