NTP woes
-
-
I get the first two lines, but what is the third used for?
It is not needed here but if the host is already connecting to the firewall, then this is allowed and I don't have to make the rule on that interface.
Now, that I am thinking about it, my solution to not redirect traffic already going to the firewall isn't that great to look at, probably should redirect everything.
-
@bob-dig Thanks for explaining, and well, it helped me... :)
-
But... With this NTP redirect rule in place, should I still need to allow each network access to the NTP server?? I thought this was that setup, or have I managed to get something wrong...
It works, I now see the pfSense IP instead of a pool one for NTP, but, is this expected?
-
I get the first two lines, but what is the third used for?
It is not needed here but if the host is already connecting to the firewall, then this is allowed and I don't have to make the rule on that interface.
I'd say, the third one is all you really need.
It covers all interface assigned addresses as well as localhost. And since you don't redirect interface IPs, you need all of them.
But you can spare the first two rules, since the third covers also both protocols, IPv4 and v6. -
Interesting... It seemed to be working, then I renamed the interface group, and while the config looks ok (reflects the new name), it now tries to get NTP from all over the place again...
-
it now tries to get NTP from all over the place again...
Your internal devices?
They will not notice the redirection. When devices tries to request e.g. 1.1.1.1 and pfSense redirects it to itself, it sends response packets back with 1.1.1.1 as source address. Hence the device will think, it's all right, the server is responding as expected.
You can check the states for outbound NTP connections to see if your rules are working.
-
@viragomann said in NTP woes:
it now tries to get NTP from all over the place again...
Your internal devices?
Yes, they are trying to get NTP from WAN addresses again... I have not yet enabled the NTP server of pfSense, but anyhow, they should try NTP from pfSenseIP:123, right?
-
Yes, they are trying to get NTP from WAN addresses again... I have not yet enabled the NTP server of pfSense
Why not? I assumed, that's your goal here.
they should try NTP from pfSenseIP:123, right?
This is expected on an DHCP-enabled device, when it pulls the IP from pfSense and you have the NTP server enabled.
But as stated here in this thread, some devices doesn't obey the NTP settings provided by DHCP anyway.
For these we redirect the NTP requests to pfSense. And if the device requests for instance time.google.com 216.239.35.8:123, pfSense responses with exactly this IP. -
I changed my rules to be more slick. I am now redirecting everything.
-
@viragomann Oh. My bad then. I thought the logs would show pfSense was serving the time. Time to enjoy this now, thanks a lot for the help!
-
-
Oh! Will read some. I thought "stratum" was when you had your own GPS. Thanks for the link! :)
You might also want to read about International Atomic Time, which NTP is supposed to be traceable to. I provided a Wikipedia link earlier.
Thanks! I will have a look at that too. :)
-
