Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 2 subscribers
  • Views 5704 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

NTP synchronization off time in virtual UTM appliance

ErikWaibel
I am running UTM 9.103-5 in vmware vsphere 5.  The UTM has drifted to 1 minute off of the assigned NTP pool servers (according to the "Test Configured Servers" button on the Time and Date page under System Settings).  When I attempt to force a manual synchronization from the console using the ntpdate -v (ntp pool server) command I get several lines of messages that state "ntpdate[31587]: sendto(ntp server name or address) : Operation not permitted

When I see this on standard linux servers, it usually means a firewall is blocking NTP (UDP port 123), but I have it allowed for my network and it appears that the UTM CAN talk to my configured NTP pool servers because in the WebAdmin GUI it passes the test (as noted above) to report that it is 1 minute off.

Is there a different method to manually force an NTP update?  I am stopping the ntp daemon before running the ntpdate command (by using /var/mdw/scripts/ntp stop).


This thread was automatically locked due to age.
  • 0
    Time drift isn't a problem anyone else reports, and I haven't seen it in any of my client sites.  Anytime I've tested it's been milliseconds, and usually /var/mdw/scripts/ntp status show running?

    Have you tried toggling NTP off/on in 'Network Services'?

    I wonder if this isn't related to some vmware setting.

    Cheers - Bob
  • 0 in reply to BAlfson
    You don't have to write firewall rules for astaro daemons to work correctly. Webadmin does it automatically by opening or closing the ports that are needed.

    Post the output of ntpq -pn. Here is a sample from my astaro 
    gatekeeper:/var/log # ntpq -pn

         remote           refid      st t when poll reach   delay   offset  jitter

    ==============================================================================

     127.127.1.0     .LOCL.          10 l   4d  128    0    0.000    0.000   0.000

    *129.7.1.66      .GPS.            1 u  120  128  377   42.502    4.169   5.982

    +128.252.19.1    .GPS.            1 u   65  128  377   83.917   -9.562   6.519
  • 0 in reply to BAlfson
    Time drift isn't a problem anyone else reports, and I haven't seen it in any of my client sites.  Anytime I've tested it's been milliseconds, and usually /var/mdw/scripts/ntp status show running?

    Have you tried toggling NTP off/on in 'Network Services'?

    I wonder if this isn't related to some vmware setting.

    Cheers - Bob


    Thanks for the reply.  My HOME UTM (physical running on an ATOM box) is fine showing millisecond offsets like I expect.   The Enterprise one I am running here at the school district is showing 1 minute offsets to the three servers I am pointing it at, which has me baffled.  The NTP daemon is running (I have toggled it off/on several times to attempt to force a synchronization).

    I also tried your suggestion of trying to toggle it off/on in Network services - no change.

    It could be because it is on a VM, I suppose, but it has worked flawlessly in the past.  I am pointing it at the three servers [0,1,2].VMare.pool.ntp.org  which I also have the VM hosts pointing to.

    What is really got me baffled is the "Operation not permitted" message I get from ntpdate when I try to manually force a a synchronization from the command line console.
  • 0
    Billybob, here is the output from ntpq -pn:

  • 0 in reply to ErikWaibel
    Everything seems ok other than the time drift ... I guess you restarted the daemon again causing low reach numbers but thats fine too. 
    You have to stop the ntp daemon for ntpdate to work
    /var/mdw/scripts/ntp stop
    ntpdate 199.102.46.72 (or whatever ntp server you have defined in webadmin)
    /var/mdw/scripts/ntp start
  • 0
    Thanks for the helpful replies.  The weekend gave me a chance to reboot it and now it is synched up just fine with