Probleme mit NTP

[psychofaktory]

Hallo liebe OPNsense-Gemeinde,

ich habe ein Problem mit der Systemzeit in meinem Netzwerk.

Folgende Ausgangssituation:
OPNsense 21.1.5-amd64 auf Unraid 6.9.2 als VM
VM-Konfiguratioin unter Unraid: "Gerät": i440fx-5.1"; BIOS: "OVMF"; 2 logigische CPUs isoliert zugewiesen; 4GB RAM zugewiesen; CPU-Modus "Pathtrough"; 2 Ports einer 4-Port Intel I350-PCIe-Karte an OPNsense durchgereicht

In OPNsense unter "Netzwerk-Zeit" sieht es wie folgt aus:
Schnittstelle(n): "Nothing selected"
Zeitserver: insgesamt 4 Zeitserver eingetragen, 2 davon bevorzugt; alle 4 sind gültig und erreichbar
sonst sind die Standardeinstellungen gesetzt.

Die Zeitsynchronisation läuft immer wieder sauber durch. Die Clients können ihre Zeit auch problemlos von der OPNsense beziehen. Nach einiger Zeit scheint die Synchronisation jedoch nicht mehr zu funktionieren. Die Systemzeit der OPNsense weicht nach 24 Stunden bis zu 30 Minuten von der tatsächlichen Zeit ab.
Wird der ntpd-Dienst neu gestartet funktioniert dann wieder alles.

Ich habe jetzt gelesen, dass es unter virtuellen Installationen derartige Probleme geben kann, da die Hardware-Zeit der BIOS-Uhr nicht richtig durchgereicht werden kann, bzw. deren Virtualisierung Probleme bereitet.

In diesen Fällen wird dann wohl dazu geraten Statt ntpd "chrony" zu verwenden, da das in derartigen fällen wohl robuster ist.

Ich habe daher die Erweiterung "os-chrony" installiert, dann den Dienst ntpd-Dienst gestoppt, alle vorhandenen Einträge unter ntpd gelöscht und ntpd somit deaktiviert.


Dann habe ich in der Konfiguration zu chrony den Haken bei "Aktiviert" gesetzt, den Port von "323" auf "123" geändert, die gleichen Zeitserver wie zuvor unter ntpd genutzt eingetragen, und meine internen Netzwerke unter "erlaubte Netzwerke" hinterlegt.

Sobald ich nun auf "Speichern" klicke ist die Weboberfläche nicht mehr erreichbar. Auch nicht nach einem Neustart über die Konsole. Ich muss erst ein Backup einspielen damit ich wieder auf die Webkonfiguration gelange. Der Fehler lässt sich beliebig oft reproduzieren.

Zum Test habe ich bei meiner Vorgehensweise in chrony die Standardkonfiguration belassen und lediglich den Haken bei "Aktiviert" gesetzt. Auch dann war die Weboberfläche ab diesem Moment nicht mehr zu erreichen.

Wo liegt hier der Fehler?
Wie kann ich chrony nutzen und sicherstellen, dass die Zeit auf meinen Systemen synchron bleibt?

[psychofaktory]

Mir ist eben aufgefallen dass der Fehler seit Thread-Erstellung eben wieder aufgetreten ist.

im ntpd-Protokoll steht folgendes:

Code Select Expand

2021-05-12T19:00:03 ntpd[71141] receive: Unexpected origin timestamp 0xe4468813.3c7638f4 does not match aorg 0000000000.00000000 from server@2001:638:a000:1123:123::2 xmt 0xe4468813.6915f562

Code Select Expand

2021-05-12T18:59:56 ntpd[71141] kernel reports TIME_ERROR: 0x4041: Clock Unsynchronized

Außerdem ist mir unter "Schnittstellen" -> "Überblick" bei der WAN-Schnittstelle aufgefallen, dass dort kein vom Provider zugewiesener IPv6-Präfix mehr angezeigt wird.
Ich habe die PPPoE-Verbindung nochmal neu laden lassen, aber erhalte dennoch keinen Präfix mehr.
Das finde ich auch etwas merkwürdig.

