NTP setup - possible issues

[Jacob_W]

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 

[Chris_Atkinson]

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?

[Jacob_W]

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 ?

[Alex-]

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.

[PhoneBoy]

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]

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 

[Jacob_W]

Anyone has any idea on above?

[MartinTzvetanov]

create a static route for this traffic

[Jacob_W]

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.  

[MartinTzvetanov]

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

[Jacob_W]

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.

[MartinTzvetanov]

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

[Jacob_W]

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.

[MartinTzvetanov]

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]

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. 

[MartinTzvetanov]

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

[Jacob_W]

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!

[MartinTzvetanov]

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