[Solved] Am I really using pfSense as NTP server ...?
-
It's ntpd that responds locally. There is no forwarding ntp queries.
You should be able to see states for ntp queries that are somehow missing your redirect. If they exist.
The only other option might be that clients are using one of the encrypted ntp types to connect externally. But if that was the case you probably wouldn't see the KoD packets. Not something I've ever looked into though.
Steve
-
@furom ntpq is polling at the correct rate, which is at the default of 64 seconds, but it will relax to a slower rate if/when it is happy.
At this point I think we are looking at your ntpq instance issuing KoD at a LAN client or clients. This may be due to an excessive request rate or simply due to ntpq not being happy about its own status.
️ -
@stephenw10 said in Am I really using pfSense as NTP server ...?:
It's ntpd that responds locally. There is no forwarding ntp queries.
You should be able to see states for ntp queries that are somehow missing your redirect. If they exist.
The only other option might be that clients are using one of the encrypted ntp types to connect externally. But if that was the case you probably wouldn't see the KoD packets. Not something I've ever looked into though.
Steve
Ok. Well, it was just a bit of a mystery, probably not something to dig much deeper in. Thanks all for the feedback and insights. :)
-
@RobbieTT Well, if so, shouldn't these KoD packets originate from pfSense? Anyhow, I haven't seen any new ones since yesterday, so guess whatever the issue was is gone for now at least. Thanks :)
-
@stephenw10 said in Am I really using pfSense as NTP server ...?:
The only other option might be that clients are using one of the encrypted ntp types to connect externally. But if that was the case you probably wouldn't see the KoD packets. Not something I've ever looked into though.
Steve
Steve, your instinct is correct as an encrypted ntp would not return a
KoD. It would either drop or, more helpfully, issue aCRYPresponse.️ -
@furom
Did you forward NAT request to your pfSense on local interfaces? -
@viragomann Yes, I have rules like this in place on them
-
@furom
No, that is a simple pass rule.
I was asking if you redirect all NTP requests to pfSense. -
@viragomann Sure, I know, NAT one is in the first post
-
@furom
Ah ya.
So I guess, that the KoDs came from pfSense.The client might be configured to request an NTP pool. But since all requests are redirected to the pfSense NTP server, this one gets many requests in a period of time and sends a KoD then.
However, the client thinks, he got the KoD from one of the pool server he was requesting, because pfSense is using the origin request IP as source in responds.Had the same issue lately after redirecting NTP requests.
-
@viragomann said in [Solved] Am I really using pfSense as NTP server ...?:
@furom
Ah ya.
So I guess, that the KoDs came from pfSense.The client might be configured to request an NTP pool. But since all requests are redirected to the pfSense NTP server, this one gets many requests in a period of time and sends a KoD then.
However, the client thinks, he got the KoD from one of the pool server he was requesting, because pfSense is using the origin request IP as source in responds.Had the same issue lately after redirecting NTP requests.
Thanks, Yeah, that's probably it then. Thanks for having a look at it :)
-
@viragomann Effectively in this scenario clients that can or prefer to go to external NTP source get pushed to pfSense's internal NTP server. If pfSense is not happy about its own suitability then every request to every external source comes back with a KoD generated by pfSense's ntpq.
So every restart or ntpq restart will have pfSense issuing KoDs (effectively a 'I don't know, ask someone else' command) to all clients, no matter what external NTP source they think they are asking or trying instead because of the previous KoD... so on they go again with the next attempt.
️ -
@RobbieTT
Yes, I know.
I was unhappy about the many KoD complains in the clients log. So I removed the NTP pool from its settings. -
@viragomann Don't forget about DHCP Option 42, where you can tell clients where to go (and in what order) for NTP. It can avoid the 'ask me only' and 'I don't know' circular path you found yourself in.
️ -
@RobbieTT This is a very good solution if your pfSense box is handing out DHCP leases for clients behind it. I do this and point all clients to the pfSense box and the pfSense box deals with the "pool". No NAT redirections or anything.
-
@mer said in [Solved] Am I really using pfSense as NTP server ...?:
@RobbieTT This is a very good solution if your pfSense box is handing out DHCP leases for clients behind it. I do this and point all clients to the pfSense box and the pfSense box deals with the "pool". No NAT redirections or anything.
I agree but unfortunately some clients don't request the Option in their DHCP Request, so it is not returned with the DHCP ACK.
For example, macOS only requests Options 1,3,6,15,51,53,54 and the 255.
Other than that I see no downsides.
️ -
@furom have you tried a negated rule and added the loop back and firewall IP addresses as an alias and set a nat rule to anything not that alias redirect to the firewall?
I noticed you only have a any any to the loopback. I had some issues with my nat set like that. Mine needed both loopback and firewall. To do that I needed the negated rule with the "!" this way it redirects any NTP requests right to the firewall the clients all work for me, even if they attempt to access a Windows time server.
(Image: showing negated NAT rules)
(Image: showing alias for NTP use) -
@JonathanLee Hi,
This would probably be as good too. My rule above is Any for all my interfaces. It seems to work as intended, all traffic goes to pfSense as is now. But will remember this to try in case of issues in the future. Thanks :)
