NTP, leap 11 (Leap not in sync)
-
I am having trouble getting ntp clients to sync to the time provided by pfSense.
My pfSense version:
2.4.2-RELEASE-p1 (amd64)
built on Tue Dec 12 13:45:26 CST 2017
FreeBSD 11.1-RELEASE-p6When another client executes:
ntpdate -d 192.168.1.1
I get the response:
1 Mar 20:26:22 ntpdate[12568]: ntpdate 4.2.8p10@1.3728-o Sat Sep 23 19:02:40 UTC 2017 (1) transmit(192.168.1.1) receive(192.168.1.1) transmit(192.168.1.1) receive(192.168.1.1) transmit(192.168.1.1) receive(192.168.1.1) transmit(192.168.1.1) receive(192.168.1.1) 192.168.1.1: Server dropped: Leap not in sync server 192.168.1.1, port 123 stratum 2, precision -18, leap 11, trust 000 refid [192.168.1.1], delay 0.02580, dispersion 0.00005 transmitted 4, in filter 4 reference time: de4334bb.d0191bc6 Thu, Mar 1 2018 20:26:03.812 originate timestamp: de4334d3.29bef709 Thu, Mar 1 2018 20:26:27.163 transmit timestamp: de4334d4.277ce4ed Thu, Mar 1 2018 20:26:28.154 filter delay: 0.02586 0.02585 0.02580 0.02592 0.00000 0.00000 0.00000 0.00000 filter offset: -0.99131 -0.99141 -0.99145 -0.99145 0.000000 0.000000 0.000000 0.000000 delay 0.02580, dispersion 0.00005 offset -0.991454 1 Mar 20:26:28 ntpdate[12568]: no server suitable for synchronization found
If I go to pfSense dashboard > services > ntp > and just press 'save'… the client will successfully sync to the timeserver, but if I try again in a few minutes I will get the same error message.
I have 4 time services configured in pfSense:
0.us.pool.ntp.org
1.us.pool.ntp.org
2.us.pool.ntp.org
3.us.pool.ntp.orgGoing to Status > NTP
I sometimes get good results, and sometimes bad...
This...
Pool Placeholder 0.us.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.004 Pool Placeholder 1.us.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.004 Pool Placeholder 2.us.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.004 Pool Placeholder 3.us.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.004 Active Peer 204.9.54.119 .CDMA. 1 u 34 64 1 36.595 -162.21 60.446 Candidate 96.244.96.19 192.168.10.254 2 u 32 64 1 59.501 -190.55 80.729 Candidate 74.82.59.149 64.6.144.6 3 u 34 64 1 63.739 -149.25 49.326 Selected 192.92.6.30 .PPS. 1 u 33 64 1 121.787 -218.72 66.634 Selected 129.6.15.29 .NIST. 1 u 31 64 1 63.248 -189.67 77.537 Selected 45.127.112.2 18.26.4.105 2 u 31 64 1 34.611 -184.91 77.094 Outlier 45.56.118.161 152.2.133.53 2 u 28 64 1 45.636 -115.41 49.026 Selected 45.76.244.202 64.250.105.228 2 u 32 64 1 61.349 -118.53 50.625 Selected 128.138.141.172 .NIST. 1 u 30 64 1 51.397 -149.43 47.355 Selected 12.167.151.1 129.6.15.29 2 u 31 64 1 58.865 -71.613 77.698 Selected 104.131.53.252 18.26.4.105 2 u 28 64 1 51.769 -70.326 80.624 Outlier 129.6.15.30 .NIST. 1 u 28 64 1 61.494 -191.75 82.000 Candidate 171.66.97.126 .GPSs. 1 u 29 64 1 66.428 -150.35 52.220 Candidate 72.29.161.5 .GPS. 1 u 24 64 1 66.810 -153.49 50.186 Candidate 198.137.202.56 66.220.9.122 2 u 29 64 1 62.499 -171.84 65.983 Outlier 198.60.22.240 150.143.81.69 2 u 27 64 1 65.793 -103.08 63.338 Outlier 52.6.160.3 130.207.244.240 2 u 33 64 1 46.387 -70.316 82.424
And then sometimes it looks like this….
Pool Placeholder 0.us.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.004 Pool Placeholder 1.us.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.004 Pool Placeholder 2.us.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.004 Pool Placeholder 3.us.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.004 Unreach/Pending 204.9.54.119 .CDMA. 1 u 74 64 1 46.983 -106.63 0.004 Unreach/Pending 96.244.96.19 192.168.10.254 2 u 78 64 1 85.603 -115.70 0.004 Unreach/Pending 74.82.59.149 64.6.144.6 3 u 75 64 1 74.621 -115.02 0.004 Unreach/Pending 192.92.6.30 .PPS. 1 u 74 64 1 87.845 -124.99 0.004 Unreach/Pending 129.6.15.29 .NIST. 1 u 78 64 1 75.204 -108.38 0.004 Unreach/Pending 45.127.112.2 35.73.197.144 2 u 74 64 1 37.517 -108.14 0.004 Unreach/Pending 45.56.118.161 128.227.205.3 2 u 41 64 1 46.148 -111.77 13.790 Unreach/Pending 45.76.244.202 128.138.141.172 2 u 76 64 1 71.580 -112.84 0.004 Unreach/Pending 128.138.141.172 .NIST. 1 u 77 64 1 49.563 -116.63 0.004 Unreach/Pending 12.167.151.1 129.6.15.29 2 u 75 64 1 72.482 -109.31 0.004 Unreach/Pending 104.131.53.252 173.162.192.156 2 u 41 64 1 54.919 -131.42 16.409 Unreach/Pending 129.6.15.30 .NIST. 1 u 78 64 1 74.280 -108.21 0.004 Unreach/Pending 171.66.97.126 .GPSs. 1 u 74 64 1 65.748 -121.27 0.004 Unreach/Pending 72.29.161.5 .GPS. 1 u 37 64 1 66.148 -138.20 22.031 Unreach/Pending 198.137.202.56 66.220.9.122 2 u 76 64 1 65.255 -116.92 0.004 Unreach/Pending 198.60.22.240 150.143.81.69 2 u 40 64 1 68.234 -140.74 20.050 Unreach/Pending 52.6.160.3 130.207.244.240 2 u 75 64 1 57.044 -113.48 0.004
The NTP system log doesn't seem to show anything interesting:
Mar 1 19:38:43 ntpd 30258 ntpd 4.2.8p10@1.3728-o Sun Oct 8 22:12:06 UTC 2017 (1): Starting Mar 1 19:38:43 ntpd 30258 Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid Mar 1 19:38:43 ntpd 30399 proto: precision = 4.000 usec (-18) Mar 1 19:38:43 ntpd 30399 leapsecond file ('/var/db/leap-seconds'): good hash signature Mar 1 19:38:43 ntpd 30399 leapsecond file ('/var/db/leap-seconds'): loaded, expire=2018-12-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37 Mar 1 19:38:43 ntpd 30399 Listen normally on 1 vtnet0 192.168.1.1:123 Mar 1 19:38:43 ntpd 30399 Listen normally on 2 lo0 [::1]:123 Mar 1 19:38:43 ntpd 30399 Listen normally on 3 lo0 127.0.0.1:123 Mar 1 19:38:43 ntpd 30399 Listening on routing socket on fd #24 for interface updates Mar 1 19:38:45 ntpd 30399 Soliciting pool server 204.9.54.119 Mar 1 19:38:45 ntpd 30399 Soliciting pool server 96.244.96.19 Mar 1 19:38:46 ntpd 30399 Soliciting pool server 74.82.59.149 Mar 1 19:38:46 ntpd 30399 Soliciting pool server 45.79.111.114 Mar 1 19:38:46 ntpd 30399 Soliciting pool server 192.92.6.30 Mar 1 19:38:47 ntpd 30399 Soliciting pool server 129.6.15.29 Mar 1 19:38:47 ntpd 30399 Soliciting pool server 45.127.112.2 Mar 1 19:38:47 ntpd 30399 Soliciting pool server 45.56.118.161 Mar 1 19:38:47 ntpd 30399 Soliciting pool server 45.76.244.202 Mar 1 19:38:48 ntpd 30399 Soliciting pool server 12.167.151.1 Mar 1 19:38:48 ntpd 30399 Soliciting pool server 128.138.141.172 Mar 1 19:38:48 ntpd 30399 Soliciting pool server 104.131.53.252 Mar 1 19:38:49 ntpd 30399 Soliciting pool server 72.29.161.5 Mar 1 19:38:49 ntpd 30399 Soliciting pool server 171.66.97.126 Mar 1 19:38:49 ntpd 30399 Soliciting pool server 129.6.15.30 Mar 1 19:38:50 ntpd 30399 Soliciting pool server 198.137.202.56 Mar 1 19:38:50 ntpd 30399 Soliciting pool server 2604:880:50:6f::ffff:53 Mar 1 19:38:50 ntpd 30399 Soliciting pool server 198.60.22.240 Mar 1 19:56:19 ntpd 30399 Soliciting pool server 52.6.160.3
Anyone have any ideas?
Edit:
I should mention, pfSense is running in a VM under proxmox. I think this NTP problem started when I upgraded to pfSense 2.4.2… I think I may have had 2.3.X prior?.... -
Well ntp is clearly not talking to pool servers.. None of your status is good. From that you have never talked to any ntp server you have setup… NTP server will show reach of 377 when you can talk to them without issue and they have gotten multiple updates from them, etc.. Looks like the highest reach you have ever gotten is 1..
You need to figure out why pfsense is not talking to the pool servers.
Do you have something upstream of pfsense blocking ntp?
-
Thanks for the hint…
I ran "ntpdate -d 0.us.pool.ntp.org" from the pfSense shell, and it appears to execute succesfully.
I am unable to copy/paste the output but it receives the time with .8 sec offset, stratum 1 server, precision -18, leap 00, trust 000 -
Well clearly from your output pfsense ntpd which is not ntpdate is not able to talk outbound.. Did you mess with outbound nat? Do you have any floating rules..