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

    NTP not working on 2.1.1 pre-release

    Scheduled Pinned Locked Moved 2.1.1 Snapshot Feedback and Problems - RETIRED
    7 Posts 4 Posters 3.4k 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.
    • K
      kevin067
      last edited by

      I am getting all the right data from the NTP server as shown below…

      Status Server Ref ID Stratum Type When Poll Reach Delay Offset Jitter
      Active Peer xxx.xxx.xxx.xxx 96.47.67.105 2 u 184 256 377 94.100 -5.010 2.161

      And in NTP status I see…
      istening on routing socket on fd #30 for interface updates
      Feb 2 17:46:33 ntpd[62296]: Listen normally on 9 bridge0 192.168.1.1:123
      Feb 2 17:46:33 ntpd[62296]: setsockopt IPV6_MULTICAST_IF 0 for fe80::7ae4:ff:fe4b:36a4%9 fails: Can't assign requested address
      Feb 2 17:46:33 ntpd[62296]: Listen normally on 8 ath0_wlan0 [fe80::7ae4:ff:fe4b:36a4%9]:123
      Feb 2 17:46:33 ntpd[62296]: setsockopt IPV6_MULTICAST_IF 0 for fe80::1%7 fails: Can't assign requested address
      Feb 2 17:46:33 ntpd[62296]: Listen normally on 7 lo0 [fe80::1%7]:123
      Feb 2 17:46:33 ntpd[62296]: Listen normally on 6 lo0 [::1]:123
      Feb 2 17:46:33 ntpd[62296]: Listen normally on 5 lo0 127.0.0.1:123

      I don't have ivp6 so I assume those are warnings…

      The problem is no ntp client has yet to be served by nptd. I have even redirected their ip address to 127.0.0.1:123 And can see this in the logs. But the clients continuously request service. And no messages in the ntp logs indicating beyond listening.

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        It looks like this is due to the added "limited" keyword from issue #3384. I'm backing out that chance since it breaks acting as a server. Next snapshot dated after this post should be OK.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • K
          ky41083 Banned
          last edited by

          See https://redmine.pfsense.org/issues/3384#note-5

          1 Reply Last reply Reply Quote 0
          • K
            kevin067
            last edited by

            I see what the limited is for. But I should probably ask a few questions about it before a release is committed.

            When it is working, will ntp respond to "any" request passing through the interface on 123 regardless of dest ip and consume the packet?

            Or am I supposed to create a NAT to redirect them to localhost myself?

            Also since it seems your experiencing ntp storms. I have found that there are embedded devices on the market that pretend to ask for time on port 123. But go to a hard coded ip address of their choosing and use it for communications. So it is entirely possible to get a packet on port 123 and look like nonsense to your ntp server.

            The bad news if the rogue device is redirected to the local ntp server and the device is expecting a non-ntp response. It will start storming since the ntp server didn't act like the server it was expecting and will keep trying until it gets what it wants.

            1 Reply Last reply Reply Quote 0
            • jimpJ
              jimp Rebel Alliance Developer Netgate
              last edited by

              ntp binds to any (or the interfaces you select in the GUI). No need for NAT in most cases unless you bind only to localhost.

              It will respond to anyone you allow to reach the NTP service. Proper firewall rules control access effectively.

              Personally, I haven't witnessed any such misbehaving NTP clients, but I've seen enough broken devices to know they probably exist somewhere I just haven't seen them myself.

              Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

              Need help fast? Netgate Global Support!

              Do not Chat/PM for help!

              1 Reply Last reply Reply Quote 0
              • K
                ky41083 Banned
                last edited by

                @kevin067:

                I see what the limited is for. But I should probably ask a few questions about it before a release is committed.

                When it is working, will ntp respond to "any" request passing through the interface on 123 regardless of dest ip and consume the packet?

                Or am I supposed to create a NAT to redirect them to localhost myself?

                Also since it seems your experiencing ntp storms. I have found that there are embedded devices on the market that pretend to ask for time on port 123. But go to a hard coded ip address of their choosing and use it for communications. So it is entirely possible to get a packet on port 123 and look like nonsense to your ntp server.

                The bad news if the rogue device is redirected to the local ntp server and the device is expecting a non-ntp response. It will start storming since the ntp server didn't act like the server it was expecting and will keep trying until it gets what it wants.

                Basically what jimp said, I will add my personal experience though since it pertains to your question….

                NTP will only respond to requests directed at an IP it is bound to.

                That being said, I have at least one crappy home wireless AP on my network that has a hard coded NTP server IP list. I use NAT to redirect the one public IP I set it to use for NTP, back into the LAN IP of pfSense, only on dest port 123, only from the source IP of the wireless AP. It works, and works well.

                This is the only case you should have to do any odd NAT redirects for NTP, unless you want to do a global port 123 redirect to your internal NTP server, and that really shouldn't be done for a multitude of reasons.

                Other than that, NTPd will handle all the NTP request denies / drops without effecting non-NTP port 123 traffic when throttling is enabled.

                1 Reply Last reply Reply Quote 0
                • T
                  Tikimotel
                  last edited by

                  Feb 8 14:10:33	ntpd[34622]: restrict ::: KOD does nothing without LIMITED.
                  Feb 8 14:10:33	ntpd[34622]: restrict 0.0.0.0: KOD does nothing without LIMITED.
                  

                  So should "kod" also be removed then?

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