- Products
- Learn
- Local User Groups
- Partners
-
More
Join Us for CPX 360
23-24 February 2021
Important certificate update to CloudGuard Controller, CME,
and Azure HA Security Gateways
How to Remediate Endpoint & VPN
Issues (in versions E81.10 or earlier)
IDC Spotlight -
Uplevel The SOC
Important! R80 and R80.10
End Of Support around the corner (May 2021)
I really like the all new R80.30 feature for separating management from data traffic via
as described in sk138672.
Did anyone test this already?
About time! This is a long over due feature!
"Use of logical interfaces is not suppoted on management interface (Alias, Bridge, VPN Tunnel, 6in4 Tunnel, PPPoE, Bond, VLAN)"
1. It is a pity. Showstopper for us.
2. There is typo (suppoted -> supported).
So anything below 5900 will not be able to take advantage of it...
Danny, you may want to change the heading by adding "for gateways with 8 or more cores".
Otherwise it leads to unwarranted euphoria 🙂
Added.
I do have a concern about the best practices from the article: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
"Connectivity to the LDAP and similar servers from the Gateway should be done via the Data Plane."
I've always been told that only the management/control plane of a security gateway should be making or allowing connections to the device. The data plane should not allow or make connections, it should only play the role of traffic cop.
What is everyone's thoughts on this?
FYI this was changed to min 4 recently
Thanks for the info. I changed the thread title from 8 to 4 CPU cores.
I tested and worked successfully. (resource&routing both enabled)
It's not possible to use mgmt ip on identity collector and i think it should be.
Could you please add a service/task for this issue?
XXXXXXXXX:TACP-0> show mdps state
Management Data plane separation:
Routing plane: Enabled
Dedicated resource: Enabled (FW-Instance [39,38], CPU [4,28])
Management interface: Mgmt
Sync interface: Sync
Management plane configured routes:
default via X.X.X.X
XXXXXXXXX:TACP-0> show mdps tasks
Management plane tasks:
Service: cpri_d
Service: ntpd
Service: sshd
Service: syslog
Process: cloningd
Process: httpd2
Process: ntpd
Process: snmpd
Process: snmpmonitor
Port;Protocol: 256;tcp
Port;Protocol: 257;tcp
Port;Protocol: 2010;tcp
Port;Protocol: 5432;tcp
Port;Protocol: 18181;tcp
Port;Protocol: 18183;tcp
Port;Protocol: 18184;tcp
Port;Protocol: 18187;tcp
Port;Protocol: 18191;tcp
Port;Protocol: 18192;tcp
Port;Protocol: 18195;tcp
Port;Protocol: 18210;tcp
Port;Protocol: 18211;tcp
Port;Protocol: 18264;tcp
I tried mdps in the lab. I have two issues so far:
1. Can't make backup traffic to go over Mgmt interface, it attempts ssh connections on one of the data interfaces instead, even if I try to backup gateway to a management appliance.
2. TACACS traffic on port 49 goes over Mgmt interface during initial login the the gateway, which is expected, then it attempts to go over data interface for some reason during 2nd authentication when I try escalate my privileges from TACP-0 to TACP-15.
These two issues are show stoppers for us to deploy this feature.
We have exactly the same issue with R80.40 latest ongoing JHF:
1. Identity Collector planned to communicate with different firewalls in different zones and the only common network is the mgmt
2. We also can't apply JHF using CPUSE GUI, just CLI
3. Lastly, the default route disappears occasionally after a reboot
4. Only one sync is supported
Any light at the end of the tunnel? I wish it would work more like a routing domain with more flexibility.
Hi Alex,
Can you share the following please?
'dbget -rv mdps'
Also why do you need more than once interface for Sync? you can use link aggregation (bond) instead.
Hi Aviad,
We wanted to have another Vlan as 2nd sync, already have the dedicated sync as a bond.
Here is the outputs you requested, as you can see we put "0.0.0.0" and default as the default used to drop off occasionally.
Would good to understand if the Identity Collector can work with the management plane rather than data plane, this is the most major thing for us, the rest looks like bugs which will get fixed eventually.
[Expert@BNZ_WDC3-FW1-Access-011:0]# dbget -rv mdps
mdps:interface:management eth0
mdps:interface:sync bond0
mdps:route:0.0.0.0/0:nexthop:10.x.x.x t
mdps:route:default:nexthop:10.x.x.x t
Thanks
Please move clish to mplane environment:
'set mdps environment mplane'
Alternatively you can move confd to mplane permanently via 'add mdps task process confd' (requires reboot)
Hi Ramazan,
Currently it's a limitation which is documented on the SK, I would suggest consulting solution center
Hi everyone,
I have this in production with a R80.20 gateway and JHF 156. Works well so far except that customer's monitoring tool isn't able to discover data plane interfaces and counters, even if I follow sk138672 and use the "special community string" (..._dplane). Hope this will be gone with the next major upgrade. 😐
Does anyone here has other ideas and/or experience with mdps and interface monitoring using snmp? Could it help to disable resource separation?
Thanks
Hi dj0Nz, i strongly recommend using R80.30
Hi,
Just a point of clarification because it's not 100% clear in the SK, is this supported on R80.30 on both 2.6 and 3.10 kernels or only on 3.10? I interpret the minimum requirements as requiring JHF Take 136 if using kernel 3.10 but because there is no mention of 2.6 it's unclear if the original R80.30 GA supports this or if there is no support on 2.6.
Thanks and Regards,
Ben
Hi Ben,
MDPS is supported for R80.30 (2.6 and 3.10).
For 3.10 the requirement is to use JHF take 136
Why is the special community "community+_dplane." required ? Is it not possible to show both dataplane and management oids? If not, wouldn't it make more sense to show the dataplane oids and require a special community for the management plane - at the end of the day you want to access through the management plane to monitor the dataplane oids in most of the cases, no?
In sk138672, best practices recommend to run LDAP and similar through the dataplane. Why? I think LDAP/TACACS etc is about management, isn't it?
I wonder if it makes sense to add the tacacs process or tacacs service to the mplane? add mdps task ...
Hi @Luis_Miguel_Mig , Thank you for your feedback.
There is another option with SNMP where you don't need to put _dplane in the community name and instead use 1.4 prefix the get data plane OID.
for example: 1.3.6.1.2.1.2.2.1.2 is OID to get interface description, if you use 1.4.6.1.2.1.2.2.1.2 that will return result from data plane.
Regarding your 2nd comment, Currently a limitation, R&D working on solution to support such configuration.
Thanks Aviad,
I don't know what is the problem regarding the data plane oids but I was wondering if checkpoint would consider to keep the data plana oids with the standard community and oid numbers and perhaps changing the management plane oids if required in next GAIA releases?
Do you think the ldap/tacacs solution will be available in the next jumbo? I am working in a lab/test environment at the moment but planning to put it in production soon.
Hi @Luis_Miguel_Mig You are welcome to get in touch with the solution center in order to get such solution.
About CheckMates
Learn Check Point
Advanced Learning
WELCOME TO THE FUTURE OF CYBER SECURITY