topic Re: NTP setup - possible issues in Firewall and Security Management

NTP setup - possible issues

Jacob_W — Fri, 29 Jan 2021 09:47:01 GMT

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

Re: NTP setup - possible issues

Chris_Atkinson — Fri, 29 Jan 2021 14:23:28 GMT

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?

Re: NTP setup - possible issues

Jacob_W — Fri, 29 Jan 2021 15:09:36 GMT

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 ?

Re: NTP setup - possible issues

Alex- — Fri, 29 Jan 2021 16:21:14 GMT

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.

Re: NTP setup - possible issues

PhoneBoy — Sat, 30 Jan 2021 06:25:37 GMT

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.

Re: NTP setup - possible issues

Jacob_W — Wed, 03 Feb 2021 10:33:05 GMT

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

Re: NTP setup - possible issues

Jacob_W — Mon, 08 Feb 2021 06:11:06 GMT

Anyone has any idea on above?

Re: NTP setup - possible issues

MartinTzvetanov — Mon, 08 Feb 2021 09:01:13 GMT

create a static route for this traffic

Re: NTP setup - possible issues

Jacob_W — Mon, 08 Feb 2021 09:04:51 GMT

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.

Re: NTP setup - possible issues

MartinTzvetanov — Mon, 08 Feb 2021 09:10:56 GMT

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

Re: NTP setup - possible issues

Jacob_W — Mon, 08 Feb 2021 09:14:34 GMT

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.

Re: NTP setup - possible issues

MartinTzvetanov — Mon, 08 Feb 2021 09:14:30 GMT

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

Re: NTP setup - possible issues

Jacob_W — Mon, 08 Feb 2021 09:23:03 GMT

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.

Re: NTP setup - possible issues

MartinTzvetanov — Mon, 08 Feb 2021 10:12:02 GMT

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?

Re: NTP setup - possible issues

Jacob_W — Mon, 08 Feb 2021 10:16:48 GMT

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.

Re: NTP setup - possible issues

MartinTzvetanov — Mon, 08 Feb 2021 11:37:14 GMT

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

Re: NTP setup - possible issues

Jacob_W — Mon, 08 Feb 2021 12:02:42 GMT

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!

Re: NTP setup - possible issues

MartinTzvetanov — Mon, 08 Feb 2021 12:17:13 GMT

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