NTP server stopped working
-
You appear to be using a VLAN1 tagged interface which can be problematic. Wouldn't be specific to ntp though.
Also it's common to find ntp using 123 as the source port as well as destination which means only one client can run at a time.
-
@stephenw10 said in NTP server stopped working:
Also it's common to find ntp using 123 as the source port as well as destination which means only one client can run at a time
Nice catch. That explains the error I had with this ntptool :
That could really put me on the path where I had to repair something that wasn't broken.
The windows native ntp client on the same PC was syncing just fine against pfSense.As I forgot to post m NTP ACL :
-
@Gertjan
My acl's are exactly the same. -
@Gertjan I have the same problem on another pfsense and there there isn't a lag group with vlans.
There each interface is a fysical interface. -
What exactly is failing?
-
@stephenw10 NTP is not reacting on clients.
It is like it isn't running. -
You mean it's not replying to queries? What failure do you see at the client?
Do you see the queries in a pcap on pfSense?
Does it reply to local queries from pfSense itself like?:
[24.03-RELEASE][admin@fw1.stevew.lan]/root: ntpdate -q 127.0.0.1 server 127.0.0.1, stratum 1, offset +0.000087, delay 0.02589 14 Jun 13:40:09 ntpdate[16884]: adjust time server 127.0.0.1 offset +0.000087 sec -
@belrpr you mean clients get no answer? Is pfsense seeing the traffic? is it actually listening on the IP your trying to talk to it? What are you firewall rules on this interface?
Do you have any rules in floating?
Have seen users create tcp rules, have seen policy routing above where they allow access to ntp, etc..
So you need to do some basic validation of what is actually going on to figure out what is wrong..
[23.09.1-RELEASE][admin@sg4860.home.arpa]/root: sockstat -4 | grep .123 root ntpd 83745 21 udp4 192.168.9.253:123 *:* root ntpd 83745 24 udp4 192.168.2.253:123 *:* root ntpd 83745 27 udp4 192.168.3.253:123 *:* root ntpd 83745 30 udp4 192.168.200.1:123 *:* root ntpd 83745 32 udp4 192.168.7.253:123 *:* root ntpd 83745 35 udp4 127.0.0.1:123 *:* root ntpd 83745 36 udp4 10.10.10.1:123 *:* root ntpd 83745 38 udp4 192.168.4.253:123 *:* root ntpd 83745 40 udp4 192.168.6.253:123 *:* root ntpd 83745 42 udp4 192.168.110.253:123 *:* root ntpd 83745 44 udp4 10.1.1.253:123 *:* [23.09.1-RELEASE][admin@sg4860.home.arpa]/root:I limited this to just IPv4 because no need to show my IPv6 GUA in an example.. With the -4 in the command.
Sniff to validate your clients traffic is getting to pfsense interface, is this interface tagged or native?
Lets see your firewall rules on the interface where traffic would be seen, etc.
-
@stephenw10
Hi I use a tool called NTP Tool.
It sends the request but never gets an awnser.Will do a pcap on pfsense but need to read some stuff about how to do that.
The local query works:server 127.0.0.1, stratum 2, offset +0.000096, delay 0.02606 14 Jun 15:07:27 ntpdate[7221]: adjust time server 127.0.0.1 offset +0.000096 sec@johnpoz said in NTP server stopped working:
sockstat -4 | grep .123
The sockestat command gives:
root ntpd 89229 22 udp4 127.0.0.1:123 *:* root ntpd 89229 24 udp4 10.10.5.1:123 *:* root ntpd 89229 26 udp4 172.16.3.1:123 *:* -
@belrpr so that is good info.. Now you just need to validate that pfsense is actually seeing the query from your client.
What are your firewall rules on the interface, do you have any floating rules?
Sniff is easy enough, under diagnostic menu, packet capture.. Pick your interface and port 123 and then do your test from your client.. Do you see that in the packet capture..
-
@belrpr said in NTP server stopped working:
Hi I use a tool called NTP Tool
Hummmm.
That does ring a bell.
Stop using that tool.Use another 'tool'.
Like this one :
( my French GUI Micorsoft Windows classic Time settings - but you have the same, as the info is valid since windows 95.)
I just synced with pfSense = 192.168.1.1 :
so my tool works.
