- Products
- Learn
- Local User Groups
- Partners
- More
Maestro Masters
Round Table session with Maestro experts
Hey guys,
I've been playing around with some Maestro units and a number of gateways. I have been running into a number of problems that caused me to document all the actions that I needed to do for a specific type of installation, the document is about 3 different scenario's:
Please check out the document and let me know what you think about it, also if you see things that you don't understand or know that should be different, please let me know.
Updated the document to v1.0, 16 dec 2019.
Updated the document to v1.2, 26 Feb. 2020. Added bonding.
Updated the document to v1.3, 03 Mar. 2020. updated some parts and added commands.
Updated the document to v1.5, 17 Mar. 2020. updated some parts and added commands after training.
Updated the document to v1.6, 25 May 2020. Update regarding HA licenses
If you have two MHO's in each sites are you saying the only SYNC port that is required is the external one (47)? I would have though the internal SYNC port would also be required for local SYNC traffic.
In a dual site implementation you need at least two sync ports, one is the orchestrator sync between the orchestrator at the same site and one is a site sync, between the sites.
Great, that makes sense.
No. We only support 1 or 2 orchestrator setups. In dual site setup both both sites should have the same number of orchestrators.
Yes, you should have the same number of appliances on both sites.
Not mandatory, but better to have the same amount
Hello all,
I've got question about link aggregation of management interfaces.
We have only one MHO140 and we're about to configure only one SG on it. I'm planning to configure LACP (magg) between ports 1 and 2. I will assign those ports to the SG, and after that configure LACP within. As far as I understood management ports can be shared between SGs. How to proceed if we decide to add new SG after some time? Do I have just to add ports 1 and 2 to the new SG, and create again LACP (magg) inside it?
Thank you!
Physical management ports can be shared between the security groups. It is Check Point's best practice to create a MAGG interface (management aggregation) if you have two orchestrators per site.
MHO-140 has four physical management ports to manage security groups. If you have multiple security groups and available switch ports my recommendation is to use to configure separate magg using dedicated management ports for each SG.
SG1: Eth1-Mgmt1 + Eth2-Mgmt1
SG2: Eth1-Mgmt2 + Eth2-Mgmt2
SG3: Eth1-Mgmt3 + Eth2-Mgmt3
SG4: Eth1-Mgmt4 + Eth2-Mgmt4
If you have more than four SGs or don't have enough switch ports (or use MHO-170 that has only two management ports), the physical management interfaces can be shared.
SG1: Eth1-Mgmt1 + Eth2-Mgmt2
SG2: Eth1-Mgmt1 + Eth2-Mgmt2
You can still create a magg out of these ports, but the mode must be XOR or active-backup. LACP is not supported for magg ports in Maestro.
Thank you all for the replies! I will try to add ports 1 and 2 to both security groups and create magg (active-backup) inside each one.
Hi Lari_Luoma
I have configured Bonding MAGG with XOR mode and the switch(cisco) has been configured, but due to human error/missing, bonding MAGG one of the interfaces is lost in the switch(cisco) configuration when trying to combine interfaces in the switch configuration and disable->enable the interface on orchestrator, traffic can not even pass to the Maestro. Can you tell me the good step to combine again the Bonding MAGG?
Does this still apply in R80.10?
I believe you mean R81.10? R81.10 supports uplink sharing.
Sorry, yes R81.10+
Hello all,
My MHO IP is 10.200.1.10 and the gateway is 10.200.1.1. The same gateway is a security group, part of MHO and also its management IP.
10.200.1.0/24 is part of the encryption domain of that SG, and now I can't reach Maestro (10.200.1.10) or other IPs from the same subnet via VPN, which I think somewhere were described as a normal behaviour. So currently all the hosts which are part of that subnet should be re-configured with different IPs and put on a separate VLAN.
I'm running R80.20SP T279. Do you know whether the issue with reaching management subnet via VPN is fixed in R80.30SP?
I think it shouldn't be an issue, but just in case I need your opinion - is it fine if Maestro IP is in different subnet from the SGs?
For instance I'm planning to add Maestro Mgmt to VLAN100 and give it IP 10.1.1.1, and then give SGs IPs from range 172.16.1.0/24 (VLAN200).
One more thing - may I break something if I change SG management IP in production environment?
Please let me know if I didn't describe clear enough all my questions.
Thank you!
Hi,
It's completely fine to have separated networks for MHO itself and Security Groups.
Please keep in mind, we do no support VPN or NAT on management interfaces of Security Group, since it doesn't pass via distribution. Better not to pass non-management traffic via Management interfaces.
Thank you,
Anatoly
Hello Anatoly,
Thank you for your reply! Let's say my management is co-located on another data center, and I'm going to use public IP of the SG for management. In case like this, do I need to add physical MGMT ports to the SG at all?
Yes, you need physical Mgmt ports, but you can manage your security group via uplink (traffic) interfaces.
Please note, when web services of Security Group (Web UI, Captive portal, etc...) won't work when using L4 distribution, so in this case, you have to disable it
Hello Anatoly,
I apologise if I'm asking stupid questions, but why do I need physical MGMT ports if I'm going to use my SG public IP for management?
I'm not sure I understood correctly your second sentence - WebUI won't work if use public IP instead of MGMT or I got it wrong?
1. Because otherwise you cannot complete FTW for security group
2. I will work only with L3 distribution (disable L4 distribution, which is enabled by default)
Thank you for your replies!
I was reading this and got a little confused if you are talking about the same thing here. 🙂
I strongly recommend migrating to a dedicated management interface architecture in Maestro. It will be much better solution in the long run. Some of the reasons include:
o Cutover(s) will be easier with a dedicated management interface as we’ll be able to stay connected all the time.
o We should be able to install policy before the cutover, so we can’t use the current production IP anyway.
o When the management server communicates with the gateway (SG) only one SGM will be aware of the communication and responding when using the dedicated management interface. This simplifies troubleshooting.
o Management interfaces are separate from data interfaces allowing management traffic even under high load.
o Anatoly can confirm, but my understanding also is that the orchestrators have QOS type of rules enforcing availability of the management traffic (when dedicated management interfaces are used)
o When you take ssh to the production interface, your connection lands on a random SGM that can be confusing.
All this being said you still should be able to manage the Maestro system over a production interface in security gateway mode (VSX needs to use the DMI). Your issue is not necessarily a Maestro issue, but related to VPN somehow. Any errors in the logs?
If you could share a network diagram it could help us to understand the issue.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
24 | |
4 | |
4 | |
2 | |
2 | |
2 | |
1 | |
1 | |
1 | |
1 |
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY