NTP server stopped working
-
@belrpr said in NTP server stopped working:
Anyone know how to debug the problem?
Like : Windows 11 : (sorry; French GUI) :
where 192.168.1.1.is my pfSense router.
NTP server and client setup :
so the NTP server listens on my 3 LAN interfaces.
Every LAN interface need to contain firewall rules that permit NTP traffic - probably UDP, destination port 123.
Lets fact check :
[24.03-RC][root@pfSense.bhf.tld]/usr/local/pkg: sockstat -4 | grep ':123' root ntpd 77669 21 udp4 192.168.1.1:123 *:* root ntpd 77669 25 udp4 192.168.2.1:123 *:* root ntpd 77669 27 udp4 192.168.100.1:123 *:* root ntpd 77669 31 udp4 127.0.0.1:123 *:* root ntpd 77669 32 udp4 10.10.10.1:123 *:*and this proofs that the ntp daemon (== server) listens on all my LAN interfaces, port 123.
AFAIK, there is not much more to it.
Maybe this : check if the pool used is actualy usable :
So, yes, it is, my ntp 'client' is active, and synced with an upstream NTP server : Active Peer 2001:41d0:801:2000::acb
-
@Gertjan said in NTP server stopped working:
ce need to contain firewall rules that permit NTP traffic - probably UD
So I've checked all thing.
The lan rule is very open so this should be a problem:
These are my NTP settings:
Here is proof that it is listening:
My NTP status:
But when I try NTP tool to sync time it never gets an awnser:
when I query an external one it just works:
And I always tested using NTP tool.
Maybe noting that I have vlans for my guest and lan on a lag group of 2 fysical ports:
but this was from the beginning. -
Couldn't find NTPtool but found this :
Ok, I insisted. Found it .... ( normally, I wouldn't even consider installing this kind of pre Windows 7 software on a Windows 11 device ... ) but ok, and sure enough :
Port already in use ?????
WTF : this is - is it ? a client - not a server app ? A client doesn't 'bind to a port like that ..... Ditched NTP tool ....VLANs : never used them. if set up correctly, VLANs can't be an issue ;)
Btw : what about :
Hit start and now you see all incoming and outcoming LAN traffic using UDP on port 123 :
Client (my PC, 192.168.1.6) asking and pfSense (192.168.1.1) replying :
13:02:14.933372 IP (tos 0x0, ttl 128, id 25871, offset 0, flags [none], proto UDP (17), length 76) 192.168.1.6.52162 > 192.168.1.1.123: [udp sum ok] NTPv3, Client, length 48 Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 3922434134.684999999 (2024-04-18T13:02:14Z) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 3922434134.684999999 (2024-04-18T13:02:14Z) 13:02:14.933472 IP (tos 0xb8, ttl 64, id 29204, offset 0, flags [none], proto UDP (17), length 76) 192.168.1.1.123 > 192.168.1.6.52162: [udp sum ok] NTPv3, Server, length 48 Leap indicator: (0), Stratum 3 (secondary reference), poll 3 (8s), precision -23 Root Delay: 0.026702, Root dispersion: 0.019515, Reference-ID: 0xac099600 Reference Timestamp: 3922426453.956603380 (2024-04-18T10:54:13Z) Originator Timestamp: 3922434134.684999999 (2024-04-18T13:02:14Z) Receive Timestamp: 3922426934.933415658 (2024-04-18T11:02:14Z) Transmit Timestamp: 3922426934.933454875 (2024-04-18T11:02:14Z) Originator - Receive Timestamp: -7199.751584341 Originator - Transmit Timestamp: -7199.751545124 -
@Gertjan
So I requested 2 times the NTP from my laptop.
Then I got this result:
-
10.10.2.188 talks to 10.10.5.1 : these are /16 networks ?
Probably not related, and tells about my ignorance :
What is a "lagg" doing on a LAN ?
( link aggregation on a LAN ?) -
@Gertjan
The lan is /16. The guest is /24.
I need 16 because I have a lot of domotica which resides on the network.
I've used the lag for redundancy. If one cable is unplugged the other one will still serve both the lan and the guest network. -
I'm fine with all that.
But let me ask this question : on a /24 non-VLAN interface, with ntp listening on that interface (also), it works for you ? -
@belrpr that sure is a lot of domotica ;) 65k some ips..
Well it seems to answer 10.10.3.1 and .2 IPs..
Do you have any ACLs set on the ntp server, do you have any rules in floating? The traffic from 2.188 gets to pfsense, but ntp doesn't answer so either it has a ACL via ntp setup, or you have a rule say in floating blocking it?
-
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.
