Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Local NTP with pfsense

    Scheduled Pinned Locked Moved General pfSense Questions
    14 Posts 4 Posters 1.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • F
      freddehmel
      last edited by

      Hi,
      we want to have a local NTP for the whole network. This are two test-setups:

      1. one pfsense 2.2.6, one public IP, NAT, a VM with Debian 9.9 and ntpd, two different configs: first with the pfsense as reference, second with the Debian-NTP-Pool.
        pfsense has two rules with udp/123 to "This Firewall" and to the Debian-VM with the NTP. pfsense has 0.pfsense.pool.ntp.org ... as their reference
        These are working.
      2. two pfsenses 2.4.2 in Carp-Mode, one /23, config is the same as above. This does not work.
        We tried to have the CARP-IP of the pfsenses or the physical IP of the master as reference. Also external pools as reference ...
        ntpstat says: unsynchronised, polling server every 8 s .....

      All internal configs are identical, difference is the setup of the pfsense (Release, Carp or not).
      Are there an ideas?

      Thanks in advance
      Fred

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        What exactly is not working in the second setup? pfSense itself is not synchronising? Both nodes? Or clients behind it are unable to sync to it?

        Both those systems need to be updated. 2.2.6 is waaaaay out of date! 😉 That should not be causing an ntp issue asfar as I know but there are many many other things that have been fixed since.

        Steve

        1 Reply Last reply Reply Quote 0
        • F
          freddehmel
          last edited by

          Hi Steve,
          time on pfsenses is correct. Clients cannot sync against the pfsense OR external Timeservers. When i sniff on a client, there i can see the "question" on 123, but no "answer".
          In the "small" setup i see:
          14:56:54.373942 IP 192.168.115.3.123 > 46.182.18.245.123: NTPv4, Client, length 48
          14:56:54.430933 IP 46.182.18.245.123 > 192.168.115.3.123: NTPv4, Server, length 48
          In the other setup there is no answer.
          So i think, it´s belonging to the ruleset, but they are identical: incoming udp/123 to "This Firewall" and to the Debian-VM with the NTP.
          Thanks for your thoughts.
          Fred

          1 Reply Last reply Reply Quote 0
          • I
            isolatedvirus
            last edited by

            allowed to vip ip as well?

            F 1 Reply Last reply Reply Quote 0
            • stephenw10S
              stephenw10 Netgate Administrator
              last edited by

              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 :123 make 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

              F 1 Reply Last reply Reply Quote 0
              • F
                freddehmel @isolatedvirus
                last edited by

                @isolatedvirus
                You mean to the virtual public wan-address? Yes. This should be "this firewall", isn´t it?
                Fred

                1 Reply Last reply Reply Quote 0
                • F
                  freddehmel @stephenw10
                  last edited by

                  @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

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

                    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

                    1 Reply Last reply Reply Quote 0
                    • F
                      freddehmel
                      last edited by freddehmel

                      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

                      1 Reply Last reply Reply Quote 0
                      • johnpozJ
                        johnpoz LAYER 8 Global Moderator
                        last edited by johnpoz

                        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..

                        An intelligent man is sometimes forced to be drunk to spend time with his fools
                        If you get confused: Listen to the Music Play
                        Please don't Chat/PM me for help, unless mod related
                        SG-4860 24.11 | Lab VMs 2.7.2, 24.11

                        1 Reply Last reply Reply Quote 0
                        • stephenw10S
                          stephenw10 Netgate Administrator
                          last edited by

                          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

                          1 Reply Last reply Reply Quote 0
                          • johnpozJ
                            johnpoz LAYER 8 Global Moderator
                            last edited by

                            @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?

                            An intelligent man is sometimes forced to be drunk to spend time with his fools
                            If you get confused: Listen to the Music Play
                            Please don't Chat/PM me for help, unless mod related
                            SG-4860 24.11 | Lab VMs 2.7.2, 24.11

                            1 Reply Last reply Reply Quote 0
                            • F
                              freddehmel
                              last edited by

                              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

                              1 Reply Last reply Reply Quote 0
                              • F
                                freddehmel
                                last edited by

                                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

                                1 Reply Last reply Reply Quote 0
                                • First post
                                  Last post
                                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.