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

Changing IP of the Management server for AWS CloudGuard

I'm working on my presentation for CPX and have run into this: Security Management Server with CloudGuard for AWS 

In it, there is a recommendation to change the main IP of the Management Server:

In all other cases, the Security Management Server and Security Gateways will have to communicate with each other using public IP addresses. The object that represents the Management Server in the SmartConsole must have the public IP address as its main address. To set a public IP address as the Management Server's main address, follow these steps:

  1. Connect to the Management Server with SmartConsole.
  2. Select Gateways & Servers
  3. Double click on the object representing the Management Server. 
  4. Insert the Management Server's public IP address in the IP Address field.
  5. Publish changes.

Following this recommendation breaks logging of the existing gateways located on premises, at least in R80.10.

Is this something that R80.20 handling differently, or should there be a caveat mentioned that this is for new implementations only?

Additionally, there is a line there explicitly mentioning possibility of managing CLoudGuard gateways via their private IPs over VPN. This is something that was discussed in the past and it was not a recommended approach:

Communication over private IP addresses is possible in one of the following cases:

  • The Management Server is in the same VPC as the Security Gateways.
  • The Management Server is in another VPC that is peered with the VPC in which the Security Gateways are deployed.
  • The Management Server is in an on-premises network that has connectivity to the VPC in which the Security Gateways are deployed, over Direct Connect.
  • The Management Server is in an on-premises network that has connectivity to the VPC in which the Security Gateways are deployed, over a VPN connection.

Please advise if this too is now acceptable solution or if this too should carry warnings.

Thank you,

Vladimir

0 Kudos
3 Replies
Yonatan_Philip
Employee Alumnus
Employee Alumnus

Hello Vladimir,

Regarding the IP change, I believe that since that's written in the installation section, the assumption is that you will do this before adding gateways (otherwise, you'll have to manually renew SIC or risk automatic certificate renewal failing as well).

Can you explain why or where it was stated that the fourth option (private IP over VPN) is not recommended?

While I agree that this approach can be problematic in many use cases, I can think of a couple of use cases where this approach will make sense.

HTH

Yonatan

0 Kudos
Vladimir
Champion
Champion

Hi Yonatan.

Agree that the description of the IP change in the Installation section is some-what justifiable, but still think it is a good practice to caution against possible side effects if taken out of context.

I've been looking into the management over VPN some 1.5 year ago and this is the thread where Dameon states that it is not a recommended configuration:

https://community.checkpoint.com/thread/5710-managing-r8010-aws-vsec-from-on-prem-sms-via-existing-v... 

What I am also surprised at not seeing there is the Statically NATed SMS scenario. I've been using it in my lab environment on and off for a year and do not recall having issues with it.

0 Kudos
Yonatan_Philip
Employee Alumnus
Employee Alumnus

Hi Vladimir,

As I suspected it's all a matter of context.

In general, this isn't recommended when the GW is both managed by the private IP and is the terminus of the VPN tunnel, as you might have a problem if the VPN tunnel goes down (cutting off the branch you're sitting on...).

However, there are other use cases where the VPN is handled by either another gateway or by a 3rd party such as AWS VPN GW. In such use cases using the private IP to manage a gateway is a valid option.

I will admit that using the private IP will usually be a niche use cases, but it is none the less still a valid option that can help for non-standard deployments.

Regarding the NAT use case (assuming I understand the use case correctly), you're right, that too is a valid use case. Not sure why it wasn't mentioned.

HTH 

 Yonatan 

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events