- Products
- Learn
- Local User Groups
- Partners
- More
Quantum Spark Management Unleashed!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
Hello team,
I have been configuring some gateways in bridge mode with "inter-vlan multibridging" i mean:
3 bridge interfaces with the following squeme:
bridge 1 = bond2.10 and bond3.100
bridge 2 = bond2.20 and bond3.200
bridge 3 = bond2.30 and bond3.300
I had no problems with this configuration and the gateways bridge the traffic correctly between the corresponding vlan subinterfaces. By definition:
Bridging two interfaces causes every Ethernet frame that is received on one bridge port to be transmitted to the other port. Thus, the two bridge ports participate in the same Broadcast domain (which is different from router ports behavior).
Only two interfaces can be connected by a single Bridge interface. These two interfaces can then be thought of as a two-ports switch. Each port can be a physical, VLAN, or bond device.
I have tried to configure the same scenario in a VirtualSystem and I found the following limitation:
I have a VSX cluster and I followed this procedure:
1. Configure 2 bond interfaces in each VSX member:
add bonding group 2
set bonding group 2 mode 8023AD
set interface eth1-01
state on set interface eth1-02 state on
add bonding group 2 interface eth1-01
add bonding group 2 interface eth1-02
Set interface bond2 comments Outside
The same configuration with bond3.
2. I created the VLAN interfaces in the VSX Cluster via SmartClient. Then, when I create the VS, I select bridge mode, and then I add, for example, bond2.2 and bond 3.200. Vlan 2 is the outside vlan and vlan 200 is the inside vlan (both are in the same ip address range). The purpose of this is to bridge these vlan interfaces in order to force L2 traffic to pass through the VS.
The problem is that when I try to add more bondX.y interfaces to the virtualsystem and click accept an ERROR is prompted: Something like interfaces vlan must be created in pairs for bridge.
I have read in VSX admin guide:
To configure the external and internal interfaces:
If the selected interface is a VLAN interface, enter the same VLAN tag in both the external and internal VLAN Tag fields. This field is not available for non-VLAN interfaces.
So after some tests I get the conclusion that in VS you can:
* Configure only one intervlan bridge interface (different vlan in external and internal interfaces)
* Configure multi-bridge interfaces with same vlan tag for internal and external interfaces.
Limitation:
* Configure multi-bridge interfaces with different vlan in external and internal interfaces (as you can do in standard gateway operation)
Is this correct? Do you know the reason that we cannot configure this on VirtualSystems?
Thank you in advance.
Have you tried using vSwitch as the intermediary?
Do you mean to connect inside and outside trunks links directly to a Vswitch and then change the tags there in order to match the gateway bridge interfaces? I don't know if I understand you right.
Yes, by definition it seems I can configure it in active-active mode with same vlan tag:
Multi Bridges
This feature is supported only in R77.30 and higher, for VSX Gateways, and VSX clusters in Active/Active Bridge mode.
Multi Bridge allows traffic from many different VLANs to move over one Virtual System in Bridge mode. In a Virtual System in Bridge mode, you can add physical and VLAN interfaces. When you add more than two VLAN interfaces, Multi Bridge is automatically enabled. Configure the same VLAN tag on each set of two interfaces to make them bridged.
Requirements for Multi Bridge interfaces:
For example, you define eth1.10, eth2.10, eth1.20, eth2.20. Now the VLAN trunks, eth1 and eth2, cannot be used with other VLAN trunks on other Virtual Systems in Bridge mode: eth1.30 cannot bridge with eth3.30.
I tried this and it works but it is not exactly what I need. I am trying to migrate from other environment that can work with virtual contexts, multibridges and vlan translation but I cannot find the correct way to configure this in checkpoint.
Thanks!
Sure, will be like this. Endusers, for example in VLAN2, have their default gateway 192.168.1.254 in vlan 200 (who knows all the routes to get to remote networks). As we want to have the minimum impact in network design, we separate the ip network in two broadcast domains (vlan 2 and 200) and we bridge them at Checkpoint firewall in order to force this traffic to pass through it.
Hi mate! @PhoneBoy I don't know if you saw the network diagram. Thank you!
Thanks!!!
Given the limitations described in the "multi bridge" section it appears that you may have to use a dedicated VS for each VLAN translation instance.
Alternatively, translate them outside of the VSX.
Thank you for your reply. I think that using a VS per Bridge will not be cost effective (vs licenses) and will be hard manageable. I think we will need to change the network design, separate networks physically or translate vlans outside the VSX as you said.
Hi Guys,
I am deploying also a VS in bridge mode between two switches and I need to form the OSPF between the switches but I am having issues.
In the VS side, I setup the following interfaces to form the bridge using smart console.
br10
- eth1.200 (trunk)
- eth2.200 (trunk)
br20
- eth1.300 (trunk)
- eth2.300 (trunk)
In the switch side, I configure an SVI per VLAN. Then I configure the uplinks as trunk ports. This way, the OSPF is not forming and I do not see any traffic passing in the firewall.
However, when I configure the uplink ports of the switch to an access port for example access to vlan 200, the OSPF is forming and I can see traffic now in the firewall.
I would like to know what did I missed? The switchport should be working when I set it to trunk because my firewall interfaces are also in trunk mode as well.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
18 | |
11 | |
7 | |
7 | |
6 | |
6 | |
6 | |
4 | |
4 | |
3 |
Tue 16 Sep 2025 @ 02:00 PM (EDT)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - AmericasWed 17 Sep 2025 @ 04:00 PM (AEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - APACWed 17 Sep 2025 @ 03:00 PM (CEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - EMEAThu 18 Sep 2025 @ 03:00 PM (CEST)
Bridge the Unmanaged Device Gap with Enterprise Browser - EMEAThu 18 Sep 2025 @ 02:00 PM (EDT)
Bridge the Unmanaged Device Gap with Enterprise Browser - AmericasTue 16 Sep 2025 @ 02:00 PM (EDT)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - AmericasWed 17 Sep 2025 @ 04:00 PM (AEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - APACWed 17 Sep 2025 @ 03:00 PM (CEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - EMEAThu 18 Sep 2025 @ 03:00 PM (CEST)
Bridge the Unmanaged Device Gap with Enterprise Browser - EMEAThu 18 Sep 2025 @ 02:00 PM (EDT)
Bridge the Unmanaged Device Gap with Enterprise Browser - AmericasAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY