Maintaining management of gateways over VPN as backup

[dt7]

Dear all,

My issue is somewhat related to previous topics I found on Checkmates but I am not very clear on some aspects if I were to apply it on my scenario detailed below.

https://community.checkpoint.com/t5/Management/Managing-a-gateway-over-VPN/td-p/13669#

https://community.checkpoint.com/t5/Management/Exclude-CPM-traffic-from-implied-rules/td-p/3934

https://community.checkpoint.com/t5/Management/Exclude-CPM-Traffic-from-Implied-Rules/m-p/9187

From what I understand, it is not recommended to allow management traffic of the gateways over VPN, it does not work by default (handled via the implied rule) but it is possible to modify this behavior via the implied_rules.def config file on SMS/CMA (if using MDS), as it is illustrated on the links above to allow SmartConsole access (CPM) or logs over VPN. The other alternative would be to use public IPs to as the management IP of the gateways for the remote site (i.e Cluster B in the scenario below).

The common scenario that I would like to address is as follows:

• I have two sites, Site A and Site B
• Site A contains the CMA + Cluster A (gateways)
• Site B contains Cluster B (gateways)
• Both clusters gateways (i.e including the remote site B) are managed via private IPs, for members and Cluster IPs.
• Between Site A and Site B I have two links, one Layer2 link (main line), and one Internet backup link with site-to-site VPN configured (using VTI)
• Automatic routing (OSPF) is in place between both sites, allowing failover of the traffic between the L2 link and the internet backup line automatically in case of an issue with the primary link.

The management of the Cluster B gateways works fine in normal operations, as the management traffic goes via the L2 link (not encrypted). The problem that I would like to address is when the main link (L2) is down and that the traffic switches to the internet backup link with site-to-site VPN configured. Data traffic still works fine with OSPF kicking in, but by default the management traffic is not allowed over VPN, so basically we lose management access of Cluster B completely when that happens. On top of losing the management, it also means that the VPN between Cluster A and Cluster B will go down after some time as Cluster B cannot access the management server when the VPN times out and needs to be re-established.

My questions would be:

1. What would be the best way to ensure that the management of Cluster B remains when using the backup link over VPN? If we are using private IPs as management IPs. If any?
2. Would it be possible to do that by modifying the implied_rules.def config file on the CMA? But does it means we have to comment all of the necessary processes that communicate between CMA and the gateways so that they are not part of the implied rules? I.e all the ones shown in the attached picture? On top of that, making the necessary FW rules to allow that traffic.
3. If you want to push this further, you might want to have actually two site-to-site VPNs configured on both links (including the L2 line) to encrypt all the traffic, but in that case without a way to manage gateways over VPN how is it even possible to do so and still have management access of Cluster B?

Sorry for the long post, but I can't find a proper way at the moment of addressing this scenario so any advice or help would be much appreciated, thank you!

[PhoneBoy]

It is possible to do SIC over VPN, which has some caveats.
The following two community threads might help:

• https://community.checkpoint.com/t5/Management/Exclude-CPM-traffic-from-implied-rules/td-p/3934
• https://community.checkpoint.com/t5/Management/Exclude-CPM-Traffic-from-Implied-Rules/m-p/9187#M1452 
•  

[dt7]

@PhoneBoyThanks, I saw those community threads previously (one of them is linked in my post also), but they address only CPM traffic (to connect via SmartConsole) and logs. We need to add other ports in the implied_rules.def to manage the gateways no?

[Bob_Zimmerman]

---

@dt7 wrote:

...

On top of losing the management, it also means that the VPN between Cluster A and Cluster B will go down after some time as Cluster B cannot access the management server when the VPN times out and needs to be re-established.

---

This brings up the real issue. VPNs between Check Point firewalls managed by the same management server rely on certificates for authentication. The certificate authority is on the management server. When a firewall tries to bring up a VPN with another firewall and it gets a certificate from the other firewall, it tries to verify the CRL. If it can't, it won't pass authentication. If the firewall and its management should talk over the VPN, this leads to a cyclic dependency. You have to fetch the CRL to negotiate the VPN, but the VPN has to be working to fetch the CRL.

While it's technically possible to accomplish this goal with manual modifications to various .def files, modifying .def files on the management gives me hives. Management upgrades are relatively rare, so it's really easy to forget about the modified files, and upgrades wipe out the modifications. This leads to a distressingly high chance of unpleasant foot/gun interactions which I would rather avoid.

[JozkoMrkvicka]

Regarding CRL mechanism you mentioned, it is very important to make sure the gateways are able to fetch CRLs (by default every 24 hours) in case there will be VPN with another gateway managed from the same CMA/management:

VPNs go down within 24 hours after the primary Security Management server goes down

Just a side note about upgrades of management - if using latest version of upgrade tools, the PUV will inform you in case some important .def files were modified, which will be replaced by new version.

[dt7]

Indeed it is cyclic dependency..

Would there be any other better way to handle redundancy in this scenario then? Does it mean there is no choice other than managing the remote gateways (Cluster B) via their Public IPs and without VPN? But if you have two ISPs with two different ranges how to manage that also on your cluster?

It's a pretty common scenario to have a remote site (with firewalls) and two links in between (main and backup) with a dynamic way to switch the traffic between the two links if one fails, so I am a bit  puzzled that there isn't a more straightforward or recommended way to set this up via Checkpoint while still having the remote gateways under management.