NTP not working
-
@johnpoz said in NTP not working:
NTP doesn't normally use a source port of 123 anyway..
According to the docs:
...note that NTP requires port 123 for both source and destination ports
Not all NTP server software behaves this way, of course.
Normally, traffic originating from pfSense itself will not be subject to NAT. So if NTP requiring a source port of 123 is a problem for a given network then a NAT rule like the ones above should randomize the source port. That is apparently why some people need these NAT rules to use NTP.
-
@jrey i have windows server in my local network and it is configured as ntp server, if i want to use it as ntp
server for pfsense should i select it as a peer of server? -
@dochy if your going to run a ntp server on your network and you want pfsense to sync time to this - then it would be a server.
Peers are ntp servers that work together to sync their time.. asking each other, they would really need to be the same stratum level, etc. You would normally set in pfsense to point to your local ntp server as a server.
But that is not what you have - pfsense is pointing to ntp pool, and your having a hard time from what you posted talking to them.. Not that you can't talk to them at all - but seems to be sporadic. If you have a local ntp, then sure use that.. I point my pfsense to my local pi running ntp with a gps had, and pps signal, etc.
I just rebooted my pfsense couple days ago to apply all the patches released.. So takes a few days to really get nice tight..
-
@johnpoz Unfortunately it didn't work. Here is my conf and NTP log file. I have tested 10.123.12.8 server with ntpcheck utility in my pc which is in
the same network with pfsense
Mar 23 08:50:24 ntpd 65460 ntpd exiting on signal 15 (Terminated) Mar 23 08:50:24 ntpd 65460 10.123.12.8 9012 82 demobilize assoc 34521 Mar 23 08:50:24 ntpd 65460 10.123.12.8 local addr 10.123.12.1 -> <null> Mar 23 08:50:24 ntpd 65460 0.0.0.0 001d 0d kern kernel time sync disabled Mar 23 08:50:24 ntpd 85891 ntpd 4.2.8p15@1.3728-o Wed Jan 12 15:39:52 UTC 2022 (1): Starting Mar 23 08:50:24 ntpd 85891 Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid Mar 23 08:50:24 ntpd 85891 ---------------------------------------------------- Mar 23 08:50:24 ntpd 85891 ntp-4 is maintained by Network Time Foundation, Mar 23 08:50:24 ntpd 85891 Inc. (NTF), a non-profit 501(c)(3) public-benefit Mar 23 08:50:24 ntpd 85891 corporation. Support and training for ntp-4 are Mar 23 08:50:24 ntpd 85891 available at https://www.nwtime.org/support Mar 23 08:50:24 ntpd 85891 ---------------------------------------------------- Mar 23 08:50:36 ntpd 86042 proto: precision = 1000000.000 usec (0) Mar 23 08:50:36 ntpd 86042 proto: fuzz beneath 0.771 usec Mar 23 08:50:36 ntpd 86042 basedate set to 2021-12-31 Mar 23 08:50:36 ntpd 86042 gps base set to 2022-01-02 (week 2191) Mar 23 08:50:36 ntpd 86042 Listen and drop on 0 v6wildcard [::]:123 Mar 23 08:50:36 ntpd 86042 Listen and drop on 1 v4wildcard 0.0.0.0:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 2 em0 [fe80::20c:29ff:fe71:6839%1]:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 3 em0 213.230.64.30:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 4 em1 [fe80::20c:29ff:fe71:6843%2]:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 5 em1 10.123.12.1:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 6 em2 [fe80::20c:29ff:fe71:684d%3]:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 7 em2 217.30.161.101:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 8 lo0 [::1]:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 9 lo0 [fe80::1%5]:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 10 lo0 127.0.0.1:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 11 em1.1300 [fe80::20c:29ff:fe71:6843%8]:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 12 em1.1300 10.123.20.1:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 13 em1.1350 [fe80::20c:29ff:fe71:6843%9]:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 14 em1.1350 10.123.24.1:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 15 em1.1500 [fe80::20c:29ff:fe71:6843%10]:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 16 em1.1500 10.123.40.1:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 17 em1.1600 [fe80::20c:29ff:fe71:6843%11]:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 18 em1.1600 10.123.48.1:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 19 em1.1700 [fe80::20c:29ff:fe71:6843%12]:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 20 em1.1700 10.123.56.1:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 21 em1.1750 [fe80::20c:29ff:fe71:6843%13]:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 22 em1.1750 10.123.64.1:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 23 em1.1340 [fe80::20c:29ff:fe71:6843%14]:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 24 em1.1340 10.123.22.1:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 25 em1.1100 [fe80::20c:29ff:fe71:6843%15]:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 26 em1.1100 10.123.15.1:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 27 em1.1200 [fe80::20c:29ff:fe71:6843%16]:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 28 em1.1200 10.123.16.1:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 29 em1.1360 [fe80::20c:29ff:fe71:6843%17]:123 Mar 23 08:50:36 ntpd 86042 Listen normally on 30 em1.1360 10.123.32.1:123 Mar 23 08:50:36 ntpd 86042 Listening on routing socket on fd #51 for interface updates Mar 23 08:50:36 ntpd 86042 10.123.12.8 8011 81 mobilize assoc 2451 Mar 23 08:50:36 ntpd 86042 kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized Mar 23 08:50:36 ntpd 86042 0.0.0.0 c01d 0d kern kernel time sync enabled Mar 23 08:50:36 ntpd 86042 kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized Mar 23 08:50:36 ntpd 86042 0.0.0.0 c012 02 freq_set kernel 9.180 PPM Mar 23 08:50:36 ntpd 86042 0.0.0.0 c016 06 restart Mar 23 08:50:36 ntpd 86042 10.123.12.8 8014 84 reachable -
@dochy said in NTP not working:
My pfsense is in vmware server
Has anyone considered the warning/note shown at top of the NTP config page ?
/Bingo
-
@bingo600 In my case Vmware is not responsible for clock
-
@dochy how long are you waiting, what is your reach doing.. does it change.. It should move up from 0 to 377... Your is showing 77, so either its been running a long time and you are not getting all the responses or you just started it..
-
@johnpoz i have been waiting about 2 hours, yeah now status is 377 but still unreach/pending
-
@dochy if your reach is 377 and staying there - then you have too much of an offset possible, ntp will normally not sync if the offset is too much.. Do a manual sync of time so your closer - you can see in your test there with that gallon tool doesn't seem like any of your clients actually have very accurate time..
If I run that tool from my windows machine to my ntp server - my clock offset is 1ms or 0 or 2 etc..
Curious why your pointing at 10.123.12.8 when its reference is 10.122.12.4 - why would you not just point to this 12.4 address? Also why is it saying where you pointing is a stratum 6? Your root delay and dispersion is crazy high as well..
-
@dochy
Have you looked at : these two
https://communities.vmware.com/t5/ESXi-Discussions/NTP-Why-will-my-host-NOT-sync-time-to-the-NTP-source/td-p/2826675https://kb.vmware.com/s/article/1005092
And this:
Please note that āAn ESXi/ESX host, by default, does not accept any NTP reply with a root dispersion greater than 1.5 seconds (1500 ms).ā (https://kb.vmware.com/s/article/1035833). Hence, the customer would have to add the ātos maxdistā configuration as a workaround if they want to continue using the same configured NTP servers. A flash valye of 400 can also indicate that the maximum distance threshold has been exceeded and that the tos maxdist configuration needs to be applied.
