NTP, leap 11 (Leap not in sync)

jason00

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-p6

When 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.org

Going 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?....

johnpoz

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?

jason00

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

johnpoz

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..