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

NTP setup - possible issues

Hi,

As we're not using NTP servers for our security GWs, we're experiencing some problems with logs synchronizations, etc. due to clocks mismatch.

I'm planning to setup up all the GWs and mgmt server to use corporate NTP servers. 

My question is what issues might pop-up? Differences between clocks on specific GWs are even few hours. 

Does the NTP configuration imply GW reboot? 

Thanks 

0 Kudos
17 Replies
Chris_Atkinson
Employee Employee
Employee

Make sure you have the correct timezones set prior, no reboot should be necessary.

Lack of time sync can cause issues with Logging, certificates and VPNs.

Are all the affected systems physical appliances?

CCSM R77/R80/ELITE
0 Kudos
Jacob_W
Contributor

Hi Chris,

Thanks for the answer. Yes, they are all physical boxes located in two different timezones.

Is the GAIA GUI right place for that setup or should I go with CLI ?

 

0 Kudos
Alex-
Leader Leader
Leader

Both are valid and actually the same thing, if you configure the NTP servers in CLISH they will appear in the web UI and vice-versa.

Just make sure you type "save config" if you do it in CLISH, in the UI it's done automatically.

0 Kudos
PhoneBoy
Admin
Admin

Before setting the NTP servers, make sure the time and date is correct.
NTP will only correct for clock drift, not massive changes (more than a few minutes) in the clock.
You may want to use the ntpdate command from expert mode to do this one time.

Jacob_W
Contributor

So it went smooth for all GWs, but one that is connected back to location where NTP sits via s2s VPN.

Issue is that when sending NTP request it uses mgmt interface which has public IP and the checkpoint on the other side of VPN tunnel drops traffic.

Is there a way to change source interface for NTP service traffic ?

Thanks,

Kuba 

0 Kudos
Jacob_W
Contributor

Anyone has any idea on above?

0 Kudos
MartinTzvetanov
Advisor

create a static route for this traffic

0 Kudos
Jacob_W
Contributor

Static route won't help here as there's only one outside interface and it's the one with public IP. Default route is s2s VPN.

Traffic must be originated from LAN interface to be properly classified on the other end of tunnel.  

0 Kudos
MartinTzvetanov
Advisor

so your ntp traffic goes in clear and the other site drops it?

0 Kudos
Jacob_W
Contributor

Yes, it's getting dropped as the source IP (mgmt interface) is not a part of encryption domain of that VPN.

That's why I'm looking on hot to pick up other interface as source for NTP traffic. This would be the easiest and best option.

0 Kudos
MartinTzvetanov
Advisor

add it to the enc domain or do an exclusion for this traffic in the vpn community

0 Kudos
Jacob_W
Contributor

Adding to encryption domain might be the solution/workaround here.

Exclusion would also require change in implied rules, right ?

I was just wondering if Checkpoint has functionality like service routes in Palo Alto firewalls - this would be the easiest way here.

0 Kudos
MartinTzvetanov
Advisor

exclusion is done in the vpn community, there is a tab service exclusion. There you add ntp and this traffic goes by this community without being enc/decr. Of course you must have a rule on both site to pass this traffic. This is not a change in implied rule. Sometimes I use this function for icmp to proof a customer that the devices has connectivity and the problem is somewhere in the encryption part 😁 .

I never heard of any kind of service route in CP but I believe policy based routing can do the same. In your case the enc/decr traffic goes thru mgmt interface, also the ntp goes thru the same mgmt interface, so routing the traffic to eth1 doesn't make sense, or I miss something in your environment?

Jacob_W
Contributor

Thanks a lot for explanation.

It's not about routing traffic via eth1, but sourcing traffic from it. They it could be encrypted/decrypted and would work fine.

ICMP traffic from that gateway is now hitting implied rule on other end of VPN tunnel and this is fine. 

I'll try both in some maintenance window - exclusion and adding mgmt int IP to enc domain. 

0 Kudos
MartinTzvetanov
Advisor

but the ntp traffic originates from the gw itself. It makes no sense to source it from eth1 and leaves via mng to be encrypted.

 

I see two solutions for you: 1) add your gw in the vpn community and ntp as an interesting traffic on both sites 2) exclude ntp in the vpn community

0 Kudos
Jacob_W
Contributor

In this specific use case it doesn't make sense, true.

But there are other use cases when it would be a benefit to source some, let's say service traffic, out from interfaces different than management. 

I'll proceed with solutions You provided. Thanks again!

 

0 Kudos
MartinTzvetanov
Advisor

It's a matter of routing. You can play with policy based routing to achieve something different than static/default routing. Also you must think of the surrounding devices so there won't be any assymetric traffic

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events