[Solved] Am I really using pfSense as NTP server ...?
-
@furom The pfSense GUI will show you when and how often it is polling from the sources and if they are actually available:
You can go deeper than this but it will probably answer your question.
️ -
Yes, ntpd should just respond to clients locally. That should not generate additional external queries.
-
@stephenw10 said in Am I really using pfSense as NTP server ...?:
Yes, ntpd should just respond to clients locally. That should not generate additional external queries.
So I could be forwarding queries somehow... I certainly don't intend to, I would be very happy keeping clients in sync with pfSense. Does my rule for catching NTP look alright? Before that I had all sorts of NTP requests blocked, so thought a NAT was the way to go, but perhaps pfSense is not what actually responds in my case?
-
@RobbieTT Thanks :) What I am concerned about is if my clients are in fact served by pfSense, or if my NAT is not enough to contain local NTP traffic...
-
@furom Understood. Are you going to post your Status / NTP table?
️ -
@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.
