<![CDATA[pfSense NTP server is very unstable.]]>pfSense NTP server only works fine for the first a few hours after every restarting NTP service or updating NTP settings.

For the last month, I have tried/tested various time servers in the pfSense settings:

pool.ntp.org
0.pool.ntp.org
1.pool.ntp.org
2.pool.ntp.org
cn.pool.ntp.org
ntp.aliyun.com
time.windows.com
time.apple.com
ntp.ubuntu.com

No matter which one or serveral of the above NTP servers/pools I set in Services -> NTP -> Time Servers, the pfSense NTP server only works for the first few hours to a half day, then no longer working.

I run a simple Linux shell script in a LAN PC, to check both the external NTP server (configured in pfSense) and the NTP server of pfsense itself, periodically:

while true; do
	echo ======
	date
	ntpdate -q ntp.aliyun.com # assuming the external NTP server configured in pfSense is: ntp.aliyun.com
	echo
	ntpdate -q 192.168.1.1 # assuming the IP of pfSense is: 192.168.1.1
	sleep 300
done

After every updating of the NTP settings or every restarting of the NTP service in pfSense, I run the obove script for a few hours to one day.

It turns out that the external NTP server is very stable, the result of every check reads something like:

server 203.107.6.88, stratum 2, offset 0.727373, delay 0.04918
23 Jan 04:59:13 ntpdate[102300]: step time server 203.107.6.88 offset 0.727373 sec

But the pfSense NTP server only works fine for the first few hours, then no longer working:

server 192.168.1.1, stratum 2, offset 1.739098, delay 0.02609
22 Jan 19:58:25 ntpdate[80598]: no server suitable for synchronization found

Moreover, I also tried setting Orphan Mode in the NTP settings. As its description implied, this setting is useful when external NTP server is unreachable. If my understanding is correct, when pfSense can not reach external NTP server, the clock of the device of pfSense itself will be used to answer NTP requests.

But in my test, I first set the NTP server to an arbitrary fake one, then no matther what value I set for Orphan Mode, the NTP requests from LAN to pfSense will fail.

]]>https://forum.netgate.com/topic/169301/pfsense-ntp-server-is-very-unstableRSS for NodeSun, 19 Apr 2026 03:06:30 GMTSat, 22 Jan 2022 21:34:28 GMT60<![CDATA[Reply to pfSense NTP server is very unstable. on Sun, 06 Feb 2022 13:37:07 GMT]]>https://www.ntp.org/ntpfaq/NTP-s-trbl-general.htm#AEN5162
NTP will reject a peer that is #roughtly 20 or more minutes off.

http://www.ntp.org/ntpfaq/NTP-s-algo.htm
And it will consider a 128ms diff enough to be "unsync'ed"

@einsdisp said in pfSense NTP server is very unstable.:

How to force pfSense to believe remote time of a single server, in case the offset is very large?

ntpdate will "step the time" ,but requires the ntp daemon to have released it's binding to the UDP 123 port ... AKA "usually" not running.

/Bingo

]]>https://forum.netgate.com/post/1023814https://forum.netgate.com/post/1023814Sun, 06 Feb 2022 13:37:07 GMT<![CDATA[Reply to pfSense NTP server is very unstable. on Sun, 06 Feb 2022 10:56:45 GMT]]>@stephenw10

My final question regarding pfSense itself:

it's unlikely to sync to a single server that is showing a 46s offset.

In my test, if pfSense VM RTC clock differs from remote NTP server by a large amount, pfSense refuses to sync time.

How to force pfSense to believe remote time of a single server, in case the offset is very large? I already checked "prefer" checkbox in the NTP server settings, but it is no use.

If there is no way for a single remote server, then how many servers is needed at least?

]]>https://forum.netgate.com/post/1023812https://forum.netgate.com/post/1023812Sun, 06 Feb 2022 10:56:45 GMT<![CDATA[Reply to pfSense NTP server is very unstable. on Sun, 06 Feb 2022 10:47:55 GMT]]>@stephenw10 @johnpoz

