NTP not working on 2.1.1 pre-release
-
I am getting all the right data from the NTP server as shown below…
Status Server Ref ID Stratum Type When Poll Reach Delay Offset Jitter
Active Peer xxx.xxx.xxx.xxx 96.47.67.105 2 u 184 256 377 94.100 -5.010 2.161And in NTP status I see…
istening on routing socket on fd #30 for interface updates
Feb 2 17:46:33 ntpd[62296]: Listen normally on 9 bridge0 192.168.1.1:123
Feb 2 17:46:33 ntpd[62296]: setsockopt IPV6_MULTICAST_IF 0 for fe80::7ae4:ff:fe4b:36a4%9 fails: Can't assign requested address
Feb 2 17:46:33 ntpd[62296]: Listen normally on 8 ath0_wlan0 [fe80::7ae4:ff:fe4b:36a4%9]:123
Feb 2 17:46:33 ntpd[62296]: setsockopt IPV6_MULTICAST_IF 0 for fe80::1%7 fails: Can't assign requested address
Feb 2 17:46:33 ntpd[62296]: Listen normally on 7 lo0 [fe80::1%7]:123
Feb 2 17:46:33 ntpd[62296]: Listen normally on 6 lo0 [::1]:123
Feb 2 17:46:33 ntpd[62296]: Listen normally on 5 lo0 127.0.0.1:123I don't have ivp6 so I assume those are warnings…
The problem is no ntp client has yet to be served by nptd. I have even redirected their ip address to 127.0.0.1:123 And can see this in the logs. But the clients continuously request service. And no messages in the ntp logs indicating beyond listening.
-
It looks like this is due to the added "limited" keyword from issue #3384. I'm backing out that chance since it breaks acting as a server. Next snapshot dated after this post should be OK.
-
See https://redmine.pfsense.org/issues/3384#note-5
-
I see what the limited is for. But I should probably ask a few questions about it before a release is committed.
When it is working, will ntp respond to "any" request passing through the interface on 123 regardless of dest ip and consume the packet?
Or am I supposed to create a NAT to redirect them to localhost myself?
Also since it seems your experiencing ntp storms. I have found that there are embedded devices on the market that pretend to ask for time on port 123. But go to a hard coded ip address of their choosing and use it for communications. So it is entirely possible to get a packet on port 123 and look like nonsense to your ntp server.
The bad news if the rogue device is redirected to the local ntp server and the device is expecting a non-ntp response. It will start storming since the ntp server didn't act like the server it was expecting and will keep trying until it gets what it wants.
-
ntp binds to any (or the interfaces you select in the GUI). No need for NAT in most cases unless you bind only to localhost.
It will respond to anyone you allow to reach the NTP service. Proper firewall rules control access effectively.
Personally, I haven't witnessed any such misbehaving NTP clients, but I've seen enough broken devices to know they probably exist somewhere I just haven't seen them myself.
-
I see what the limited is for. But I should probably ask a few questions about it before a release is committed.
When it is working, will ntp respond to "any" request passing through the interface on 123 regardless of dest ip and consume the packet?
Or am I supposed to create a NAT to redirect them to localhost myself?
Also since it seems your experiencing ntp storms. I have found that there are embedded devices on the market that pretend to ask for time on port 123. But go to a hard coded ip address of their choosing and use it for communications. So it is entirely possible to get a packet on port 123 and look like nonsense to your ntp server.
The bad news if the rogue device is redirected to the local ntp server and the device is expecting a non-ntp response. It will start storming since the ntp server didn't act like the server it was expecting and will keep trying until it gets what it wants.
Basically what jimp said, I will add my personal experience though since it pertains to your question….
NTP will only respond to requests directed at an IP it is bound to.
That being said, I have at least one crappy home wireless AP on my network that has a hard coded NTP server IP list. I use NAT to redirect the one public IP I set it to use for NTP, back into the LAN IP of pfSense, only on dest port 123, only from the source IP of the wireless AP. It works, and works well.
This is the only case you should have to do any odd NAT redirects for NTP, unless you want to do a global port 123 redirect to your internal NTP server, and that really shouldn't be done for a multitude of reasons.
Other than that, NTPd will handle all the NTP request denies / drops without effecting non-NTP port 123 traffic when throttling is enabled.
-
Feb 8 14:10:33 ntpd[34622]: restrict ::: KOD does nothing without LIMITED. Feb 8 14:10:33 ntpd[34622]: restrict 0.0.0.0: KOD does nothing without LIMITED.So should "kod" also be removed then?
