[Solved] Am I really using pfSense as NTP server ...?
-
@RobbieTT Here it is, it looks a lot like yours I suppose
-
@furom said in Am I really using pfSense as NTP server ...?:
So I could be forwarding queries somehow... I certainly don't intend to,
If you look at your firewall rule, in the comment you stated that indeed to "redirect NTP to pfSense." So, that implied it was by design. Here is mine also as well as firewall rule:
-
@furom It's not looking that healthy. One active peer is good but there are no other NTP servers with "Candidate" status.
Has it recently been restated?
️ -
@RobbieTT Yes, I have been fiddling with it, so probably why
-
@NollipfSense said in Am I really using pfSense as NTP server ...?:
@furom said in Am I really using pfSense as NTP server ...?:
So I could be forwarding queries somehow... I certainly don't intend to,
If you look at your firewall rule, in the comment you stated that indeed to "redirect NTP to pfSense." So, that implied it was by design. Here is mine also:
Well, yes. I wrote the rule with intention to send all traffic to pfSense. I believe that part to work fine, but what actually responds to it, if it is pfSense or some external NTP is the question as I did get KoD packets from external NTP servers
-
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.
