NTP sync failing after PAN-OS 7.0 upgrade

[jsafranek]

I upgraded Panorama to 7.0 and then 7.0.1 recently and it seems to have broken my ntp synchronization in Panorama. Now I get "NTP sync to server x.x.x.x failed, authentication type none". If I run a "show ntp":

NTP state:

    NTP not synched, using local clock

    NTP server: x.x.x.x

        status: rejected

        reachable: no

        authentication-type: none

The NTP server is reachable (on same subnet) and is functioning for all other systems that use it. If I change the ntp server in Panorama to the host name or even another ntp server and commit, the GUI system monitor shows it syncs, but the next time it tries it fails. When using 0.pool.ntp.org I get the same thing happening. I've manually changed the system time to a few minutes off and then committed with a different ntp server (either internal or public) and it does sync, but will never sync after that first time.

2015/07/31 15:38:41 NTP time learnt; New time is: Fri Jul 31 11:17:31 PDT 2015'

2015/07/31 15:38:41 NTP restart synchronization performed

2015/07/31 15:53:42 NTP sync to server x.x.x.x failed, authentication type none

admin@Panorama> tail mp-log dagger.log

2015-07-31 15:35:26.034 -0700 OPCMD: handler "ntp_state"

2015-07-31 15:35:26.484 -0700 OPCMD: handler "ntp_state"

2015-07-31 15:35:26.943 -0700 OPCMD: handler "ntp_state"

2015-07-31 15:35:27.404 -0700 OPCMD: handler "ntp_state"

2015-07-31 15:35:27.854 -0700 OPCMD: handler "ntp_state"

2015-07-31 15:35:28.274 -0700 OPCMD: handler "ntp_state"

2015-07-31 15:35:28.713 -0700 OPCMD: handler "ntp_state"

2015-07-31 15:35:29.184 -0700 OPCMD: handler "ntp_state"

2015-07-31 15:38:52.805 -0700 OPCMD: handler "ntp_state"

2015-07-31 15:38:57.065 -0700 OPCMD: handler "ntp_state"

[pulukas]

From your testing plan, it would appear to me you have discovered a bug.

Your best bet is to report this via a ticket to support with the link in the upper right corner.  They can determine if this is known or not already and get you a hot fix even before the official release when it is available.

[BenjAudy.MTL]

I also have NTP synchronization problems since version 7.0.0 and reported it to PAN.

Benjamin

[Anon1]

I have also ntp sync problems after update to 6.1.6

In the tech support tgz you can find in the /var/log/messages file that there is a hardcoded wrong ntp server name (after the two configured by the admin) which is causing the ntpdate process to exit:

Aug 13 14:55:10 CMS ntpdate[24425]: Can't find host 0.%{vendorzone}pool.ntp.org: Name or service not known (-2)

Aug 13 14:55:10 CMS ntpdate[24425]: no servers can be used, exiting

I assume this is the root cause. I have opened a ticket with these findings.

[pivvre]

Same happend to us after updating from 6.0.x to 7.0.3 yesterday....

[kiwi]

 Hi,

I've seen reports of the same which from the looks of it has a fix scheduled to be released with PAN-OS 6.1.9 and 7.0.4.

I would recommend opening a support case so the TAC team can confirm if you are hitting the exact same thing.

regards,

-Kim.

[Dulle]

From PAN Support:

According to collected information you're hitting bug 85285, scheduled for release in 7.0.4 (second half of December) and 6.1.9 (first half of January). If you add second ntp server the issue should go away (it is more of a display issue).

And it works fine to add a secondary NTP server. Both are now OK:

ken.guru@Panorama(primary-active)> show ntp

NTP state:
NTP synched to 192.168.25.1
NTP server: 192.168.25.1
status: synched
reachable: yes
authentication-type: none
NTP server: 192.168.25.2
status: available
reachable: yes
authentication-type: none

[MMCiobanu]

We are running on 7.0.9, have a secondary NTP server and the sync still fails:

NTP state:
NTP not synched, using local clock
NTP server: x.x.x.x
status: rejected
reachable: yes
authentication-type: none
NTP server: y.y.y.y
status: rejected
reachable: yes
authentication-type: none

[RFalconer]

If you remove the secondary, does the primary sync?

I saw this issue when the NTP servers were providing slightly different times back to the PA. If they are different, NTP will fail.

[BPry]

as @RFalconer stated removing one of your NTP servers will likely cure what you are seeing. This bug shouldn't be an issue any longer; but if your NTP servers are reporting seperate times then you will get an NTP sync error.