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

R80.30 Management Interface default gateway

Hi, everyone.

Let me preface by saying that I just started working with Checkpoint Firewalls. I mostly worked on Palo Altos and ASAs previously. 

I'm very confused about the security gateway management interface. How do I change the default gateway for the management interface? I can't see an option to change it? All I can see is IP and the mask option. What am I missing here?

I also need to change the gateway for the Checkpoint management server as well. 

Thanks in advance. 

 

0 Kudos
1 Solution

Accepted Solutions
_Val_
Admin
Admin

Lol, a colleague of mine had a similar confusion when moving from Check Point (two words) to PAN. PAN uses two separate pieces of hardware in the same box, one for control connections (management interface) and one for filtering production traffic. 

With Check Point security gateways, there is no separate routing for the management interface. Although it is called MGMT on most of the appliances, it is a part of the main connectivity framework, meaning it can receive and forward any production traffic crossing the FW, not just management connections for the gateways and back.

So if you change the default GW, it applies to all interfaces, including your management interface, if you are working with Check Point


View solution in original post

(1)
8 Replies
_Val_
Admin
Admin

Lol, a colleague of mine had a similar confusion when moving from Check Point (two words) to PAN. PAN uses two separate pieces of hardware in the same box, one for control connections (management interface) and one for filtering production traffic. 

With Check Point security gateways, there is no separate routing for the management interface. Although it is called MGMT on most of the appliances, it is a part of the main connectivity framework, meaning it can receive and forward any production traffic crossing the FW, not just management connections for the gateways and back.

So if you change the default GW, it applies to all interfaces, including your management interface, if you are working with Check Point


(1)
vsurresh
Contributor

Thanks for the response.

If I understand correctly, let's say I assigned 10.10.10.10/24 to the MGMT interface and 192.168.1.10/24 to eth1/2 interface. Let's assume I also have a static route of 0.0.0.0/0 with the next hop of 192.168.1.1. So, If I connect to the security gateway from a subnet other than 10.10.10.0/24 then the traffic will leave the security gateway via eth1/2 interface right?

With Palo, I can assign 10.10.10.10/24 to the MGMT interface (management plane) and set the default gateway to 10.10.10.1. At the same time, I can have a 0.0.0.0/0 (data plane) pointing to a different interface/next hop. So, all the management traffic will ingress and egress via the MGMT only. 

Is there a reason why Check Point doesn't have a management plane separation?  

Regards

Suresh

0 Kudos
_Val_
Admin
Admin

Yes, your assumption about routing is correct is correct. The reason why is mostly related to the origin of the company tech. You can read this article for starters.

Technically, you can have multiple options for management plane separation with Check Point today, but it overcomplicate things, actually.

Imagine you have your management network routed through a security GW. With Palo, you have to define it twice: once on mgmt interface and another time on data plane, and also connect two cables leading to the same network two times to the same appliance. With Check Point you do not have that complexity. 

Once again, the reason PAN has data plane separate is in their HW structure. With Check Point, the same code runs on open server and CP appliance.


vsurresh
Contributor

Thanks for the explanation, it started to make sense now.

0 Kudos
Bob_Zimmerman
Authority
Authority

Check Point does offer the ability to separate management and data forwarding. The main option for this is called VSX. It's just VRFs (implemented using Linux network namespaces on R80.40 and later), which are multiple routing tables (called FIBs) under one OS. Last time I checked, every firewall license includes the ability to run one additional VS specifically for this reason. When set up this way, VS 0 handles to-traffic, while the additional VS (commonly VS 1, but might be VS 2 or more if you add some switch contexts first) handles through-traffic.

Bob_Zimmerman
Authority
Authority

Ehhhh ... most Palo Alto boxes don't actually have physically separate management plane and data plane. Their data plane has something a bit like an old Nokia ADP card, but the software part of data forwarding runs on specific cores on the same CPU as management. You can get a similar result with Check Point by limiting the number of load-bearing CoreXL instances and pinning them to certain cores with process affinity. As far as I can tell, PAN does their forwarding with UML, as opposed to multi-kernel like CoreXL, but it's definitely not on physically separate hardware on anything but their blade frames. If the OS wedges, you lose both data forwarding and management.

_Val_
Admin
Admin

>>>Their data plane has something a bit like an old Nokia ADP card, but the software part of data forwarding runs on specific cores on the same CPU as management

That's not exactly 100% accurate, but you are close to what I said. Your ADP card analogy is what I imply - separate from the main computation unit piece of HW dedicated to traffic filtering.

0 Kudos
Bob_Zimmerman
Authority
Authority

Sure, but it can't continue filtering and forwarding traffic in isolation for more than a few seconds. It has to interact with processes running on the main CPU. My point is mostly that if the OS running the "management plane" hangs, you lose both management and traffic forwarding. If you lose a stick of RAM, you lose both management and traffic forwarding. It's not like it computes a new FPGA LUT for each rule change.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events