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

    OpenNTPD timing out when performing queries

    Scheduled Pinned Locked Moved pfSense Packages
    4 Posts 2 Posters 3.1k 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.
    • D
      deepdish
      last edited by

      Hello,

      I am having a very annoying issue trying to get OpenNTPD working on my pfSense box. Essentially I want pfsense to act as an NTP server for my local LAN.

      • OpenNTPD is enabled on the LAN and loopback interfaces of pfSense
        – As a precaution, I have also allowed a rule to the firewall itself on udp port 123 from the LAN

      • pfSense itself is configured as an NTP client to ntp.pool.org , and is synchronized as well.

      • Any query to ntpd on the pfsense box results in the output below:

      ntpq -p 10.119.97.61
      10.119.97.61: timed out, nothing received
      ***Request timed out

      • When attempting to perform queries from the pfsense box itself is doing the same thing:

      [2.0.1-RELEASE][root@pfsense]/root(23): ntpdc
      ntpdc> peers
      localhost: timed out, nothing received
      ***Request timed out
      ntpdc> monlist
      localhost: timed out, nothing received
      ***Request timed out
      ntpdc> sysinfo
      localhost: timed out, nothing received
      ***Request timed out
      ntpdc> sysstats
      localhost: timed out, nothing received
      ***Request timed out
      ntpdc> exit
      [2.0.1-RELEASE][root@pfsense]/root(24):

      • I am seeing that ntpd is listening on port 123 udp on loopback on the LAN IP:

      udp4      0      0 127.0.0.1.123          .                   
      udp4      0      0 10.119.97.61.123      .

      • At this moment, I'm stuck. I have been playing around with this for a week and I am not getting anywhere. I would leave the daemon on overnight or for a few days with no improvements.

      Am I overlooking something on my configuration?

      pfSense version I'm running is:

      2.0.1-RELEASE (amd64)
      built on Mon Dec 12 18:43:51 EST 2011
      FreeBSD 8.1-RELEASE-p6

      1 Reply Last reply Reply Quote 0
      • D
        deepdish
        last edited by

        To further add to my frustration, there does not appear to be any helpful logs that would assist me further.

        1 Reply Last reply Reply Quote 0
        • B
          biggsy
          last edited by

          I was curious about this, having tried ntpq myself with the same timeout.

          I did some searching and found this thread http://www.monkey.org/openbsd/archive/misc/0408/msg00448.html

          It seems, from the first few responses in the very long thread, that openntpd doesn't respond to ntpq and probably never will.

          Do you know/suspect your LAN clients aren't sync'ing to pfSense?

          1 Reply Last reply Reply Quote 0
          • D
            deepdish
            last edited by

            @biggsy:

            I was curious about this, having tried ntpq myself with the same timeout.

            I did some searching and found this thread http://www.monkey.org/openbsd/archive/misc/0408/msg00448.html

            It seems, from the first few responses in the very long thread, that openntpd doesn't respond to ntpq and probably never will.

            Do you know/suspect your LAN clients aren't sync'ing to pfSense?

            I expected " ntpq -p " to work, but never bothered to use anything else to check if the ntp server is working.

            I just performed ntpdate on one of my computers and got some positive feedback:

            ntpdate 10.119.97.61
            29 Jan 11:38:06 ntpdate[15951]: adjust time server 10.119.97.61 offset -0.004357 sec
            

            I guess this thread can be closed. Would be nice to see what servers the pfSense box is sync'ed to, but I suppose this would suffice.
            Thanks for having me .. think outside the box :)

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