Let's talk about MDPS and why it sucks!

[melcu]

Hi Mates,

Why it sucks ? So let's see!

First of all it's not a real separation. It's kind of "understandable"  but let go deep:

Tunnel Interface - Planes are isolated and traffic cannot cross between them. The Tunnel interface (mdps_tun) allows only packets that originated from the local gateway to be sent to selected destination(s) through the Management plane, regardless of the plane where the connection was initiated.

This right here clearly violates the rule that "planes are isolated and traffic cannot cross between them". The result is asymetrical routing.

Another thing is that when you are using MDPS  the management interface is still visible in topology and massive anti-spoofing occurs. Disabling "extended cluster anti-spoofing" solves part of the problem.

Traffic originating from the management plane/interface with the interface's IP address  (with default route in core network) arrives from the core network to an interface in dplane. It gets recognized by the firewall as being it's own and it's dropped 🙂 It it's real isolated why is this happening ?

Workaround: just use a 3rd party router to NAT the ip address in order not to be recognized by mplane otherwise  the management of the firewall from the internal network (originating from dplane) is absolutely impossible.

So how the big question comes: is there a WAY to disable/remove the mdps_tun interface ? I wanted to implement mpds (as I was used and in love with the real separation that Palo Alto has) but I stumbled across multiple problems. Of traffic originates from a source in dplane (my local vlan - my laptop) I would never reach the management IP of the firewall.

So the big question is: am I thinking wrong trying to access my own firewall from my own internal network but via MDPS (which is isolated from the rest of the world)?

Otherwise mplane sitting by it's own is fine ... some TACACS+/LDAP/DNS problems but seems to be fine. Util you try to do something from behind dataplane :))))

[the_rock]

I only worked with 1 customer that is using mdps and had not encountered any of the issues you mentioned. I dont have nearly as much experience with it as you do, but that particular client seems to be okay with it.

Andy

[Bob_Zimmerman]

Just use VSX. All Check Point firewall licenses include the ability to run one VS. VSX is network namespaces, which is the same technology which underpins MDPS, but it has more configurability. VS 0 handles all management traffic and almost all traffic initiated by the system (some things like outgoing site-to-site VPN negotiations leave from the VS how you would expect).

There are four types of VS you can build: layer 2 with no firewalling (switch), layer 2 with firewalling (bridge-mode firewall), layer 3 with no firewalling (router), and layer 3 with firewalling (firewall). Switches don't consume a license slot, all the others do. Without buying VSX specifically, you have one license slot. You can get add-on licenses if you want which add more slots.

The big headaches with VSX are that it cares very deeply about interface names, and it doesn't play nicely with CoreXL. To deal with the interface names, just make bonds and tell VSX about only the bonds. Presto: you can now trivially move logical interfaces between your physical interfaces, since changing which interface backs a bond doesn't change the bond itself. The CoreXL limitation is bigger (the number of cores available to a VS is fixed, and changing it requires a hard outage for traffic), but if you only plan to run one VS, just hand it most of the cores when you build it.

The firewall kernel handling a VS only knows about the interfaces assigned to that VS. No more asymmetry. No more antispoofing problems.

[melcu]

Bob thanks, but it's nod my decision.

I'm trying just to understand why MDPS was created if it's so dumb. I know it's not a real separation but why the duck do we have a default route on mplane if some trafic goes on dplane. Why !? Why is the  mdps_tun interface not treated as it should be ? trafic originativ from mplane to dplane should be excluded from filter/inspection/spam/etc.

So basically I have to tell my client that if he decides to use MDPS  then the traffic to management should not originate from any interface from dplane. He's trying to to that right now. He's computer sits on ethX in dplane and tries to access mgmt in mplane.

No way!  Traffic is routed asymmetric and it simply fails. The workaround that I've created for him is to use another router and just NAT everything.

He's background is with other vendors (Palo, Cisco) which have a dedicated plane or vrf with complete sparation for managemnet and data.

So basically what I need to do is to tell him "checkpoint sux, loose MDPS and go to normal mode"  or use VSX which will complicate things with CoreXL and so on.

[Alex-]

We never tried MDPS due to the numerous constraints and the fact it's relatively new compared to the time-tested methods of a Firewall management section at the top and allowed hosts/trusted clients configuration. Also, you lose a core.

We believe it was added to answer some market demands (RFP, feature list and so on) where such a feature is necessary.

Other vendors have this by design, so yes each brand has their own specificities and we'd rather do VSX for this than MDPS.

With R82/VSNext/ElasticXL, maybe we'll just deploy only VSX from now on if the "free" initial VS remains available given the computing power of new appliances and the fact that the VS architecture has been completely re-engineered.

[Chris_Atkinson]

My customers also prefer VSX to MDPS.

Downtime for changing the number of FWK on VSLS clusters was something minimized circa R80.20 but perhaps your scenario is different: https://sc1.checkpoint.com/documents/R80.20_GA/WebAdminGuides/EN/CP_R80.20_RN/205465.htm#o207506 

Moreover the amount of manual CoreXL work can be reduced with the likes of Dynamic Balancing etc. 

For me these are not reasons to avoid VSX in this context and whilst the single VS element is valid this again has been improved with R82 both in terms of CoreXL limits and VSNext.