NTP Problem - 0x800705B4 - funktioniert auf keinem Server
Hallo zusammen,
wir haben vor Kurzem einen neuen Kunden übernommen und festgestellt, dass NTP überhaupt nicht funktioniert.
Da wir zunächst keinen Zugriff auf die bestehende Firewall hatten, haben wir das Thema erstmal hintenangestellt. Inzwischen wurde die Firewall durch eine eigene ersetzt – dennoch funktioniert NTP weiterhin nicht.
Woran es liegt, ist unklar. Die neue Firewall blockiert laut Logs nichts – sämtliche Verbindungen werden laut LOGS korrekt durchgelassen.
Folgendes wurde bereits getestet:
Genauere Informationen:
Ich freue mich über jede Unterstützung.
wir haben vor Kurzem einen neuen Kunden übernommen und festgestellt, dass NTP überhaupt nicht funktioniert.
Da wir zunächst keinen Zugriff auf die bestehende Firewall hatten, haben wir das Thema erstmal hintenangestellt. Inzwischen wurde die Firewall durch eine eigene ersetzt – dennoch funktioniert NTP weiterhin nicht.
Woran es liegt, ist unklar. Die neue Firewall blockiert laut Logs nichts – sämtliche Verbindungen werden laut LOGS korrekt durchgelassen.
Folgendes wurde bereits getestet:
- Lokale Windows-Firewall komplett deaktiviert
- UDP-Port 123 (NTP) explizit in der lokalen Firewall freigegeben
- Testweise eine Any-Regel für die betroffenen Hosts auf der Hardware-Firewall aktiviert
- NTP-Dienst registriert, deregistriert, Registry-Werte angepasst, verschiedene Zeitserver (Cloudflare, AWS etc.) ausprobiert
- NTP-Dienst gestoppt, neugestartet und erneut getestet
Genauere Informationen:
- Abbildungen sind von dem Haupt AD
Ich freue mich über jede Unterstützung.
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672688
Url: https://administrator.de/forum/ntp-problem-0x800705b4-funktioniert-auf-keinem-server-672688.html
Ausgedruckt am: 30.04.2025 um 20:04 Uhr
9 Kommentare
Neuester Kommentar
Hallo,
laufen der/die Server direkt auf Blech oder unter einem Hypervisor virtuell? Falls Hyper-V verwendet wird dann die Einstellungen an der Vm im Client zur Zeitsynchronisation mit dem Host abschalten. Ansonsten wären mehr Infos zur Situation nötig
laufen der/die Server direkt auf Blech oder unter einem Hypervisor virtuell? Falls Hyper-V verwendet wird dann die Einstellungen an der Vm im Client zur Zeitsynchronisation mit dem Host abschalten. Ansonsten wären mehr Infos zur Situation nötig
Hallo,
Die VMs laufen in VMWare ESXi.
Sollte ich noch etwas in VMWare einstellen? vielen Dank!
Die VMs laufen in VMWare ESXi.
Sollte ich noch etwas in VMWare einstellen? vielen Dank!
Zitat von @wollekuj:
Hallo,
laufen der/die Server direkt auf Blech oder unter einem Hypervisor virtuell? Falls Hyper-V verwendet wird dann die Einstellungen an der Vm im Client zur Zeitsynchronisation mit dem Host abschalten. Ansonsten wären mehr Infos zur Situation nötig
Hallo,
laufen der/die Server direkt auf Blech oder unter einem Hypervisor virtuell? Falls Hyper-V verwendet wird dann die Einstellungen an der Vm im Client zur Zeitsynchronisation mit dem Host abschalten. Ansonsten wären mehr Infos zur Situation nötig
Ich habe jetzt versucht, die Zeitsynchronisation in VMWare auszuschalten, aber leider hilft das nicht... immer noch erfolglos.
Schau mal in den Gruppenrichtlinien. Wir hatten den Fall, dass wir eine Richtlinie hatten, die dafür gesorgt hat, dass NTP im Kreis gelaufen ist.
In der Default Domain Controller Policy gibst du deinen bevorzugen externen NTP-Server an und in der Default Domain Policy einen Round Robin DNS-Eintrag der die DC beinhaltet, mit dem sich die Clients synchronisieren sollen.
Alternativ, wenn du HP-Switches hast, gibt es eine Funktion, die mit DoS Protection oder ähnlichem beschriftet ist, die dafür sorgt, dass Dienste, deren Source- und Destination-Port identisch sind (was bei NTP gegeben ist) einfach nicht mehr funktionieren.
In der Default Domain Controller Policy gibst du deinen bevorzugen externen NTP-Server an und in der Default Domain Policy einen Round Robin DNS-Eintrag der die DC beinhaltet, mit dem sich die Clients synchronisieren sollen.
Alternativ, wenn du HP-Switches hast, gibt es eine Funktion, die mit DoS Protection oder ähnlichem beschriftet ist, die dafür sorgt, dass Dienste, deren Source- und Destination-Port identisch sind (was bei NTP gegeben ist) einfach nicht mehr funktionieren.
Zitat von @tikayevent:
Schau mal in den Gruppenrichtlinien. Wir hatten den Fall, dass wir eine Richtlinie hatten, die dafür gesorgt hat, dass NTP im Kreis gelaufen ist.
In der Default Domain Controller Policy gibst du deinen bevorzugen externen NTP-Server an und in der Default Domain Policy einen Round Robin DNS-Eintrag der die DC beinhaltet, mit dem sich die Clients synchronisieren sollen.
Alternativ, wenn du HP-Switches hast, gibt es eine Funktion, die mit DoS Protection oder ähnlichem beschriftet ist, die dafür sorgt, dass Dienste, deren Source- und Destination-Port identisch sind (was bei NTP gegeben ist) einfach nicht mehr funktionieren.
Schau mal in den Gruppenrichtlinien. Wir hatten den Fall, dass wir eine Richtlinie hatten, die dafür gesorgt hat, dass NTP im Kreis gelaufen ist.
In der Default Domain Controller Policy gibst du deinen bevorzugen externen NTP-Server an und in der Default Domain Policy einen Round Robin DNS-Eintrag der die DC beinhaltet, mit dem sich die Clients synchronisieren sollen.
Alternativ, wenn du HP-Switches hast, gibt es eine Funktion, die mit DoS Protection oder ähnlichem beschriftet ist, die dafür sorgt, dass Dienste, deren Source- und Destination-Port identisch sind (was bei NTP gegeben ist) einfach nicht mehr funktionieren.
Hallo,
danke für deine Hilfe.
In der Domäne ist, denke ich, eher weniger etwas. Ich habe hier einen Test-Linux-Host, der nicht in der Domäne ist, und auch hier funktioniert es leider nicht.
Ich vermute, es muss irgendetwas am Switch oder Ähnlichem liegen – irgendeine bestimmte Funktion, denke ich, da kein Host per NTP nach außen kommt.
Moin,
Du testet ja immer nach außen. Nur vom DC aus? Wie sieht es denn an einem Client aus, kommt der raus (dann wäre Firewall ja nicht das Problem)?
Was passiert denn beim Setzen einer neuen Source? Der Fehler oben sagt ja nichts anderes, als dass lokal keine Source erreichbar ist (Windows Time Sync error: 0x800705B4).
Teste mal bei einem Client mit einer NTP-Clientsoftware und so etwas wie ptbtime1.ptb.de als Server: www.meinberg.de/german/sw/ntp.htm
Gruß
DivideByZero
P.S.: Sehe gerade Deinen Post. Dann teste doch mal direkt die Ports und hänge Dich ohne Switch direkt an die Firewall, ggf. auch mal daran vorbei, um das blockierende Gerät zu finden.
Du testet ja immer nach außen. Nur vom DC aus? Wie sieht es denn an einem Client aus, kommt der raus (dann wäre Firewall ja nicht das Problem)?
Was passiert denn beim Setzen einer neuen Source? Der Fehler oben sagt ja nichts anderes, als dass lokal keine Source erreichbar ist (Windows Time Sync error: 0x800705B4).
Teste mal bei einem Client mit einer NTP-Clientsoftware und so etwas wie ptbtime1.ptb.de als Server: www.meinberg.de/german/sw/ntp.htm
Gruß
DivideByZero
P.S.: Sehe gerade Deinen Post. Dann teste doch mal direkt die Ports und hänge Dich ohne Switch direkt an die Firewall, ggf. auch mal daran vorbei, um das blockierende Gerät zu finden.
Kann die eigesetzte Firewall denn evtl auch ntp?
Vlt an einem Client mal
w32tm /config /manualpeerlist:"firewallip",0x8 /syncfromflags:MANUAL
net stop "windows time"
net start "windows time"
w32tm /resync
Vlt an einem Client mal
w32tm /config /manualpeerlist:"firewallip",0x8 /syncfromflags:MANUAL
net stop "windows time"
net start "windows time"
w32tm /resync
Zitat von @DivideByZero:
Moin,
Du testet ja immer nach außen. Nur vom DC aus? Wie sieht es denn an einem Client aus, kommt der raus (dann wäre Firewall ja nicht das Problem)?
Was passiert denn beim Setzen einer neuen Source? Der Fehler oben sagt ja nichts anderes, als dass lokal keine Source erreichbar ist (Windows Time Sync error: 0x800705B4).
Teste mal bei einem Client mit einer NTP-Clientsoftware und so etwas wie ptbtime1.ptb.de als Server: www.meinberg.de/german/sw/ntp.htm
Gruß
DivideByZero
P.S.: Sehe gerade Deinen Post. Dann teste doch mal direkt die Ports und hänge Dich ohne Switch direkt an die Firewall, ggf. auch mal daran vorbei, um das blockierende Gerät zu finden.
Moin,
Du testet ja immer nach außen. Nur vom DC aus? Wie sieht es denn an einem Client aus, kommt der raus (dann wäre Firewall ja nicht das Problem)?
Was passiert denn beim Setzen einer neuen Source? Der Fehler oben sagt ja nichts anderes, als dass lokal keine Source erreichbar ist (Windows Time Sync error: 0x800705B4).
Teste mal bei einem Client mit einer NTP-Clientsoftware und so etwas wie ptbtime1.ptb.de als Server: www.meinberg.de/german/sw/ntp.htm
Gruß
DivideByZero
P.S.: Sehe gerade Deinen Post. Dann teste doch mal direkt die Ports und hänge Dich ohne Switch direkt an die Firewall, ggf. auch mal daran vorbei, um das blockierende Gerät zu finden.
Hallo,
ich habe gerade auch aus einem Linux-Host getestet, und es funktioniert ebenfalls nicht. Auch von einem Windows-Client aus habe ich es versucht, ohne Erfolg. Das Problem tritt nicht nur im DC auf, sondern überall.
Das Tool habe ich ebenfalls heruntergeladen und getestet, jedoch funktioniert es auch darüber nicht.
Das Setzen einer Source bzw. mehrerer Sources habe ich ebenfalls schon ausprobiert.
Viele Grüße
Moin,
Schmeiß
a) WireShark an und schau was passiert
b) das Logging in der vorgelagerten Firewall (welche eigentlich? pfSense? Sophos? Sonicwall?…) an und schaue, wo die Pakete kleben bleiben.
BTW: unsere DCs fragen die Zeit an unserer Firewall an. Diese leitet die Anfragen dann als Stellvertreter an extern weiter. Früher war unsere Sophos selbst in Richtung WAN als NTP Client aktiv und in Richtung LAN als NTP-Server. Somit musste man kein (ausgehendes) Loch in die Firewall bohren
Schmeiß
a) WireShark an und schau was passiert
b) das Logging in der vorgelagerten Firewall (welche eigentlich? pfSense? Sophos? Sonicwall?…) an und schaue, wo die Pakete kleben bleiben.
BTW: unsere DCs fragen die Zeit an unserer Firewall an. Diese leitet die Anfragen dann als Stellvertreter an extern weiter. Früher war unsere Sophos selbst in Richtung WAN als NTP Client aktiv und in Richtung LAN als NTP-Server. Somit musste man kein (ausgehendes) Loch in die Firewall bohren