As I tested more these days, I finally figured out the cause of this issue: The host OS should not be set to sync time with pfSense VM. As my test, if I stopped the NTP of host OS, all runs fine. If I enabled host OS NTP, the host RTC will advance 3 more seconds compare to the real world clock, in every 5 minutes. The accumulative error is about 10 minutes per day.

I am not a KVM expert, but I guess it is due to that, by default, (or in my VM config), KVM may adjust VM RTC clock ticking rate, when host time is changed. So if host OS NTP sever is set to pfSense VM, it may ended up in a "dead loop".

My original VM config related to clocking:

<clock offset="utc">
  <timer name="rtc" tickpolicy="catchup"/>
  <timer name="pit" tickpolicy="delay"/>
  <timer name="hpet" present="yes"/>
</clock>

I guess (but haven't tested), changing <timer name="rtc" tickpolicy="catchup"/> to <timer name="rtc" tickpolicy="delay" track="guest"/> may direct KVM to handle VM RTC clock as normal, when host time changes, as if host time is not changed, thus resolving the "dead loop".

But a more simple solution is disabling host OS NTP or set host OS NTP server to an external one, rather than pfSense VM.

]]>https://forum.netgate.com/post/1023811https://forum.netgate.com/post/1023811Sun, 06 Feb 2022 10:47:55 GMT<![CDATA[Reply to pfSense NTP server is very unstable. on Tue, 25 Jan 2022 03:27:53 GMT]]>@einsdisp well if you got it turned off in the host, lets see if that has any effect on the issue you were seeing.

the openvm tools for doesnt really have a setting either that I can see in the gui, so guessing it might just disable that by default..

But from this - I take it the qemu package is available

https://forum.netgate.com/post/995504

that is if running 2.6 or 22.01 I take it.. I am looking forward to it myself for my VMs - since my nas virtual machine is qemu based.. I not sure why I had those openvm tools installed - might of been habit from when I ran esxi ;) I have now removed it. And think might update that vm to 2.6 to try out the qemu tools - now maybe my dashboard will show the IP of pfsense, and will be able to shutdown vs having to halt the system from inside the vm.

edit:
Well I updated to 2.6, and installed the package and then ran it and now I see IPs on that vm

vm.jpg

On my VM dashboard on my nas..

edit: just to update its been hours and hours now and working as it should..

ntp.jpg

status.jpg

]]>https://forum.netgate.com/post/1021591https://forum.netgate.com/post/1021591Tue, 25 Jan 2022 03:27:53 GMT<![CDATA[Reply to pfSense NTP server is very unstable. on Mon, 24 Jan 2022 18:56:42 GMT]]>@johnpoz

  1. My host OS is Linux, and it was set to sync time to pfSense VM before. As you suggested, I disabled NTP in host OS just now: sudo timedatectl set-ntp false.

  2. My virtualization software is KVM+QEMU+libvirt. "openvm-tools" is VMware staff. The KVM equivalent is qemu-guest-agent, which does the host-VM time sync job. But pfSense VM does not have such staff apparently. There is no such "tools" running in pfSense VM which syncs VM time to host.

  3. My current NTP graph:

ad8ed885-eef5-488e-a297-6773a5fbf8c5-image.png

]]>https://forum.netgate.com/post/1021586https://forum.netgate.com/post/1021586Mon, 24 Jan 2022 18:56:42 GMT<![CDATA[Reply to pfSense NTP server is very unstable. on Mon, 24 Jan 2022 18:36:38 GMT]]>@einsdisp said in pfSense NTP server is very unstable.:

NTP server in OpenWrt.

While that is a good test, better test would be a freebsd vm..

Have you make sure to disable ntp sync with the host on the vm? I take it your running the openvm tools package.. Been quite sometime since have used that - but more than likely you want to disable its time sync function..

