OPNsense Forum
International Forums => German - Deutsch => Topic started by: t0mc@ on August 18, 2016, 10:48:06 pm
-
Hallo zusammen,
habe folgendes Problem:
Ein Ubuntu Client in einem lokalen Netz (192.168.112.0/24) soll per ntpdate (und später per ntpd) die Zeit aktuell halten.
Eine OPNsense dient dabei als Gateway (192.168.112.1) und hat auf der WAN Schnittstelle auch direkte Internetverbindung. Es sind keine besonderen Firewall Regeln definiert.
Wenn ich auf dem Linux Client nun per
# ntpdate de.pool.ntp.org
versuche, die Zeit zu aktualisieren, schlägt das damit fehl:
18 Aug 22:41:56 ntpdate[20261]: no server suitable for synchronization found
Wenn ich ntpdate per -u dazu bringe, unpreviligierte Ports zu benutzen, funktionierts:
# ntpdate -u de.pool.ntp.org
18 Aug 22:42:05 ntpdate[20282]: adjust time server 62.75.236.38 offset 0.007126 sec
Probehalber habe ich auf der OPNsense mal den NTP Server aktiviert. Das Ergebnis ist identisch:
# ntpdate 192.168.112.1
18 Aug 22:43:38 ntpdate[20340]: no server suitable for synchronization found
# ntpdate -u 192.168.112.1
18 Aug 22:43:49 ntpdate[20341]: adjust time server 192.168.112.1 offset 0.008085 sec
Was mache ich hier noch falsch?
Vielen Dank schon mal!
T0mc@
-
Hey t0mc@,
vielleicht hilft dir das hier: http://superuser.com/questions/141772/what-are-the-iptables-rules-to-permit-ntp
Ansonsten vielleicht einmal probieren auf der LAN Seite ausgehenden Traffic auf UDP port 123 (NTP) zu erlauben.
Auf der Seite, die ich hier angehangen habe steht, dass bei nicht veränderter iptables Config auf der Client Seite her aus es zu keinerlei Probleme kommen sollte.
Von daher vielleicht mal schauen, ob irgendwas bei iptables stört, ansonsten wie gesagt vielleicht mal die LAN Rule ausprobieren. Vielleicht klappt es. :)
Grüße
-
Vielen Dank erst mal für die Antwort.
Leider hilft rein gar nichts, egal, was ich wie auf der FW frei schalte.
Mit nmap konnte ich herausfinden, dass die Verbindung zu Port 123, UDP bei 0.de.pool.ntp.org schon mal funktioniert.
Ich habe danach mit tcpdump die Pakete mitgeschnitten und in Wireshark angesehen. Wird ntpdate ohne -u aufgerufen, so sind - wie zu erwarten - Quell und Zielport von ntpdate 123. In diesem Fall scheinen aber keine Antworten vom NTP Server anzukommen.
Ein Mitschnitt per tcpdump von ntpdate -u zeigte, dass der Quellport von ntpdate diesmal bei 57760 war. Auf diesen sind dann Antworten angekommen, so dass ntpdate keine Probleme hatte.
Ich habe danach in der OPNSense ein UDP Port Forwarding von Port 123 auf den betreffenden Client gemacht, auch das hat nicht geholfen.
Anscheinend blockiert OPNsense konsequent alle Zugriffe von UDP auf Port 123. Ich konnte nur noch nicht herausfinden, warum und wo ich das abstelle....
Noch irgendeinen Tip, wo ich nachsehen könnte?
-
Ich nutze
OPNsense 16.7.2-i386
FreeBSD 10.3-RELEASE-p7
OpenSSL 1.0.2h 3 May 2016
mit allen Updates unter Proxmox als KVM - VM zum Testen. Bei mir macht der Befehl keine Probleme. Ich habe lediglich vor dem Test den NTP - Dienst deaktivieren müssen.
Ich habe keine Änderungen an den Firewalleinstellungen gemacht.
root@OPNsense:~ # ntpdate de.pool.ntp.org
25 Aug 19:41:40 ntpdate[89886]: adjust time server 37.120.191.49 offset -0.000112 sec
Rosi
-
Hey hey,
ich nochmal. :)
Was mich persönlich mal interessieren würde is, ob du mit ner Windows VM
(Netzwerkeinstellung bei Virtual Box "NAT")
oder mit nem komplett anderen Rechner (anderes OS) mehr erfolg hast.
Schwieriges Thema. Viel mehr fällt mir auch nicht mehr ein. :-/
Da du den NTP Server ja von der LAN Seite aus her erreichst,
kann es ja eigentlich schon gar kein Problem mehr mit den Rules geben.
Die Session kann von OPNsense ja anscheinend aufgebaut werden.
Der Quellport ändert sich ja bei jeder erneuten Anfrage jedes mal soweit ich weiß.
Vielleicht trotzdem mal zu Testzwecken die Floating Rules überprüfen und bei der LAN Seite einmal ALLES erlauben. Wenn es dann immer noch nicht klappt liegt es zu mindestens schon mal nicht an den Rules. :-/
Vielleicht hat noch wer anders eine Idee. :-)
EDIT:
Mir ist gestern noch was eingefallen, woran es auch noch liegen könnte.
OPNsense erstellt die NAT Einträge ja by default automatisch für einen.
Falls du vielleicht manuelle Einträge eingestellt hast, kann es sein,
dass du dir dadurch das NAT zerschossen hast.
Was man machen könnte, wäre einmal die Config xml zu sichern. OPNsense neu aufzusetzen.
Dann zu schauen ob es frisch installiert vielleicht plötzlich funktioniert und dann die Config zurückzusetzen und die Unterschiede zu vergleichen. (Insbesondere bei den NAT Einträgen.)