[Solved] Am I really using pfSense as NTP server ...?
-
Maybe you have a client that's asking too frequently. I've been running NTP servers for many years, even before I used pfSense, and have never seen that.
The way it works is your server syncs with whatever servers you select and then makes the time available to clients. You can have multiple servers and that provides better accuracy and redundancy. You should have at least 3 sources and some say as many as 5 or 6. You don't want 2, as if one goes bad and produces the wrong time, your server won't know which one and will cut them both off. I use 3 stratum 1 servers and 3 stratum 2.
Use Packet Capture to see where those KoD packets are being sent.
-
@JKnott said in Am I really using pfSense as NTP server ...?:
Maybe you have a client that's asking too frequently. I've been running NTP servers for many years, even before I used pfSense, and have never seen that.
The way it works is your server syncs with whatever servers you select and then makes the time available to clients. You can have multiple servers and that provides better accuracy and redundancy. You should have at least 3 sources and some say as many as 5 or 6. You don't want 2, as if one goes bad and produces the wrong time, your server won't know which one and will cut them both off. I use 3 stratum 1 servers and 3 stratum 2.
Use Packet Capture to see where those KoD packets are being sent.
Thanks, but that's just it.. If any of my clients ask pfSense too much it shouldn't generate KoD's from an external NTP...? What I'd expect is pfSense responding locally, no?
-
@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.