I could fire up the vm I have running under my nas virtual machine stuff, but I have never left it running for any length of time, and never even installed the vm tools package.

Edit: Seems I did have the openvm package installed.. So I have turned on graphing for ntp and will let this vm run for a day or so and see what it shows.

I just booted, and here is current status
currentdetails.jpg

edit2: here is current ntp graph
ntpgraph.jpg

]]>https://forum.netgate.com/post/1021577https://forum.netgate.com/post/1021577Mon, 24 Jan 2022 18:36:38 GMT<![CDATA[Reply to pfSense NTP server is very unstable. on Mon, 24 Jan 2022 18:00:43 GMT]]>@johnpoz
@stephenw10

I already tried NTP pool (rather than a single NTP server) before. No matter what I set, pfSense NTP always works fine only for the first several hours, then no longer working.

I just adjusted the system clock of the host OS and restarted pfSense VM. This time I set the external server to ntp.aliyun.com. Everything is fine now:

5b2a9f76-161f-4cf7-b159-2f2924e2953e-image.png

be1ebb32-063d-4b37-bfbd-992aeed7b16f-image.png

Jan 25 01:52:47 	ntpd 	34952 	ntpd 4.2.8p15@1.3728-o Thu Jun 24 21:53:38 UTC 2021 (1): Starting
Jan 25 01:52:47 	ntpd 	34952 	Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
Jan 25 01:52:47 	ntpd 	34952 	----------------------------------------------------
Jan 25 01:52:47 	ntpd 	34952 	ntp-4 is maintained by Network Time Foundation,
Jan 25 01:52:47 	ntpd 	34952 	Inc. (NTF), a non-profit 501(c)(3) public-benefit
Jan 25 01:52:47 	ntpd 	34952 	corporation. Support and training for ntp-4 are
Jan 25 01:52:47 	ntpd 	34952 	available at https://www.nwtime.org/support
Jan 25 01:52:47 	ntpd 	34952 	----------------------------------------------------
Jan 25 01:52:47 	ntpd 	35232 	proto: precision = 17.470 usec (-16)
Jan 25 01:52:47 	ntpd 	35232 	basedate set to 2021-06-12
Jan 25 01:52:47 	ntpd 	35232 	gps base set to 2021-06-13 (week 2162)
Jan 25 01:52:47 	ntpd 	35232 	Listen normally on 0 lo0 [::1]:123
Jan 25 01:52:47 	ntpd 	35232 	Listen normally on 1 lo0 127.0.0.1:123
Jan 25 01:52:47 	ntpd 	35232 	Listen normally on 2 bridge0 10.1.1.2:123
Jan 25 01:52:47 	ntpd 	35232 	Listening on routing socket on fd #23 for interface updates
Jan 25 01:52:47 	ntpd 	35232 	kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Jan 25 01:52:47 	ntpd 	35232 	0.0.0.0 c01d 0d kern kernel time sync enabled
Jan 25 01:52:47 	ntpd 	35232 	kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Jan 25 01:52:47 	ntpd 	35232 	0.0.0.0 c012 02 freq_set kernel -8.436 PPM
Jan 25 01:52:47 	ntpd 	35232 	0.0.0.0 c016 06 restart
Jan 25 01:52:53 	ntpd 	35232 	DNS ntp.aliyun.com -> 203.107.6.88
Jan 25 01:52:53 	ntpd 	35232 	203.107.6.88 8011 81 mobilize assoc 57546
Jan 25 01:52:54 	ntpd 	35232 	203.107.6.88 8014 84 reachable
Jan 25 01:53:00 	ntpd 	35232 	203.107.6.88 901a 8a sys_peer
Jan 25 01:53:00 	ntpd 	35232 	0.0.0.0 c61c 0c clock_step +0.236668 s
Jan 25 01:53:00 	ntpd 	35232 	0.0.0.0 c615 05 clock_sync
Jan 25 01:54:08 	ntpd 	35232 	0.0.0.0 c618 08 no_sys_peer
Jan 25 01:54:08 	ntpd 	35232 	203.107.6.88 8014 84 reachable
Jan 25 01:54:14 	ntpd 	35232 	203.107.6.88 901a 8a sys_peer