Provider ist die Deutsche Telekom; mein Tarif ist Magenta Zuhause L (VDSL100); als Modem wird ein Draytek Vigor 166 im Bridge-Modus eingesetzt. PPPoE-Einwahl und VLAN7-tagging übernimmst die OPNsense.


Was stimmt hier nicht?

[lewald]

Moin,

hier mal ein paar Anmerkungen.

Du mixt derzeit drei verschiedene Probleme in diesem einen Thread.
Nicht besonders gut geeignet um Antworten zu bekommen.

Zum 1 Problem.

OPNsense ist außer Sync.
Das wird wohl in der Tat ein Problem mit unraid und OPNsense sein.

Habe zu diesem Thema folgendes im Netz gefunden.
https://www.reddit.com/r/unRAID/comments/a1yw5b/vm_clock_vs_hwclock_driving_me_nuts/

Das ist ähnlich wie bei Dir. Du solltest im unraid Forum fragen warum sowas vorkommen kann.
Denn so eine krasse Zeit Abweichung ist nicht normal. Ich betreibe diverse OPNsense innerhalb verschiedener Virtualisierungsumgebungen (Kein unraid). Mit so einer Zeit Abweichung ist die Firewall an sich nicht mal richtig zu gebrauchen geschweige den als Zeit Server zu nutzen.

Zu Punkt 2.

Da bist du ja hingekommen weil das Zeit abgleichen per NTP scheinbar nicht so toll in vms ist.
Was mit Sicherheit so nicht ist. Der NTP gleicht beim starten die zeit ab. Wenn da mehr kommen soll muss man es konfigurieren. Ich habe da im Forum nur das Thema Cron Job zu gefunden.

Gut nun das alles war der Grund warum Du chrony probieren wolltest.
Und Du hast recht. Das lässt sich via GUI scheinbar nicht aktivieren. Hab das selbst mal probiert.
Da an die Macher vom chrony Plug IN. Das ist derzeit wohl defekt im OPNsense 21.1.5. Ein einfacher Neustart von OPNsense reicht aber aus um wieder in das Interface zu kommen.


Zu Punkt 3.

Da kann ich nichts zu beitragen.

[psychofaktory]

Vielen Dank für die Anmerkungen.
Sie haben mich auf jeden Fall schon mal ein Stück weiter geführt.

Ich hatte die Themen alle in dem Thread aufgeführt, weil ich leider nicht beurteilen kann in wie weit hier eventuell Zusammenhänge bestehen.
Nicht dass hier etwas übersehen wird weil ich ein womöglich wichtiges Detail weggelassen habe.

Vielleicht versuche ich es etwas besser zu strukturieren:

Die Systemzeit in OPNsense (VM) beginnt immer wieder vom VM-Host (Unraid) abzuweichen.
Ich habe hierzu etwas recherchiert. Offenbar verwendet OPNsense (FreeBSD) bestimmte Zeitzähler.
Meine ausgelesenen Werte wären:

Code Select Expand

root@ADL15-FW001:~ # dmesg | grep Timecounter
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec

Code Select Expand

root@ADL15-FW001:~ # sysctl kern.timecounter
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 0
kern.timecounter.invariant_tsc: 0
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: i8254(0) ACPI-fast(900) TSC-low(-100) dummy(-1000000)
kern.timecounter.hardware: ACPI-fast
kern.timecounter.alloweddeviation: 5
kern.timecounter.timehands_count: 2
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 19671
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.counter: 1961978
kern.timecounter.tc.ACPI-fast.mask: 16777215
kern.timecounter.tc.TSC-low.quality: -100
kern.timecounter.tc.TSC-low.frequency: 1909497435
kern.timecounter.tc.TSC-low.counter: 4174462623
kern.timecounter.tc.TSC-low.mask: 4294967295
Unter Unraid wurden in der Konfiguration der VM bei Erstellung (automatisch) folgende Werte dazu gesetzt:

Code Select Expand

<clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
Die Werte für die Zeitzähler in der VM-Konfiguration unter Unraid und die die OPNsense nutzt müssen nach meinem Verständnis zusammenpassen.
Allerdings konnte ich noch nicht herausfinden welche Anpassungen genau an welcher Stelle hier vorzunehmen sind damit alles zusammenpasst.
Ich habe hierzu auch schon einen Thread im Unraid-Forum eröffnet.


