NTP: a Windows PC can't get time from pfSense. Other devices are okay.

Gertjan

Go to basic mode first.

Unselect everything :

and restart NTPd.

Then check in which ports its listening :

[24.11-RELEASE][root@pfSense.bhfr.tld]/root: sockstat -4 | grep '123'
root     ntpd       44699 21  udp4   *:123                 *:*
root     ntpd       44699 23  udp4   192.168.1.1:123       *:*
root     ntpd       44699 27  udp4   192.168.2.1:123       *:*
root     ntpd       44699 29  udp4   192.168.100.1:123     *:*
root     ntpd       44699 31  udp4   192.168.10.4:123      *:*
root     ntpd       44699 35  udp4   127.0.0.1:123         *:*
root     ntpd       44699 36  udp4   10.10.10.1:123        *:*

These are all my known interfaces, port 123, UDP.

Then check the LAN firewall rules :

The first rule is a NUT NAT rule, very comparable to what you try to achieve.
But, as NTP listens to your LAN interface, why NATting it to 127.0.0.1 ?
NUT listens by default to 127.0.0.1 so the NAT is a solution.

The other two IPv4 and IPv6 rules are tested and work. because your pfSense was delivered to you with these two rules.

Between your PC and pfSense, removing everything else. a dumb "no options" switch is allowed of course.

Did you packet capture the LAN interface ?
You know the IP of the PC, the port used (123) and the protocol, UDP. Thats enough to check what arrives at pfSense.

Gertjan

@youngy said in NTP: a Windows PC can't get time from pfSense. Other devices are okay.:

I've tried providing different NTP servers in DHCP for the interface but that hasn't worked either

A DHCP server can be stuffed with all the options in teh workd, but if the DHCP client, your PC, didn't asked for an NTP server (one, or more), then the server will not send it.

Check for yourself : packet capture : all set up just for you :

and click on start an see what happens.
You'll see the entire DHCP negotiation as it was meant to be since "1970" (I guess, DHCP is old).

You'll discover that Microsoft systems don't stuff doesn't ask for a NTP server.
They have a ntp host name build, to some NTP Microsoft server (Microsoft loves to call home ^^)

youngy

@Gertjan Great, thanks for this. Much appreciated. I'll try it a bit later.

youngy

@Gertjan I've done what you suggested (bar the pcap)- resetting NTP and making sure the any any rule was working (what are the advanced settings that you use?). And I also disabled all the NTP firewall rules for redirecting etc.

The good news is the PC can now sync with the time server (pool.ntp.org). Whenever I try to get it to use pfSense NTP it fails. As it's a portable PC I'll just leave it as it is now (which I think is what @johnpoz was suggesting as well).

I set up the NAT redirect for NTP because it was a Netgate suggestion from a while ago.

Many thanks for your help.

johnpoz

@youngy said in NTP: a Windows PC can't get time from pfSense. Other devices are okay.:

As it's a portable PC I'll just leave it as it is now (which I think is what @johnpoz was suggesting as well).

no what I was suggesting is actually point windows to the IP of pfsense for its ntp.. And I use the actual ntp client on windows, not whatever junk windows has built in.

youngy

@johnpoz Right, okay. Thanks for clarifying. I changed Windows time server from time.windows.com to pool.ntp.org and allow the PC access to it. It seems to work fine now.

johnpoz

@youngy that isn't getting time from pfsense - why not just point to pfsense IP or fqdn?

youngy

@johnpoz I don't seem to understand this properly. I've tried things such as a redirect with no joy. I tried setting a host override but that didn't work, finally I tried setting the time server in Windows to my pfSense fqdn and then to its IP but that didn't work either. The only way I can get the PC to sync with a time server is to let it go out to the internet to sync with pool.ntp.org or similar. I'll try a packet capture tomorrow as shown by @Gertjan and see what that shows. Thanks for helping me push this along.

youngy

@youngy @johnpoz @Gertjan . This problem appears to be fixed now. I presume at some time and for some reason I had selected the Service box in the default ACLs for NTP. I decided to look for the default settings and noticed in a post that Service wasn't selected. I deselected it and let NTP restart. Once I re-enabled the redirects for port 123 everything started working as it's supposed to. Thanks for helping me get to the bottom of this.

johnpoz

@youngy said in NTP: a Windows PC can't get time from pfSense. Other devices are okay.:

All my other devices seem to work okay

Well guess none of your other devices are even pointing at pfsense for ntp then, or your redirects were not setup correctly either than.. Because if you had that checked nothing would of been able to get time from ntp on pfsense.

And you stated all your other devices were working.

youngy

@johnpoz yes I thought that was the case. For the wired devices, I just set the time server on the client to be the pfSense fqdn. I could see other devices getting redirected to localhost in the log so assumed they were fine but likely not as you say. It was just the windows PC that complained. I didn’t validate the setup, which in hindsight was a mistake. Lesson learnt.

johnpoz

@youngy said in NTP: a Windows PC can't get time from pfSense. Other devices are okay.:

Lesson learnt.

I would prob actually validate time sync is going to where you want, either directly pointing to pfsense which is always prob the best idea vs redirect. And working, or via your redirect.

I had some stupid iot devices (wifi light bulbs) that were pointing to pool address, not even in my country.. had some using uk.pool.ntp.org, which makes zero sense because they were bought in the states.. Someone messed up and didn't alter the code for regions they were going to be sold, etc..

So I just set a host override to point uk.pool.ntp.org to my ntp server.

A sniff (packet capture) for ntp will give great info that clients who clients are asking, and if being redirected, etc. you should see the client query and then response.