Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Wolfgang
Authority
Authority
Jump to solution

Maestro limitation ? connections going through data and management interface

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

 

2 Solutions

Accepted Solutions
Danny
Champion Champion
Champion

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.

View solution in original post

Danny
Champion Champion
Champion

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.

View solution in original post

18 Replies
Danny
Champion Champion
Champion

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
Authority
Authority

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
Champion Champion
Champion

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

0 Kudos
Wolfgang
Authority
Authority

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.

0 Kudos
Danny
Champion Champion
Champion

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.

0 Kudos
Computacenter_A
Explorer

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

0 Kudos
Timothy_Hall
Legend Legend
Legend

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

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Chris_Atkinson
Employee Employee
Employee

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? 

CCSM R77/R80/ELITE
0 Kudos
Wolfgang
Authority
Authority

@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_
Admin
Admin

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

0 Kudos
Danny
Champion Champion
Champion

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_
Admin
Admin

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? 

0 Kudos
Danny
Champion Champion
Champion

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.

0 Kudos
_Val_
Admin
Admin

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 🙂

0 Kudos
Danny
Champion Champion
Champion

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
Authority
Authority

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
Contributor
Contributor

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. 

0 Kudos
(1)
Timothy_Hall
Legend Legend
Legend

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

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

 
Upcoming Maestro Events