NTP: a Windows PC can't get time from pfSense. Other devices are okay.
-
@mer said in NTP: a Windows PC can't get time from pfSense. Other devices are okay.:
Is Windows really using NTP? I've seen stuff in the past where it's not really using NTP but some variant.
It is.
and I have the packet capture to proof it
-
Gertjan,
Thanks for helping.@Gertjan said in NTP: a Windows PC can't get time from pfSense. Other devices are okay.:
Your Surface connects to an AP using its SSID, and this AP is connected to the Unifi switch, which is connected to the pfSense, on the WAN interface ??
Yes, the APs are connected to the Unifi switch, which is connected to LAN. The VLANs are setup on pfSense and are set up the same in the Unifi controller (IIRC I followed a Lawrence Systems video when I first set up the 2100 about 5 years ago).
Also, a question : does the NTP server listens on the WAN interface ? Maybe it does, I'm not sure, you better check that.
These are the NTP settings (no interface selected - I think that's the default).
Try this : hook up your PC t the pfSense LAN interface.
tell the PC that its NTP source is "192.168.1.1".
That's why I do. Tested and works.
Just do the test to be sure that this isn't a "PC" issue.As suggested, I attached the PC directly to pfSense LAN (wired), but the PC still didn't get the time.
-
@youngy said in NTP: a Windows PC can't get time from pfSense. Other devices are okay.:
I attached the PC directly
and you set manually :
Btw : even if you tell the DHCPv4 and or DHCPv6 server ton hand over an NTOP source (server = pfSense), like this :
you'll discover that Microsoft devices don't ask for it, and not using the suggestion it found in the DHCP lease.
This is one of the rare settings you have to do for every Microsoft device, if you want it to pfSense as time source. Which is optional, of course, as the default time.Microsoft.com (can't remember what is in there when you install Windows) will work just fine.With the default LAN firewall rules Netgate put into the LAN, NTP works fine.
-
Yes, I set the time server as shown above.
I've just set the time server on Windows to pool.ntp.org. If I connect the PC to my phone hotspot and my phone is on celluar service, the time syncs immediately. When I reconnect the PC to my wifi it fails to sync even though it's allowed to the firewall:
I've tried providing different NTP servers in DHCP for the interface but that hasn't worked either. I'm a bit baffled about what to try next. Any suggestions would be appreciated.
-
@youngy how about just pointing to the IP vs trying to redirect it.
What part did you not get about windows not using ntp handed out by dhcp?
Personally I hate the time sync built into windows, and just use the actual ntp client
C:\Windows\system32>ntpq ntpq> pe remote refid st t when poll reach delay offset jitter ============================================================================== *ntp.home.arpa .PPS. 1 u 51 128 377 0.752 +0.019 0.194 ntpq> -
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. -
@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 ^^) -
@Gertjan Great, thanks for this. Much appreciated. I'll try it a bit later.
-
@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.
-
@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.
-
@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.
-
@youngy that isn't getting time from pfsense - why not just point to pfsense IP or fqdn?
-
@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 @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.
-
@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.
-
@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.
-
@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.