Die chrony-Erweiterung lässt sich nicht aktivieren.
Bei mir war es leider so, dass ich auch nach einem Neustart nicht mehr auf das Web-Inferface gekommen bin.
Bzw. in einem weiteren Versuch konnte ich die Weboberfläche kurzzeitig nach dem Start erreichen. Sobald ich dann aber auf "Dienste" -> "chrony" bin war ich wieder ausgesperrt.


Der vom Provider zugewiesene IPv6-Präfix wird in der Übersicht der Schnittstellen unter "WAN" nicht mehr angezeigt.
Noch später am selben Abend als ich meinen Post hier eingestellt hatte wurde die Info plötzlich wieder angezeit. Von meiner Seite aus wurde hier nichts angepasst. Auch die Internetverbindung wurde nicht neu aufgebaut.

Ich vermute hier einfach mal, dass es zu den verschiedensten Problemen kommen kann wenn OPNsense außer Sync gerät und wahrscheinlich einige Probleme verschwinden würden wenn hier der Sync mit dem Host sauber laufen würde.


Ist mein Ansatz hier der richtige?
Weiß jemand welche Anpassungen ich hier machen könnte um den Fehler zu beheben?
Ist meine ntpd-Konfiguration ansonsten korrekt?
Gibt es einen Trick wie ich chrony dennoch aktivieren kann?

[JeGr]

Ich würde erst einmal das zu Grunde liegende Problem bzgl ntp lösen bevor ich andere Pakete dafür heran ziehe. Ich hatte noch bei meiner Installationen ob virtuell oder HW das Problem dass ich was anderes als ntpd benötigt habe um eine vernünftige Zeit zu bekommen. das Paket hat sicher seinen Sinn aber warum schon irgendwas als workaround nutzen wenn das eigentliche Problem tiefer liegt?

Cheers

[psychofaktory]

Danke für Deine Einschätzung JeGr.
Ich denke auch es wäre sinnvoller zuerst die Systemzeit von Unraid und OPNsense in Einklang zu bringen.

Wenn ich bisher alles richtig interpretiere werden in der aktuellen Standardkonfiguration Host-seitig von Unraid folgende Timer zum Abgleich zur Verfügung gestellt:

• rtc (catchup)
• pit (delay)
• hpet (not present)

OPNsense unterstützt folgende Timer:

• i8254 (0)
• ACPI-fast (900)
• TSC-low (-100)
• dummy (-1000000)

   
Wobei in meinem Fall aktuell wohl "ACPI-fast" genutzt wird.

Damit Unraid und OPNsense sich abgleichen können müssen die verwendeten Timer auf beiden Seiten identisch sein.
Hier erkenne ich aber keine Übereinstimmungen.

Im Unraid-Forum habe ich den Hinweis gefunden, dass man 'tsc' als Timer in Unraid zur Konfiguration hinzufügen kann. So ist es auch in der libvirt-Dokumentation aufgeführt.

Wie kann ich der OPNsense sagen sie soll statt 'ACPI-fast' 'TSC-low' nutzen?
Und wäre das überhaupt der richtige Ansatz?

[wurmloch]

Moin,

das soll jetzt keine ketzerische Frage sein, aber warum auf irgendwelche Hypervisoren und deren Mechanismen vertrauen?

Vorschlag:
Es gibt einen (vielleicht auch redundanten) time server im LAN, der alle Maschinen mit der korrekten Zeit versorgt. Die holt er sich zB von der PTB.DE

Alle Fragen nach der Zeit (123/TCP / 123/UDP) aus dem LAN werden von Firewall/Gatway/Router auf diese Maschine umgelenkt. Dazu werden DNS-Anfragen zu der IP der "üblichen Verdächtigen" wie "time.windows.com" vom lokalen DNS mit der IP ebendieses Zeitservers beantwortet.

Ferdsch  :)

Ist das nicht eleganter und einfacher?

LG

[psychofaktory]

