Centralized Management Architecture for many remote office gateway connected via VPNs

[Luigi_Vezzoso1]

Hi,

I'm interested to know which are the experience of the CheckMates community on the correct configuration of an architecture with many (>40) remote offices connected via VPNs to a central HUB.

• What are the correct consideration in order to manage the gateway from the main HQ?
• what are the specific settings for this configuration?
  • open ports required?
  • object definition on the smartdashboard
  • should I define the remote object from the public IPS?
  • how should I establish the SIC?
  • etc.

In past I had some issue on this kind of configuration. Have you some experience to share?

Best Regards

Luigi

[G_W_Albrecht]

I do not see any difficult open questions here - it is a main field of CheckPoint in production to connect the companies main site to worldwide distributed remote sites using S2S VPN and nearly every customer i do know of uses that functionality. All is throughly documented, see CP_R80.10_SitetoSiteVPN_AdminGuide for details. As long as no 3rd Party GW is involved, configuration is straight-forward after some basic decisions have been made. In sk105119: Best Practices - VPN Performance you can find general performance guidelines for working with VPN.

Shortly on the question details: Using Domain based VPN is compulsory, and the open ports required are taken care of by CP implied rules; object definition in Dashboard is very easy, of course the public IP of the remote GW has to be the main address used (and part of the VPN domain). And yes, you shall establish SIC as suggested in the CP manuals and guides .

[Luigi_Vezzoso1]

so in case of management from the public IP Ithe security will be assured by the implied policy... yes, you are rigth!

Let me add other difficulties that I'have faced off... how about central management of remote sites gateway behind a NAT? (my issue were happened in this architecture....). Do just I need to open the required and well documented ports? I think thera issue also on the certificate enrollment....

tks for you contribution!

[Vladimir]

Management server should be statically NATed on the gateway at the same site, preferably to a unique public IP.

As Implied rules are taking care of access control for management traffic, this is pretty much all that is required.

[Luigi_Vezzoso1]

In order to permit traffic from the external gateway to the Management? Isn't that traffic going inside the VPN tunnels?

[Vladimir]

Management traffic secured by SIC and is expressly excluded from VPN.

There are other posts in CheckMates referring to this particular subject:

https://community.checkpoint.com/message/8752-re-managing-r8010-aws-vsec-from-on-prem-sms-via-existi... 

[Jeroen_Demets]

The biggest issues we are facing with central management are NAT issues. Make sure you always specify which gateway should do the NAT in case of automatic NAT config.

And very specifically, there is the case of NAT'ed Security Management Server (SMS formerly known as SmartCenter). Checkout sk66381 and Sk100583. I hope you won't need a management dummy object as this will always annoy you with a warning sign. 

In some setups we chose to disable CRL checking, not only for the NAT issue but because of the dependancy on the reachability of the SMS. I would prefer to be able to choose PSK's and not to be forced using certificates when going for centrally managed gateways.

[G_W_Albrecht]

Management Dummy objects should not be needed asnymore 😉 NAT-T for S2S VPN is supported in R80.10 but has to be enabled, see sk32664 Check Point Security Gateway initiating an IKE negotiation over NAT-T for details.

[Jeroen_Demets]

Günther, is your comment valid on the management server being NAT'd? That sk is about gateways behind NAT, not management servers (where the CA resides which contains the CRL).

Anyway, thanks for that sk. Check Point has many interesting ones but it's sometimes hard to find them.

[G_W_Albrecht]

>>> how about central management of remote sites gateway behind a NAT

that is no more an issue nowadays with NAT-T for S2S VPN supported in R80.10.