Maestro limitation ? connections going through data and management interface

[Wolfgang]

CheckMates,

I need some clarifications regarding traffic coming in from management interfaces and going out through data interfaces and vice versa. This is a use case if you have your management in a separate subnet and connected via the management interfaces.

Known Limitations for Scalable Platforms (Maestro Appliances and Chassis) 

lists SPC-1104 "Connections that arrive via the data interface and are sent out via the management interface are not supported." 

and SPC-1111  "Connections that arrive via the management interface and sent out via the data interface are not supported"

This is a limitation since R76SP.50.  Scalable Platform R76 is not something like the newest releases 😉 I want to know wether or not these limitations are still exists with Maestro. 

Wolfgang

[Danny · Accepted solution]

This limitation still exists in R81 and R81.10.

Workaround: Use a dedicated uplink interface as management interface. Leave type:uplink on your MHO and configure it as management interface within the security group.

[Wolfgang]

Yes @Danny , this will be our workaround but with not using separate management interface you loose the ability to do none disruptive upgrades.

I think this limitation and follow from them the needed design should be more highlighted in the documentation.

[Danny]

Please elaborate further about how using a dedicated data port (uplink port) as management port causes disruptions during upgrades.

[Wolfgang]

Last year we run into a problem with LACP on the data interfaces... This knowledebase article was the result:

During an upgrade of a Quantum Maestro Security Group from R80.20SP/R80.30SP to R81.10, the "sp_upgr... 

The two releases are using different implementation of the LACP driver. Switching bond to backup/active on the old reelase solves the problem but our the first upgrade results in a disaster.

[Danny]

I see. I never had a security group running on R80.20SP, only R81 as currently recommended. So I didn't run yet into any upgrade issues.

[Computacenter_A]

Dear Danny,

Till now, I don't have used that kind of workaround, but I need it in a few days.

Can you please, give me a more detailed instruction, how to configure that workaround.

Best regards,

Christian

[Timothy_Hall]

Read sk179005.

To enable on the fly for testing: g_fw -a ctl set int fwha_data_mgmt_connection 1

To enable and make permanent: g_fw -a ctl set -f int fwha_data_mgmt_connection 1

[Chris_Atkinson]

Pardon my own curiosity here but how commonly do you see the Firewall as the "default gateway" for it's own management network versus an SVI on a switch etc? 

[Wolfgang]

@Chris_Atkinson in our none Maestro environments this is a common solution, having the firewall management systems in a small subnet attached to a gateway and the gateway is the default way out to the other networks. For security reason no other way to these subnet exist without the gateway. 

[_Val_]

Hmmm, so if GW has a "bad policy", how do you control it then? Plug yourself on the same network where MGMT sits?

[Danny · Accepted solution]

A "bad policy" in the means of not being able to access neither management nor gateway almost never happens when admins follow Check Point's Firewall Policy Management Best Practices (sk102812) and create leading firewall management rules that are followed by a stealth rule in order to secure the firewall infrastructure.

"A stealth rule is a rule that should be located as early in your policy as possible, typically immediately after any Management rules. The purpose of this is to drop any traffic destined for the Firewall that is not otherwise explicitly allowed."

The firewall management section remains almost untouched at the top of the rulebase so admin access to the firewall infrastructure is granted even in "bad policy" situations. If something goes wrong so badly that access to the management and gateway is lost at the same time, then of course it's time to plug in to the network to fix it (only required if access to LOM interfaces and serial console interfaces is lost as well).

Therefore also we secure all our customers' firewall environments (Regular, VSX and Maestro) by segmenting the security management directly on the primary firewall gateways via the management interface. This way the firewall gateways are able to control and secure all connections to their SIC-trusted leader, the security management. This always worked well for us and our customers throughout all the 25+ years of using Check Point.

Zero trust, that is.

[_Val_]

I understand Zero Trust, and I do agree, MGMT should be behind a firewall. I respectfully disagree with a concept when the only access to your management tools is via FW managed by that same server. That can work for you for decades, but it does not mean this practice is absolutely the best. 

If that primary FW is dead, what's your next step? 

[Danny]

Find and fix the issue, as always. I don't expect to reach a firewall's management if the firewall cannot be reached. As most firewalls are clustered this issue is not very likely.

[_Val_]

You are missing my point.

Do you intend to run all maintenance operations from the data center? if not, by mistake, or as a result of a technical failure, with your only FW and management depending on each other, you can be cut off. To overcome that cut, without any means of out of band access, you will have to go to that dusty noisy room every time something breaks 🙂

[Danny]

If a firewall has a failure I don't want ANYONE to be able to reach it's firewall management without physical access > Zero trust. And yes, in such situations a visit to the server room will be likely. Anyways, I didn't experience these situations to happen so often. 😀

[Wolfgang]

I'm agree with @Danny .  In the last 20 years we had only one case that the firewall-management was not available as follow up of a firewall crash. And yes, you have to go onsite or maybee use other ways to connect to your management. But this is no problem and always better then lowering security.

I think this is a limitation of Maestro and there should be a solution and not finding reasons to change a common design of the security solution.

[Andreas_Zentsch]

I am also very dissapointed to the current MGMT solution. Regarding your workaround. I would set the existing MHO interface 1/1/1 from management to uplink. Would that lead to any problems? In would expect it should work right away. 

[Timothy_Hall]

This is still a limitation in Maestro R81 however Maestro R81.10 has a hidden feature recently documented that can be enabled to make this work, but it is disabled by default.  It is expected that this new feature will be enabled by default in R81.20, and this type of traffic will become officially supported.  See here: sk179005: "Connections from Data Interface to the Management Interfaces (and Vice Versa)" feature