[Solved] Am I really using pfSense as NTP server ...?
-
@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 :)
