Local NTP with pfsense
-
allowed to vip ip as well?
-
If clients behind the HA pair are trying to sync against external NTP servers that should be no different to any other external server type. Unless maybe you have a firewall or NAT rule set as TCP only, which is possible since that's the default for firewall rules.
Check the firewall state table for:123make sure there are at least states being opened fro the client on the LAN and that they are being NAT'd correctly on WAN.Steve
-
@isolatedvirus
You mean to the virtual public wan-address? Yes. This should be "this firewall", isn´t it?
Fred -
@stephenw10
There is no other firewall and the rules ARE udp-ones.
I will cancel the ntp-part of our firewall-setup and do it once again. Than i will come back .
Fred -
I may have misread this. You have external clients trying to use NTP on the firewall (via the WAN address)? Or to the server behind it via port forwards?
I assumed it was internal clients as you almost never want to have ntp open on the WAN. Your ISP may well be blocking it if that's the case.
Steve
-
You don´t misread it. The service is for our hosts.
We tried to use the pfsenses itself working as a Reference and we tried to reference direct against public NTP-Pools. Both are not working in our HA-Setup, but in our small one with the old release.
Difference is one 100 MBit and a cable modem (Vodafone)<--> seven Fibers and two Brocade Routers in front of the Firewalls. And: no, there is no protocol oder port filtering in our routers.
Fred -
If your ntp server running and listening on your public interface.. Just sniff - just do a simple package capture.. Do you see queries?
This not hard to troubleshoot..
Sniffing on the client seeing it send the query is step 1.. But since you are providing the answer, you need to actually validate the query reaches your server(be it pfsense or not).. If your having others query your public wan... Then sniff on your public wan IP.. Do you see the query or not?
While you might not be blocking at you routers.. You still need to validate the traffic actually gets to where your going to serve the answer from.. And you need to validate its actually listening, etc..
-
Yes. Where are you testing from? Your pcap lines show it's from a private IP I assume that is behind some other router at some completely different location?
If there are no replies coming back to that just pcap on the primary WAN for incoming port 123. Are they actually arriving?
Steve
-
@freddehmel said in Local NTP with pfsense:
192.168.115.3.123 > 46.182.18.245.123:
If that is hitting your wan from wan it would be blocked by the default block rfc1918 rule that is out of the box on wan of pfsense.
So I am with stephenw10 - where exactly are you testing from?
-
OK, my infos were not as correct as they should. Sorry.
This is from "Paket Log" with WAN, udp,123, 193.yyy.xxx.xxx is physical IP of pfsense-master:
09:50:37.972097 IP 193.yyy.xxx.xxx.123 > 88.198.52.243.123: UDP, length 48
09:50:37.986078 IP 88.198.52.243.123 > 193.yyy.xxx.xxx.123: UDP, length 48
...
This is with tcpdump -nn -i ens192 |grep .123
on a Debian-System 192.168.114.137, .114.2 is the physical IP of the master-pfsense, which is defined in the ntp.conf as reference:09:51:19.736248 IP 192.168.114.137.123 > 192.168.114.2.123: NTPv4, Client, length 48
09:52:26.736309 IP 192.168.114.137.123 > 192.168.114.2.123: NTPv4, Client, length 48
...
This is from states-table, filter
WAN udp 193.yyy.xxx.xxx:123 -> 62.116.130.3:123
WAN udp 193.yyy.xxx.xxx:123 -> 138.201.64.208:123
WAN udp 193.yyy.xxx.xxx:123 -> 178.63.9.212:123
...There is one relevant rule for inbound from any,udp, any ports to "This Firewall".
Bogons and similar are not filtered.
Pfsense-pools are reference for ntp.Hope these details are better.
Fred -
Ok it´s solved!
As mentioned I canceled all ntp-relevant setups and build up this as new.
Of course: it does´t work: my test-client did not syncronise with the running NTPd on pfsense.
I found a little tuto which described how to configure such a setup. Nothing new at all but it says how one could test if it works. This test was new for me: stop the ntp-service on the client, give ntpdate 192.168.114.1 (which is the CARP-LAN-IP) and start the service again.
The ntpdate says: "no server suitable for synchronization found". A rule for udp/123 from LAN to the FW is active. Than i checked some configs in the Switch between the FW and the VM-Host with the test-client. It was preventing "SYN/SYN-ACK Flooding". Made tests, checked it twice, problem was found.Thanks for all advices and hints.
Fred