Ich denke dieser Ansatz wäre zwar intern für die anderen Geräte im LAN hilfreich, aber für die OPNsense-Instanz nicht zielführend.

Nach meinem Verständnis ist es unerheblich woher OPNSense die aktuelle Zeit bezieht. Die Abfrage bei einem (bzw. mehreren redundanten) öffentlichen NTP-Server(n) funktioniert ja und wird es sicherlich ebenso von einem NTP-Server im LAN.
Aber solange es beim internen Zeitzähler hardwarseitig, oder wie hier innerhalb der virtuellen Umgebung, immer wieder zu (teils größeren) Abweichungen kommt, wird OPNSense zumindest bis zur nächsten NTP-Abfrage wieder mit der falschen Zeit laufen. Bei einer zu großen Abweichung scheitert dann wohl auch die Abfrage an sich und die Systemzeit läuft gänzlich willkürlich.

Alle Fragen nach der Zeit (123/TCP / 123/UDP) aus dem LAN werden von Firewall/Gatway/Router auf diese Maschine umgelenkt.

Das wäre ja nur dann erforderlich, wenn an einem Client im LAN der Zeitserver hard-coded wäre und man Zeitabweichungen zwischen dem eigenen internen Zeitserver und dem hart kodiertem öffentlichen vermeiden wöllte. Das ist bei meinen Geräten nicht der fall. Hier kann ich die Adresse des Zeitservers überall statisch festlegen, oder via DHCP übergeben. Eventuelle zeitabweichungen sollten aber auch nicht allzu gravierend sein.

[wurmloch]

Aber solange es beim internen Zeitzähler hardwarseitig, oder wie hier innerhalb der virtuellen Umgebung, immer wieder zu (teils größeren) Abweichungen kommt, wird OPNSense zumindest bis zur nächsten NTP-Abfrage wieder mit der falschen Zeit laufen. Bei einer zu großen Abweichung scheitert dann wohl auch die Abfrage an sich und die Systemzeit läuft gänzlich willkürlich.

Volle Zustimmung. Ich bin allerdings davon ausgegangen, dass der NTP Service der OPNsense in regelmäßigen Abständen seine Zeitquelle abfragt und die Zeit der OPNsense entprechend stellt.

Das ist vielleicht eine Annahme, die schlicht falsch ist, das weiß ich nicht. Falls das zutrifft, dann würde ich bei meinen Netzen dringend Anpassungen vornehmen müssen. Ich habe gerade in die OPNsense Doku geschaut und keine Info über die Regelmäßigkeit/Häufigkeit der Zeitabfrage gefunden.

Falls die Zeit der OPNsense dramatisch schnell in die Differenz läuft, könnte dieses Intervall doch verkürzt werden? Aber ich denke, das ist in Deinem Fall eher Arbeiten an einem Symptom und nicht an der Ursache.

Alle Fragen nach der Zeit (123/TCP / 123/UDP) aus dem LAN werden von Firewall/Gatway/Router auf diese Maschine umgelenkt.

Das wäre ja nur dann erforderlich, wenn an einem Client im LAN der Zeitserver hard-coded wäre und man Zeitabweichungen zwischen dem eigenen internen Zeitserver und dem hart kodiertem öffentlichen vermeiden wöllte. Das ist bei meinen Geräten nicht der fall. Hier kann ich die Adresse des Zeitservers überall statisch festlegen, oder via DHCP übergeben. Eventuelle zeitabweichungen sollten aber auch nicht allzu gravierend sein.

Schon alles erlebt (und teilweise noch aktuell): Geräte, die einen Zeitserver in taiwan fest codiert hatten; Geräte, die sich nicht um einen eingetragenen Zeitserver scheren; Geräte die den DHCP-Parameter mit dem zu nutzenden Zeitserver schlicht ignorieren. Und das quer durch Server- und Client-Betriebssysteme oder embedded devices. Das hat mich am Ende zu "meiner" best practice geführt.

LG

[psychofaktory]

Was ich gelesen habe fragt der NTP-Dienst regelmäßig seine Zeitquelle ab, legt den Intervall hierfür aber eigenständig fest. Man kann dieses Verhalten wohl beeinflussen indem man einen Minimalwert und einen Maximalwert dafür festlegt.

