Create a Post
Showing results for 
Search instead for 
Did you mean: 

NTP clock sync not working on cloudguard R80.10 HA

Hi All...

I have successfully deployed Checkpoint cloudguard HA cluster running R80.10 using Check Point CloudGuard IaaS High Availability for Microsoft Azure R80.10 and above Deployment Guide ..

Internet ---- eth0 ( 21)/28) FW1 eth1 ( 38)/28) -------Inside (towards on-premise NTP server)

As per the template the FW is deployed wth a backend loadbalancer with an IP of No frontend-lb has been deployed

My NTP server sits on-premise network with IP address of

I have added the route for NTP server on the firewall pointing towards (first IP on the inside eth1 subnet)

However I see a strange behaviour where the initial NTP packet is sourced from the backend-lb IP address ( towards NTP server which then replies back to the FW1 IP address (.37) followed by an ICMP unreachable sourced from backend-lb to the NTP server

As soon as I remove the route via eth1 interface (forcing traffic to go out via default route on eth0 interface) I can see bi-directional comms between the FW eth0 interface and the NTP server

15:00:13.292177 IP > NTPv3, Client, length 48
15:00:13.317949 IP > NTPv3, Server, length 48

However even with this bi-directional comms, the output of show ntp current displays

No server has yet to be synchronized

I have attached wireshark captures from both eth0 and eth1 interface

The end goal here is to get NTP (and all other comms to on-premise network) working via the inside interface

Any ideas ?

6 Replies

Have you configured the necessary UDRs in Azure?

0 Kudos

The UDR has been setup correctly to use the eth1 interface.. I got the traffic flow issue resolved by changing the eth1 to be just a Syn interface and eth0 to be the cluster interface with cluster ip set to virtual-ip on eth0 interface .. So we now see two-way traffic between gateway and the NTP server

However the clock still wouldn't sync as the offset and jitter are too high..

Here is the output from the firewall

[Expert@fw1:0]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================      3 u   41   64  377   18.479  -224130 6225.18     2 u   48   64  377   25.672  -223593 4348.23

ntpq> associations

ind assID status  conf reach auth condition  last_event cnt
  1 14834  9024   yes   yes  none    reject   reachable  2
  2 14835  9024   yes   yes  none    reject   reachable  2

ntpq> rv 14834
assID=14834 status=9024 reach, conf, 2 events, event_reach,
srcadr=, srcport=123, dstadr=, dstport=123,
leap=00, stratum=3, precision=-23, rootdelay=10.849,
rootdispersion=6.653, refid=, reach=377, unreach=0, hmode=3,
pmode=4, hpoll=6, ppoll=6, flash=400 peer_dist, keyid=0, ttl=0,
offset=-2241300.599, delay=18.479, dispersion=4.444, jitter=4674.461,
reftime=e00fa28e.f5e2a217  Thu, Feb 14 2019  8:17:18.960,
org=e00fa2a3.f188753b  Thu, Feb 14 2019  8:17:39.943,
rec=e00fab6d.355bf748  Thu, Feb 14 2019  8:55:09.208,
xmt=e00fab6d.304cedeb  Thu, Feb 14 2019  8:55:09.188,
filtdelay=    19.71   20.36   19.22   19.35   18.48   18.71   18.72   18.90,
filtoffset= -224925 -224710 -224477 -224295 -224130 -223959 -223786 -223615,
filtdisp=      0.00    0.98    1.97    2.96    3.90    4.89    5.85    6.84

Spoken to TAC and they reckon we need Hotfix for this as per sk105862 but I am not sure as I expect the clocks to sync initially and then drift but in my case its not syncing at all to start with

0 Kudos

What happens if you use the command ntpdate first to sync the clocks?

This should do a one-time sync of the clocks regardless of the drift involved.

0 Kudos

ntpdate does the trick but the clocks then start drifting shortly

0 Kudos

Maybe add a cronjob that periodically calls ntpdate?

TAC would have to get involved to troubleshoot ntp not syncing properly.

0 Kudos

Indeed TAC did get involved and provided a Hotfix as we were hitting the bug outlined in sk105862…once applied the clocks are syncing OK now with NTP server



Epsum factorial non deposit quid pro quo hic escorol.