But as expected, pfSense NTP will very likely to fail some hours later. I will track its status periodically.

To figure out whether it is due to VM, I run an OpenWrt instance in the same host OS, using the same KVM/libvirt config, and enable NTP server in OpenWrt. It turns out OpenWrt NTP works fine currently. I will check its status as well.

]]>https://forum.netgate.com/post/1021574https://forum.netgate.com/post/1021574Mon, 24 Jan 2022 18:00:43 GMT<![CDATA[Reply to pfSense NTP server is very unstable. on Mon, 24 Jan 2022 17:10:41 GMT]]>Mmm, it's unlikely to sync to a single server that is showing a 46s offset.

If you add a pool there so it can see multiple servers and they are all showing close to the same offset I would expect it to sync.

Why is the offset so large initially anyway?

Steve

]]>https://forum.netgate.com/post/1021562https://forum.netgate.com/post/1021562Mon, 24 Jan 2022 17:10:41 GMT<![CDATA[Reply to pfSense NTP server is very unstable. on Mon, 24 Jan 2022 16:43:10 GMT]]>@einsdisp said in pfSense NTP server is very unstable.:

0.0.0.0 061d 0d kern kernel time sync disabled

well that not good.. Huge time difference could be the cause of that.

If this is a vm, you prob want to make sure the VM isn't doing sync with the host, etc if you want it to sync time with ntp.

]]>https://forum.netgate.com/post/1021558https://forum.netgate.com/post/1021558Mon, 24 Jan 2022 16:43:10 GMT<![CDATA[Reply to pfSense NTP server is very unstable. on Mon, 24 Jan 2022 16:39:37 GMT]]>@stephenw10

As per Diagnostics -> Backup & Restore -> Config History, the last time I updated the NTP settings was 1/23/22 05:51:12 (my timezone is UTC+8).

The last time I updated the NTP setting, I changed the server to IP address 203.107.6.88 (IP of ntp.aliyun.com), because some Google results indicate that using IP address than domain name may be more stable for pfSense):

5de2ffa5-339f-4809-844e-8f45f55f0278-image.png

Current NTP status:

4809dd6e-8e54-47d0-8253-14c8ce3e4b7d-image.png

d5470d24-278d-49aa-a5e0-f9696c301012-image.png

It means pfSense can't get time from the external server, but as my test in a PC, this external server just works fine. And as I remembered, I checked the pfSense NTP status in WebUI just after updating settings last time, and it showed the status was good.

The logs from the last time I updated NTP settings (Status -> System Logs -> NTP):

