Incoming NTP packets not reaching destination
-
I'm not sure that linked thread still applies. It was written at the time of 2.0.2 so many fixes have gone in since then.
What happens if you unselect all three interfaces so that it's listening on all three?
I assume you haven't opened port 123 on WAN by the way which would then expose your NTP server to the world, which would be bad!Your UDP rule on LAN will not do anything unless your LAN servers are trying to connect to external NTP servers directly.
Steve
-
@sthepen If I select no interface on the NTP service all goes "unreach/pending"
If I select the 3, all also goes "unreach/pending"There's no NAT rule UDP Port 123. It's closed
-
Are those NTP servers you have set all public or are some of them at your ISP?
You could try setting a static route to one of them via the Liberty gateway.
I meant a firewall rule not a NAT rule. There would be no need for NAT as the NTP service is running on the WAN interfaces themselves.
Steve
-
@johnpoz Sorry I didnt explain the situation in great detail, your suggested rule to allow UDP in the LAN wont do nothing.
The Window servers I want to sync and the pfSense are in the same "physical" ESX… meaning, it's a virtual network and pfSense has no control over it.
There reason there's a LAN interface on the pfSense is because ESX1 is connected to ESX2... that is the "LAN" pfSense controls.All the servers and inconming ISP connections are physically on the ESX1, so there should be no need at all to touch any LAN rule. The reason I created the rule in the first place was to make sure all NTP traffic to public servers was going trough LIBERTY and not WORLDNET.
-
Your UDP rule on LAN will not do anything unless your LAN servers are trying to connect to external NTP servers directly.
and actually that rule will push all requests out the Liberty gateway. Even a LAN client trying to get NTP from pfSense LAN address will have the request pushed out Liberty gateway, which won't be able to route it anywhere useful.
Put destination !LANaddress in that rule. -
@sthepen here's the NTP list I'm using:
0.pfsense.pool.ntp.org
1.pfsense.pool.ntp.org
2.pfsense.pool.ntp.org
time-a.nist.gov
time-b.nist.gov
0.north-america.pool.ntp.org
1.north-america.pool.ntp.org
2.north-america.pool.ntp.orgA static route is a great suggestion. I set 1 up to time-a.nist.gov (129.6.15.28):
And now the NTP service, withc is only configured on LAN and would normally give all "unreach/pending" is showing:
However, the static route seems to be working only by IP… is there a way to configure with FQDN?
-
and actually that rule will push all requests out the Liberty gateway
Agreed and not only ntp but ANY udp traffic – like DNS for example.. That is really bad rule to put in place to be honest and not required.
-
No, I don't think so but you could just add more routes and use fixed NTP servers. You probably don't need 8 anyway.
Take note of Phils excellent point above. That rule might be bypassing the pfSense NTP server altogether, though I believe the negate rules should allow access to it if you haven't disabled that.
I'm confused about your ESX setup. You surely need a LAN interface for your servers behind pfSense which are on the same VM host? :-\
Steve
-
@johnpoz @shepen Yes I deleted the rule right away after reading John comment, thanks :)
So I ended up using a fixed IP list on NTP server (utcnist2.colorado.edu time-a.nist.gov time-b.nist.gov time-c.nist.gov nist1.symmetricom.com)
Thank you very much guys for you time and patience :)
-
Is it still necessary to have the NTP server listen on your WAN interfaces? I would certainly have it configured to only listen on LAN if not.
Steve
-
@stephen Is only configured on the LAN port, thanks for asking!
