OPNsense Forum
International Forums => German - Deutsch => Topic started by: der_dom on August 16, 2019, 04:08:05 pm
-
Hallo zusammen,
ich habe das Problem, dass sich, wie bei vielen anderen auch, der NTPD nicht mit einem NTP Server synct.
Lokal übernimmt die Aufgabe ein PI - der Port 123 ist auf dem Teil frei und er kann auch verteilen - soll er aber nicht (bis auf an die OPNSense - ich weiß, das klingt absurd aber ist so).
Die Meldungen im Log sind die üblichen:
Aug 16 15:57:15 ntpd[68510]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Aug 16 15:57:15 ntpd[68510]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Aug 16 15:57:15 ntpd[68510]: mlockall(): Cannot allocate memory
Das geht soweit, dass die Zeiten gut und gerne mal eine Stunde abweichen.
Per ntpdate (-u) IP-Adresse funktioniert das Tadellos - ob mit oder ohne (-u).
Der PI hängt (noch) im WAN Netz.
Firewalltechnisch habe ich aus spaß an der Freude mal eine Regel erstellt die besagt, dass das Netz wo der Pi drin hängt (WAN) den einen zulässt und den Port 123 durchlässt - egal von welcher Quelladresse und egal von welchem Quellport im LAN Netzwerk.
Bringt aber nichts.
Gleiches Problem bei externen NTP Servern.
Ich vermute mal, dass irgendwelche IPTable-Rules nicht passen - wobei die Firewall so gut wie jungfräulich ist und nahezu keine Extraregeln inne hat.
Hat irgendwer eine Idee? Bisher hab ich keine brauchbare Lösung gefunden.
-
Firewall Logs ansehen?
-
Hi,
kannst du damit was anfangen?
filterlog: 8,,,0,re1,match,block,in,4,0x10,,64,38317,0,DF,6,tcp,52,xxx.xxx.xxx.x,xxx.xxx.xxx.x,22,29494,0,A,,1595132639,270,,nop;nop;TS
Ich erkenne "nur" dass Traffic geblockt wird. Der NTP Server ist per Roule allerdings freigegeben.
IPv4 UDP xxx.xxx.xxx.x 123 (NTP) LAN Netzwerk * * *
Edith meint:
Per ntpdate kann ich die Zeit ja vom PI ziehen, also denke ich nicht, dass es an der Firewall liegt.
-
In deinem Log wird TCP geblockt, in deiner Rule wird UDP freigegeben.
Sicher das der Logeintrag nicht zu einer anderen Verbindung gehört?
-
Ähmmm nööö, das war ein völliger Trugschluss.
Was mir aufgefallen ist, ist dass die Zeit von der OPNSense ewig langsam läuft. Heute morgen hatte ich einen Versatz von mehreren Stunden gegenüber der korrekten Zeit.
Ich habe zwischenzeitlich die CMOS Zeit von meinem ODROID (da läuft die FW drauf) kontrolliert und korrigiert (waren 2 Stunden hinten an). Danach war die FW 2 Stunden vor mir.
Jetzt läuft das ganze gut 1 1/2 Stunden und der NTP synct noch immer nicht. Ich hab ein Outbound NAT gesetzt: Geht nicht, FW Rules angepasst: Geht nicht.
Vielleicht ist auch einfach die Installation hinüber. Ich setze gleich mal eine VM auf um zu sehen ob sich das Verhalten dort wiederspiegelt. Wenn ja scheint es ein Bug innerhalb des NTP oder der OPNSense zu sein.
Wie schon erwähnt, wenn ich per ntpdate die Daten vom NTP Server fische (egal ob lokal oder extern) dann bekomme ich auch die Zeit - dauert nur relativ lange.
Ich habe zusätzlich noch einen NTP Server im gleichen Subnetz eingerichtet und den in der Sense eingerichtet - Ergebnis bleibt das Gleiche. Unerreichbar / Ausstehend - wobei die Logs sagen: Ist erreichbar.
Danke für eure Unterstützung.
-
Hi,
habe jetzt das gleiche Problem hier festgestellt.
Sep 18 11:27:40 opnsense01 ntpd[68300]: ntpd 4.2.8p13@1.3847-o Mon Aug 26 00:49:49 UTC 2019 (1): Starting
Sep 18 11:27:40 opnsense01 ntpd[68300]: Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
Sep 18 11:27:41 opnsense01 ntpd[74428]: proto: precision = 0.114 usec (-23)
Sep 18 11:27:41 opnsense01 ntpd[74428]: basedate set to 2019-08-14
Sep 18 11:27:41 opnsense01 ntpd[74428]: gps base set to 2019-08-18 (week 2067)
Sep 18 11:27:41 opnsense01 ntpd[74428]: restrict: 'monitor' cannot be disabled while 'limited' is enabled
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen and drop on 0 v6wildcard [::]:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 2 ixl0 [fe80::7ed3:aff:fed8:34a0%1]:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 3 ixl0 10.11.10.11:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 4 ixl3 [fe80::7ed3:aff:fed8:34a3%4]:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 5 ixl3 10.50.20.11:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 6 lo0 [::1]:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 7 lo0 [fe80::1%5]:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 8 lo0 127.0.0.1:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 9 lagg0 [fe80::7ed3:aff:fed8:34a1%10]:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 10 ovpns1 [fe80::7ed3:aff:fed8:34a0%20]:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 11 ovpns1 10.20.36.1:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 12 ipsec1000 [fe80::7ed3:aff:fed8:34a0%21]:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 13 ipsec1000 10.10.0.1:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 14 lagg0_vlan30 [fe80::7ed3:aff:fed8:34a1%11]:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 15 lagg0_vlan30 10.20.30.11:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 16 lagg0_vlan30 10.20.30.1:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 17 lagg0_vlan3 [fe80::7ed3:aff:fed8:34a1%12]:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 18 lagg0_vlan3 <Removed>
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 19 lagg0_vlan3 <Removed>
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 20 lagg0_vlan3 <Removed>
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 21 lagg0_vlan3 <Removed>
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 22 lagg0_vlan3 <Removed>
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 23 lagg0_vlan2027 [fe80::7ed3:aff:fed8:34a1%13]:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 24 lagg0_vlan2027 10.20.27.11:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 25 lagg0_vlan2027 10.20.27.1:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 26 lagg0_vlan2020 [fe80::7ed3:aff:fed8:34a1%14]:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 27 lagg0_vlan2020 192.168.0.11:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 28 lagg0_vlan2020 192.168.1.1:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 29 lagg0_vlan2029 [fe80::7ed3:aff:fed8:34a1%15]:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 30 lagg0_vlan2026 [fe80::7ed3:aff:fed8:34a1%16]:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 31 lagg0_vlan2026 10.20.26.11:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 32 lagg0_vlan2026 10.20.26.1:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 33 lagg0_vlan2040 [fe80::7ed3:aff:fed8:34a1%17]:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 34 lagg0_vlan2040 10.20.40.11:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 35 lagg0_vlan2040 10.20.40.1:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 36 lagg0_vlan2028 [fe80::7ed3:aff:fed8:34a1%18]:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 37 lagg0_vlan2028 10.20.28.11:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 38 lagg0_vlan2028 10.20.28.1:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 39 lagg0_vlan2038 [fe80::7ed3:aff:fed8:34a1%19]:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 40 lagg0_vlan2038 10.20.38.41:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listen normally on 41 lagg0_vlan2038 10.20.38.1:123
Sep 18 11:27:41 opnsense01 ntpd[74428]: Listening on routing socket on fd #62 for interface updates
Sep 18 11:27:41 opnsense01 ntpd[74428]: mlockall(): Cannot allocate memory
Sep 18 11:27:41 opnsense01 ntpd[74428]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Sep 18 11:27:41 opnsense01 ntpd[74428]: 0.0.0.0 c01d 0d kern kernel time sync enabled
Sep 18 11:27:41 opnsense01 ntpd[74428]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Sep 18 11:27:41 opnsense01 ntpd[74428]: 0.0.0.0 c012 02 freq_set kernel 44.683 PPM
Sep 18 11:27:41 opnsense01 ntpd[74428]: 0.0.0.0 c016 06 restart
Sep 18 11:27:41 opnsense01 ntpd[74428]: DNS 0.opnsense.pool.ntp.org -> 82.64.45.50
Sep 18 11:27:41 opnsense01 ntpd[74428]: DNS 1.opnsense.pool.ntp.org -> 78.46.90.21
Sep 18 11:27:41 opnsense01 ntpd[74428]: DNS 2.opnsense.pool.ntp.org -> 185.244.195.159
Sep 18 11:27:41 opnsense01 ntpd[74428]: DNS 3.opnsense.pool.ntp.org -> 131.130.251.107
Sep 18 11:27:41 opnsense01 ntpd[74428]: DNS ptbtime1.ptb.de -> 192.53.103.108
Sep 18 11:27:41 opnsense01 ntpd[74428]: DNS ptbtime2.ptb.de -> 192.53.103.104
Sep 18 11:27:41 opnsense01 ntpd[74428]: DNS ptbtime3.ptb.de -> 192.53.103.103
Sep 18 11:27:51 opnsense01 ntpd[74428]: 0.0.0.0 c61c 0c clock_step +3.794831 s
Sep 18 11:27:51 opnsense01 ntpd[74428]: 0.0.0.0 c615 05 clock_sync
Sep 18 11:27:51 opnsense01 ntpd[74428]: 0.0.0.0 c618 08 no_sys_peer
Sep 18 11:27:57 opnsense01 ntpd[74428]: 0.0.0.0 c613 03 spike_detect +0.661556 s
Sep 18 11:29:37 opnsense01 ntpd[74428]: 0.0.0.0 c618 08 no_sys_peer
Gibt es da schon eine Lösung?
-
> Gibt es da schon eine Lösung?
Für welches Problem? Dein Log zeigt erstmal keines, außer dass der NTP neu gestartet ist und normalerweise eine Weile braucht, bis er die Zeit angeglichen hat. Und das "gleiche" Problem ist schwer zu behaupten, wenn man nicht weiß, was das Problem von der_dom genau ist. Nach dem "ich setz das in ner VM nochmal auf" kam ja leider nichts mehr.
-
Hi,
ja, das Problem war, das es extrem lange gedauert hat, bis sich der NTP service auf der OPNsense auf einem bare metal server angeglichen hat. In der Zeit haben so ziemlich alle Clients sich nicht mehr an Netzlaufwerke verbinden können und andere Authentifizierungsfehler sind passiert. Habe dann einen Failover auf den zweiten Knoten gemacht und einen Tag gewartet und dann wieder zurückgeschwenkt.
Vielleicht bin ich auch einfach von chrony auf Linux verwöhnt - da geht das Angleichen schneller vonstatten.