Häufigeres Abfragen würde die Probleme sicherlich verringern, aber wohl nicht beheben.
Einige Zeitserver blocken die Peers bei zu häufigen Anfragen. Ich müsste dann zwangsläufig auf die Variante mit dem dediziertem Zeitserver im LAN arbeiten.
Grundsätzlich gibt es aber einige Dienste die Probleme mit den Zeitsprüngen haben die sich bei den Sychronisationen ergeben. Das lässt sich wohl nur lösen indem die eigentlich Ursache gefunden und behoben wird.

Hier klingt für mich der Ansatz mit den Zeitzählern sehr vielversprechend.
Allerdings weiß ich leider noch nicht wie ich die nötigen Anpassungen vornehmen kann und welches die richtigen Werte seitens Unraid und seitens OPNsense wären.

[lewald]

Ok geh mal auf die OPNsense Shell

Was gibt  sysctl kern.timecounter.hardware zurück?

Bei meinen Vms mit Proxmox kommt HPET.   

[psychofaktory]

Code Select Expand

root@ADL15-FW001:~ # sysctl kern.timecounter.hardware
kern.timecounter.hardware: ACPI-fast


Hier kommt ACPI-fast.
Wie kann ich das umstellen?

[lewald]

Code Select Expand

<clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>

evtl. beim unraid mal das hpet auf yes

[psychofaktory]

Vielen Dank für diesen Tipp!!

Code Select Expand

root@ADL15-FW001:~ # sysctl kern.timecounter.hardware
kern.timecounter.hardware: HPET

OPNsense nutzt jetzt tatsächlich HPET.

Code Select Expand

root@ADL15-FW001:~ # dmesg | grep Timecounter
Timecounter "HPET" frequency 100000000 Hz quality 950
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec


Code Select Expand

root@ADL15-FW001:~ # sysctl kern.timecounter
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 0
kern.timecounter.invariant_tsc: 0
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: i8254(0) ACPI-fast(900) HPET(950) TSC-low(-100) dummy(-            1000000)
kern.timecounter.hardware: HPET
kern.timecounter.alloweddeviation: 5
kern.timecounter.timehands_count: 2
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 49369
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.counter: 3004578
kern.timecounter.tc.ACPI-fast.mask: 16777215
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.HPET.frequency: 100000000
kern.timecounter.tc.HPET.counter: 2725944664
kern.timecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.TSC-low.quality: -100
kern.timecounter.tc.TSC-low.frequency: 1908553173
kern.timecounter.tc.TSC-low.counter: 1216703817
kern.timecounter.tc.TSC-low.mask: 4294967295


Ich werde die Zeit jetzt mal genau im Auge behalten.

[psychofaktory]

Es sah vielversprechend aus, kam dann aber doch wieder zu Abweichungen.

Ich hatte das Verhalten jetzt seit den Anpassung vorhin beobachtet.
Die Zeit verlief wunderbar synchron, bis diese Meldungen im NTP-Protokoll auftauchten:

Code Select Expand

2021-05-15T17:44:15 ntpd[78666] receive: Unexpected origin timestamp 0xe44a6acf.564f8c38 does not match aorg 0000000000.00000000 from server@2001:638:809:7::7 xmt 0xe44a6acf.c7f0dbb0
2021-05-15T17:44:15 ntpd[78666] receive: Unexpected origin timestamp 0xe44a6acf.5659de65 does not match aorg 0000000000.00000000 from server@2001:638:610:be01::104 xmt 0xe44a6acf.c6d26f56
2021-05-15T17:44:15 ntpd[78666] receive: Unexpected origin timestamp 0xe44a6acf.5656d4d0 does not match aorg 0000000000.00000000 from server@2001:638:a000:1123:123::2 xmt 0xe44a6acf.c67a89cb

Im "Status" stehen seitdem alle Server auf Unerreichbar/Ausstehend.
Erst nach Neustart des ntpd-Dienstes wird wieder mit den NTP-Servern synchronisiert.


Was bedeutet die Fehlermeldung und wie kann ich den Fehler beheben?