Jan 23 05:51:12 	ntpd 	3974 	ntpd exiting on signal 15 (Terminated)
Jan 23 05:51:12 	ntpd 	3974 	0.0.0.0 8812 82 demobilize assoc 27640
Jan 23 05:51:12 	ntpd 	3974 	17.253.84.253 1612 82 demobilize assoc 27641
Jan 23 05:51:12 	ntpd 	3974 	17.253.84.253 local addr 60.25.138.110 -> <null>
Jan 23 05:51:12 	ntpd 	3974 	17.253.116.125 1012 82 demobilize assoc 27642
Jan 23 05:51:12 	ntpd 	3974 	17.253.116.125 local addr 60.25.138.110 -> <null>
Jan 23 05:51:12 	ntpd 	3974 	17.253.114.125 1012 82 demobilize assoc 27643
Jan 23 05:51:12 	ntpd 	3974 	17.253.114.125 local addr 60.25.138.110 -> <null>
Jan 23 05:51:12 	ntpd 	3974 	17.253.114.253 1012 82 demobilize assoc 27644
Jan 23 05:51:12 	ntpd 	3974 	17.253.114.253 local addr 60.25.138.110 -> <null>
Jan 23 05:51:12 	ntpd 	3974 	17.253.116.253 1012 82 demobilize assoc 27645
Jan 23 05:51:12 	ntpd 	3974 	17.253.116.253 local addr 60.25.138.110 -> <null>
Jan 23 05:51:12 	ntpd 	3974 	0.0.0.0 061d 0d kern kernel time sync disabled
Jan 23 05:51:12 	ntpd 	8270 	ntpd 4.2.8p15@1.3728-o Thu Jun 24 21:53:38 UTC 2021 (1): Starting
Jan 23 05:51:12 	ntpd 	8270 	Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
Jan 23 05:51:12 	ntpd 	8270 	----------------------------------------------------
Jan 23 05:51:12 	ntpd 	8270 	ntp-4 is maintained by Network Time Foundation,
Jan 23 05:51:12 	ntpd 	8270 	Inc. (NTF), a non-profit 501(c)(3) public-benefit
Jan 23 05:51:12 	ntpd 	8270 	corporation. Support and training for ntp-4 are
Jan 23 05:51:12 	ntpd 	8270 	available at https://www.nwtime.org/support
Jan 23 05:51:12 	ntpd 	8270 	----------------------------------------------------
Jan 23 05:51:12 	ntpd 	8520 	proto: precision = 7.590 usec (-17)
Jan 23 05:51:12 	ntpd 	8520 	basedate set to 2021-06-12
Jan 23 05:51:12 	ntpd 	8520 	gps base set to 2021-06-13 (week 2162)
Jan 23 05:51:12 	ntpd 	8520 	Listen and drop on 0 v6wildcard [::]:123
Jan 23 05:51:12 	ntpd 	8520 	Listen and drop on 1 v4wildcard 0.0.0.0:123
Jan 23 05:51:12 	ntpd 	8520 	Listen normally on 2 vtnet0 [fe80::5054:ff:fe00:1%1]:123
Jan 23 05:51:12 	ntpd 	8520 	Listen normally on 3 vtnet1 [fe80::5054:ff:fe00:2%2]:123
Jan 23 05:51:12 	ntpd 	8520 	Listen normally on 4 em0 [fe80::5054:ff:fe00:99%3]:123
Jan 23 05:51:12 	ntpd 	8520 	Listen normally on 5 igb0 [fe80::2e53:4aff:fe07:7ee0%4]:123
Jan 23 05:51:12 	ntpd 	8520 	Listen normally on 6 igb1 [fe80::2e53:4aff:fe07:7ee1%5]:123
Jan 23 05:51:12 	ntpd 	8520 	Listen normally on 7 igb2 [fe80::2e53:4aff:fe07:7ee2%6]:123
Jan 23 05:51:12 	ntpd 	8520 	Listen normally on 8 igb3 [fe80::2e53:4aff:fe07:7ee3%7]:123
Jan 23 05:51:12 	ntpd 	8520 	Listen normally on 9 lo0 [::1]:123
Jan 23 05:51:12 	ntpd 	8520 	Listen normally on 10 lo0 [fe80::1%9]:123
Jan 23 05:51:12 	ntpd 	8520 	Listen normally on 11 lo0 127.0.0.1:123
Jan 23 05:51:12 	ntpd 	8520 	Listen normally on 12 pppoe0 60.25.138.110:123
Jan 23 05:51:12 	ntpd 	8520 	Listen normally on 13 pppoe0 [fe80::2e53:4aff:fe07:7ee0%12]:123
Jan 23 05:51:12 	ntpd 	8520 	Listen normally on 14 bridge0 10.1.1.2:123
Jan 23 05:51:12 	ntpd 	8520 	Listen normally on 15 bridge1 10.1.2.2:123
Jan 23 05:51:12 	ntpd 	8520 	Listening on routing socket on fd #36 for interface updates
Jan 23 05:51:12 	ntpd 	8520 	203.107.6.88 8011 81 mobilize assoc 9119
Jan 23 05:51:12 	ntpd 	8520 	kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized
Jan 23 05:51:12 	ntpd 	8520 	0.0.0.0 c01d 0d kern kernel time sync enabled
Jan 23 05:51:12 	ntpd 	8520 	kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized
Jan 23 05:51:12 	ntpd 	8520 	0.0.0.0 c012 02 freq_set kernel -8.436 PPM
Jan 23 05:51:12 	ntpd 	8520 	0.0.0.0 c016 06 restart
Jan 23 05:51:13 	ntpd 	8520 	203.107.6.88 8014 84 reachable
Jan 23 05:51:19 	ntpd 	8520 	203.107.6.88 901a 8a sys_peer
Jan 23 05:51:19 	ntpd 	8520 	0.0.0.0 c615 05 clock_sync
Jan 23 05:51:23 	ntpd 	8520 	0.0.0.0 0618 08 no_sys_peer
Jan 23 14:13:33 	ntpd 	32039 	ntpd 4.2.8p15@1.3728-o Thu Jun 24 21:53:38 UTC 2021 (1): Starting
Jan 23 14:13:33 	ntpd 	32039 	Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
Jan 23 14:13:33 	ntpd 	32039 	----------------------------------------------------
Jan 23 14:13:33 	ntpd 	32039 	ntp-4 is maintained by Network Time Foundation,
Jan 23 14:13:33 	ntpd 	32039 	Inc. (NTF), a non-profit 501(c)(3) public-benefit
Jan 23 14:13:33 	ntpd 	32039 	corporation. Support and training for ntp-4 are
Jan 23 14:13:33 	ntpd 	32039 	available at https://www.nwtime.org/support
Jan 23 14:13:33 	ntpd 	32039 	----------------------------------------------------
Jan 23 14:13:33 	ntpd 	32129 	proto: precision = 17.640 usec (-16)
Jan 23 14:13:33 	ntpd 	32129 	basedate set to 2021-06-12
Jan 23 14:13:33 	ntpd 	32129 	gps base set to 2021-06-13 (week 2162)
Jan 23 14:13:33 	ntpd 	32129 	Listen and drop on 0 v6wildcard [::]:123
Jan 23 14:13:33 	ntpd 	32129 	Listen and drop on 1 v4wildcard 0.0.0.0:123
Jan 23 14:13:33 	ntpd 	32129 	Listen normally on 2 vtnet0 [fe80::5054:ff:fe00:1%1]:123
Jan 23 14:13:33 	ntpd 	32129 	Listen normally on 3 vtnet1 [fe80::5054:ff:fe00:2%2]:123
Jan 23 14:13:33 	ntpd 	32129 	Listen normally on 4 em0 [fe80::5054:ff:fe00:99%3]:123
Jan 23 14:13:33 	ntpd 	32129 	Listen normally on 5 igb0 [fe80::2e53:4aff:fe07:7ee0%4]:123
Jan 23 14:13:33 	ntpd 	32129 	Listen normally on 6 igb1 [fe80::2e53:4aff:fe07:7ee1%5]:123
Jan 23 14:13:33 	ntpd 	32129 	Listen normally on 7 igb2 [fe80::2e53:4aff:fe07:7ee2%6]:123
Jan 23 14:13:33 	ntpd 	32129 	Listen normally on 8 igb3 [fe80::2e53:4aff:fe07:7ee3%7]:123
Jan 23 14:13:33 	ntpd 	32129 	Listen normally on 9 lo0 [::1]:123
Jan 23 14:13:33 	ntpd 	32129 	Listen normally on 10 lo0 [fe80::1%9]:123
Jan 23 14:13:33 	ntpd 	32129 	Listen normally on 11 lo0 127.0.0.1:123
Jan 23 14:13:33 	ntpd 	32129 	Listen normally on 12 pppoe0 116.130.78.65:123
Jan 23 14:13:33 	ntpd 	32129 	Listen normally on 13 pppoe0 [fe80::2e53:4aff:fe07:7ee0%12]:123
Jan 23 14:13:33 	ntpd 	32129 	Listen normally on 14 bridge0 10.1.1.2:123
Jan 23 14:13:33 	ntpd 	32129 	Listen normally on 15 bridge1 10.1.2.2:123
Jan 23 14:13:33 	ntpd 	32129 	Listening on routing socket on fd #36 for interface updates
Jan 23 14:13:33 	ntpd 	32129 	203.107.6.88 8011 81 mobilize assoc 41585
Jan 23 14:13:33 	ntpd 	32129 	kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Jan 23 14:13:33 	ntpd 	32129 	0.0.0.0 c01d 0d kern kernel time sync enabled
Jan 23 14:13:33 	ntpd 	32129 	kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Jan 23 14:13:33 	ntpd 	32129 	0.0.0.0 c012 02 freq_set kernel -8.436 PPM
Jan 23 14:13:33 	ntpd 	32129 	0.0.0.0 c016 06 restart
Jan 23 14:13:35 	ntpd 	32129 	203.107.6.88 8014 84 reachable
Jan 23 14:13:41 	ntpd 	32129 	203.107.6.88 901a 8a sys_peer
Jan 23 14:13:41 	ntpd 	32129 	0.0.0.0 c61c 0c clock_step +14.575908 s
Jan 23 14:13:55 	ntpd 	32129 	0.0.0.0 c615 05 clock_sync
Jan 23 14:15:03 	ntpd 	32129 	0.0.0.0 c618 08 no_sys_peer
Jan 23 14:15:03 	ntpd 	32129 	203.107.6.88 8014 84 reachable
Jan 23 14:15:09 	ntpd 	32129 	203.107.6.88 901a 8a sys_peer
Jan 23 14:15:13 	ntpd 	32129 	0.0.0.0 0628 08 no_sys_peer
Jan 24 02:39:41 	ntpd 	33147 	ntpd 4.2.8p15@1.3728-o Thu Jun 24 21:53:38 UTC 2021 (1): Starting
Jan 24 02:39:41 	ntpd 	33147 	Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
Jan 24 02:39:41 	ntpd 	33147 	----------------------------------------------------
Jan 24 02:39:41 	ntpd 	33147 	ntp-4 is maintained by Network Time Foundation,
Jan 24 02:39:41 	ntpd 	33147 	Inc. (NTF), a non-profit 501(c)(3) public-benefit
Jan 24 02:39:41 	ntpd 	33147 	corporation. Support and training for ntp-4 are
Jan 24 02:39:41 	ntpd 	33147 	available at https://www.nwtime.org/support
Jan 24 02:39:41 	ntpd 	33147 	----------------------------------------------------
Jan 24 02:39:41 	ntpd 	33227 	proto: precision = 4.560 usec (-18)
Jan 24 02:39:41 	ntpd 	33227 	basedate set to 2021-06-12
Jan 24 02:39:41 	ntpd 	33227 	gps base set to 2021-06-13 (week 2162)
Jan 24 02:39:41 	ntpd 	33227 	Listen and drop on 0 v6wildcard [::]:123
Jan 24 02:39:41 	ntpd 	33227 	Listen and drop on 1 v4wildcard 0.0.0.0:123
Jan 24 02:39:41 	ntpd 	33227 	Listen normally on 2 vtnet0 [fe80::5054:ff:fe00:1%1]:123
Jan 24 02:39:41 	ntpd 	33227 	Listen normally on 3 vtnet1 [fe80::5054:ff:fe00:2%2]:123
Jan 24 02:39:41 	ntpd 	33227 	Listen normally on 4 em0 [fe80::5054:ff:fe00:99%3]:123
Jan 24 02:39:41 	ntpd 	33227 	Listen normally on 5 igb0 [fe80::2e53:4aff:fe07:7ee0%4]:123
Jan 24 02:39:41 	ntpd 	33227 	Listen normally on 6 igb1 [fe80::2e53:4aff:fe07:7ee1%5]:123
Jan 24 02:39:41 	ntpd 	33227 	Listen normally on 7 igb2 [fe80::2e53:4aff:fe07:7ee2%6]:123
Jan 24 02:39:41 	ntpd 	33227 	Listen normally on 8 igb3 [fe80::2e53:4aff:fe07:7ee3%7]:123
Jan 24 02:39:41 	ntpd 	33227 	Listen normally on 9 lo0 [::1]:123
Jan 24 02:39:41 	ntpd 	33227 	Listen normally on 10 lo0 [fe80::1%9]:123
Jan 24 02:39:41 	ntpd 	33227 	Listen normally on 11 lo0 127.0.0.1:123
Jan 24 02:39:41 	ntpd 	33227 	Listen normally on 12 pppoe0 117.11.135.78:123
Jan 24 02:39:41 	ntpd 	33227 	Listen normally on 13 pppoe0 [fe80::2e53:4aff:fe07:7ee0%12]:123
Jan 24 02:39:41 	ntpd 	33227 	Listen normally on 14 bridge0 10.1.1.2:123
Jan 24 02:39:41 	ntpd 	33227 	Listen normally on 15 bridge1 10.1.2.2:123
Jan 24 02:39:41 	ntpd 	33227 	Listening on routing socket on fd #36 for interface updates
Jan 24 02:39:41 	ntpd 	33227 	203.107.6.88 8011 81 mobilize assoc 39013
Jan 24 02:39:41 	ntpd 	33227 	kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Jan 24 02:39:41 	ntpd 	33227 	0.0.0.0 c01d 0d kern kernel time sync enabled
Jan 24 02:39:41 	ntpd 	33227 	kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Jan 24 02:39:41 	ntpd 	33227 	0.0.0.0 c012 02 freq_set kernel -8.436 PPM
Jan 24 02:39:41 	ntpd 	33227 	0.0.0.0 c016 06 restart
Jan 24 02:39:42 	ntpd 	33227 	203.107.6.88 8014 84 reachable
Jan 24 02:39:48 	ntpd 	33227 	203.107.6.88 901a 8a sys_peer
Jan 24 02:39:48 	ntpd 	33227 	0.0.0.0 c61c 0c clock_step +1.006254 s
Jan 24 02:39:49 	ntpd 	33227 	0.0.0.0 c615 05 clock_sync
Jan 24 02:40:58 	ntpd 	33227 	0.0.0.0 c618 08 no_sys_peer
Jan 24 02:40:58 	ntpd 	33227 	203.107.6.88 8014 84 reachable
Jan 24 02:41:04 	ntpd 	33227 	203.107.6.88 901a 8a sys_peer
Jan 24 02:41:08 	ntpd 	33227 	0.0.0.0 0628 08 no_sys_peer

Moreover, my pfSense instance is running in a virtual machine. The host OS is running Ubunutu + KVM + QEMU + libvirt in an Intel server.

]]>https://forum.netgate.com/post/1021557https://forum.netgate.com/post/1021557Mon, 24 Jan 2022 16:39:37 GMT<![CDATA[Reply to pfSense NTP server is very unstable. on Sun, 23 Jan 2022 15:49:37 GMT]]>Do you see anything in the system or ntp logs when it stops responding?

What does that ntp status show when it's in that state?

Steve

]]>https://forum.netgate.com/post/1021432https://forum.netgate.com/post/1021432Sun, 23 Jan 2022 15:49:37 GMT