- Products
- Learn
- Local User Groups
- Partners
- More
Maestro Masters
Round Table session with Maestro experts
Hello All,
Based on yesterday Maestro Masters Round Table June 2022:
https://community.checkpoint.com/t5/Maestro/Maestro-Masters-Round-Table-June-2022-Video-Slides-and-Q...
There was a question and answer related to Q-in-Q requirement for Dual site architecture through external L2 switches:
===
Q: Do we still need to use QinQ VLAN for dual site Maestro configurations?
A: QinQ is not required as of R81.10.
===
May I request more details regarding above answer?
Based on available information like: sk168092, sk168814 or Quantum Maestro Getting Started Guide
there is still info that Layer 2 switches must support VLAN Q-in-Q Tunneling for Dual site architecture.
Thanks and BR
Daniel.
@Tal_Ben_Avraham & @Anatoly can you please answer?
Hi,
The default setting is to use QnQ. That mean, the default VLAN 3600 (or 3601 for a second pair of MHOs) will include all Sync vlans of security groups (3801,3802, etc..).
If you disable QnQ, then you have to configure vlans 3801, 3802, etc,,, in trunk with 3951 (or 3952 for a second pair of MHOs) instead of 3600 (or 3601).
Wow @Anatoly this is weird, when I was trying to change the base-vlan for the sync but got this:
set maestro configuration security-appliances inter-site base-vlan 3800
NMSSG 1 Invalid VLAN ID. Security Appliances inter-site base VLAN ID must be a number in the range of 3600-3650
This would mean that we need 3600-3601 for the sync and 3951, 3952 with 2 sec groups.
However I can tell you it does NOT work with the ranges 3600-3650 and 3950-3970 on the trunks
We do have this setting to disable QinQ:
set maestro configuration security-appliances inter-site vlan encapsulation disable
Hi,
That is because these 3800 VLANs are reserved for inter-SGMs sync. In general - please avoid using following vlans:
So the simple question is which VLAN's need to be allowed on the trunk between the sites when inter-site vlan encryption is disabled?
For first pair of MHOs: 3951 and 3801; for second pair - 3952 and 3801 (assuming you have only 1 security group). For any next security group add 3800+security group number
That is weird then as all documents say its using 3600 and up instead of 3800 and up, but it explains a lot why it is not working.
Thanks a lot @Anatoly
Documentation is correct. This is 3600, but 3600 is external VLAN tag.
That means, sync vlans of SGMs are coming with double-tag: [3600(3801)], [3600(3802)], etc.
When you disable QnQ, it does not wrap 380x VLANs into 360x tags, so it comes as I explained above
Thanks @Anatoly
It would be nice to update all documentation regarding the possibility to avoid requirements Q-in-Q tunneling since R81.10, after disabling vlan encapsulation on MHO's.
But as I understand it still limited to environment with no already existing vlans 3800+SG and 3951/3952, right?
BR
Daniel
I agree. We will work on it
@Anatoly it woulf really be helpful to have a R81.10 version of sk168092 with the above information incorporated.
@Anatoly 1 question left, how big is the chance that VLAN 370x will appear on the inter-site link?
VLAN 370x is used for correction layer. So, it's crucial.
but above you did not mention it being used on the inter-site link, so let me rephrase my question: do I need to add 370x to the allowed VLAN list for the inter-site sync?
I suppose correction layer communication should remain only in active site.
BR
Daniel.
No, because we do not run correction traffic between sites
FYI - sk168092 was finally updated:
===
If Orchestrators are connected via external switches, ports on the external switches must be configured accordingly.
In versions lower than R81.10, external switches must support 802.1ad ("QinQ") and allow packets with more than 1 VLAN tag. It must not remove any of the existing VLAN tags.
In version R81.10 there is an option to disable QnQ encapsulation. In this case you have to trunk all Sync vlans (380x) of all security groups all the way between sites.
===
BR,
Daniel.
Hello,
What about cli command in sk168092 how to disable QinQ encapsulation on MHOs ?
Hello,
Unfortunately they didn't mention about it. Regarding sk we have always a little possibility to give feedback without overall chance to choose how sk will be corrected.
The command on MHO was already mentioned in this thread:
set maestro configuration security-appliances inter-site vlan encapsulation disable
BR
Daniel.
Hi,
Shouldn't also vlan 395X be included in this sentence:
In version R81.10 there is an option to disable QnQ encapsulation. In this case you have to trunk all Sync vlans (380x) of all security groups all the way between sites.
Also, like mentioned before, the information on how to configure a dual site Maestro setup without using a QinQ tunnel should be made clear and complete without searching different SK's, documentation and Checkmates articles.
For example this text could be mentioned:
On the switches, configure vlans 3801-3804 (for 4 security groups) and 3951-3952.
On the MHO, use the following command: set maestro configuration security-appliances inter-site vlan encapsulation disable
Just my two cents.
Grtz Jones
Hi,
Yes, it should be added info that trunk must consists MHO Sync vlans (3951, 3952) and all used SecGrp Sync vlans (3800 + number of SecGrp) as well cmd to disable encapsulation on MHO's.
Unfortunately as patner I can only send them feedback through sk without possibility to check what they finally are going to add.
Anyway, thanks Jones for raising this as this thread consists all required information but sk not. Also I totally agree that sk/documentation should be complete before any article on checkmates.
BR
Daniel.
Hi,
I added this feedback to sk168092. Let's keep our fingers crossed.
Grtz Jones
I did it as well 🙂
BR
Daniel.
Hi,
Try to check it now. I pushed feedback twice and now subject for "Disabling site-sync VLAN encapsulation" looks better.
BR
Daniel
Hi,
This looks way better indeed. Well done Check Point.
Grtz Jones
Hello All,
Based on yesterday Maestro Masters Round Table June 2022:
https://community.checkpoint.com/t5/Maestro/Maestro-Masters-Round-Table-June-2022-Video-Slides-and-Q...
There was a question and answer related to Q-in-Q requirement for Dual site architecture through external L2 switches:
===
Q: Do we still need to use QinQ VLAN for dual site Maestro configurations?
A: QinQ is not required as of R81.10.
===
May I request more details regarding above answer?
Based on available information like: sk168092, sk168814 or Quantum Maestro Getting Started Guide
there is still info that Layer 2 switches must support VLAN Q-in-Q Tunneling for Dual site architecture.
Thanks and BR
Daniel.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
18 | |
3 | |
2 | |
2 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 |
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY