L2 Bridge mode - Multiple VLANs & Security Zones

[Scottc98]

Hi everyone, 

I am having a challenge with a L2 Bridge mode setup and hoping someone can chime in with some assistance/direction.

Use Case:

1) Customer requires a Layer2 based Bridge setup inline between its current router and core switch

2) Layer 3 interfaces reside on the router for select interfaces they wish to segment/control traffic; other networks are routed from the core switch; requiring inspection to/from router (i.e., out of the site)

3) Some of this control is between two VLANs sitting off the same router  (VLAN 100 and VLAN 200 in this example).  

4) Customer is using a Native, non tagged interface (10.10.10.1/24 in this example) between the Core and router; Tagging the interface on the router is not possible due to a dynamic routing limitation (i.e for some reason, running OSPF or BGP on this router can't be done on a sub interface 😞 )

Testing:

Initially, we set this up as a simple bridge interface (Eth1 <=> Eth2) on the checkpoint and it did flow traffic through for any traffic coming from/to the core and router.   Once we attempted traffic from one of the segmented networks, it dropped the traffic.   We determined this to be due to some 'hairpinning' of the traffic going up and back down the same bridge interface to be the root cause.  

Intended setup:

To overcome this, we are thinking of establishing 3 total bridge interfaces:   Bri1 (Eth1 <=> Eth2; for the untagged interface), Bri100 (Eth1.100 <=> Eth2.100) for VLAN 100 traffic and Bri200 (Eth1.200 <=> Eth2.200) for VLAN 200.   The hope here is that traffic between Vlan 200 and the native or between VL100 & VL200 will be allowed as its now should flow through two different interfaces.   

Wanted to check to see if 1) this is the best means to accomplish this and 2) is there any issues with this exact setup in reference to the 'untagged' traffic (Ok to do as described or do i need another physical wire  (i.e. Access port for the native only [Eth1/Eth2 bridge] and a trunked port for the tagged only [Eth3/Eth4 with VLAN interfaces for the bridges).

Topology/Security Zone question:

My goal was to fix this separation with the various Bridge interfaces per VLAN and then use security zones associated to each of the interfaces to build my access/threat policy off of.    Since this setup will be repeated at various sites, I want to establish a unified rule base using the security zone objects.   VL100 and VL200 all have the same use case at these sites but different networks.    

What i am not able to find is firm documentation on how to set this up.    

• https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_SecurityManagement_AdminGuid...
  • The "Quantum Security Management R81.10 Administration Guide" docs here mention this note :

    Note - The physical interfaces that are part of a Bridge interface always appear with the topology "Undefined".

    Workaround: Use the API command "get-interfaces".

  • Testing this in my lab using the API (with topology) does import the physical and VLAN interfaces all with the following
    • Leads To "This Network (Internal)"
    • IPv4: 0.0.0.0/0
    • Security Zone: none
    • Anti Spoofing "Prevent and Log"
  • Testing this in my lab using the API (without topology) does import the physical and VLAN interfaces all with the following
    • Leads To Not Defined (Internal)
    • IPv4: 0.0.0.0/0
    • Security Zone: none
    • Anti Spoofing "Disabled"
• https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_Installation_and_Upgrade_Gui...
  • The R81.10 install guide mentions the following for a single GW
  • On the Network Management page, configure the Topology of the Bridge interface.

Notes: If a Bridge interface connects to the Internet, then set the Topology to External. If you use this Bridge Security Gateway object in Access Control Policy rules with Internet objects, then set the Topology to External.

• Since you can only import the physical/VLAN interfaces, would that mean my Eth1 based ones (Ones towards the router) should be external....especially if that router is in its routing path towards the internet?   (Making my Eth2 based one 'internal' then?
• Even more confusing is when I look at the same guide but for a cluster setup (https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_Installation_and_Upgrade_Gui...)

  • Important:

    • Make sure the Bridge interface and Bridge subordinate interfaces are not in the Topology.

    • You cannot define the Topology of the Bridge interface. It is External by default.

I know that unless I can import the topology, I can't define security zones but does that mean that you can only do this in a single GW here and not a Cluster (Active/Active or Active/Passive)?    If External is the default topology for a bridge interface, why does each import (with or without topology) both come back with "internal" in some form.   I've looked at all of the SKs around bridge mode and what is supported and what is not.....I can't find anything outside what I have posted here that mentions anything of this subject.   its also my understanding that in L2 bridge mode, Anti-spoofing should be off (sk105899 & sk34312).  is that still the case today or only for ease of not requiring to define every network manually (per  sk34312) or for the double inspection of the management interface depending on how it flows in/out in respect to the bridge (sk105899).   For the VLAN networks in question, I believe I can define the spoofing if I set the topology with "This Network (Internal) => IP address behind this interface => Specific <Insert Network object here>.   But if the documentation states it can only be "external", then I would think defining this would not be possible(?). 

I really want to solve this L2 issue and not have to resort to a L3 deployment with the current setup this customer has.   I also know that a ClusterXL question will come up here and would also like to figure out if there is limitation to this topology deployment with the VLAN tags and Security Zones is even plausible overall. 

Sorry for the long drawn out post.....been bugging me for awhile trying to solve this and appreciate any assistance before I engage my account team 

[Scottc98]

Realizing after a night's sleep that Anti-spoofing will need to be disabled.   I feel that with the management interface being the only layer 3 on the gateway, I will hit a case where its traffic will cross the bridge as sk105899 describes 😞

Also looked at management data plane separation is not an option since i have 1) concerns with DNS traffic and 2) some of these are smaller gateways where I don't want to carve out CPU resources to seperate this.

The other question i have:  Is there going to be some sort of 'double-inspection' here going up one bridge and back down the other (Even with Anti-spoofing disabled)?    It would seem 'asymmetrical' for the flow and wanted to make sure there wasn't unnecessary load on the GW to process that.  Hoping that it doesn't require something like SecureXL disablement or equivalent customizations that would consume additional cycles on the box.    

[PhoneBoy]

Having the same flow come into the gateway twice through different bridges will not work as you cannot perform “double inspection.”
This has nothing to do with anti-spoofing and isn’t something that can be disabled.
In this case, you’d probably have to use VSX or consider a different design.

[Scottc98]

Thanks @PhoneBoy   I've got a call with my account team to review and explore some options here.   This started as a IPS only inspection, then to access layer one with the VLANs never crossing over....and then the 'hairpin' request.   i've been pushing for Layer 3 for a while and starting to feel that the requirements they have now will push to move that direction.  

If the flows of each network in this example was strictly between the router and switch (passing through the FW once), The use of "multi-bridge' interfaces for the each VLAN and use of security zones would work in this use case, correct?  Wanted to confirm if there was never any cross traffic across those bridges nor the management interface never flowed through them, this would be a valid meant to setup the bridge and use security zones as the objects in access/threat rule enforcement.  

I'll look into the VSX options but i have concerns that this might require additional license costs, along with complete chassis rebuilds.  

Is there any good sizing documentation to review for VSX gateway & clusters?   I see where each gateway data-sheet lists the max # of Virtual systems supported but wanted to see if there was more data on its affect of overall performance breakdowns as you split the gateway up.    I got small sites with 3600/3800s and bigger ones with 6400....buying new HW simple to run VSX would be a hard sell if L3 redeployment fits the use case 😉    That being said, the more VLANs added on to the CP, the more it will inspect...and the more performance it will require.   So if the scope changes....so may the sizing requirements 😉

[Scottc98]

In a previous post, I was wondering if SecureXL would come in to play with blocking this flow of traffic.   I found this SK (sk114976) that mentions a similar situation and curious if matches.  While not looking to go down that path, I just want to make sure I have the full grasp of the changes & impacts with their current deployment to help build out a justification case to redesign it. 

[PhoneBoy]

I suspect this is one of the reasons this is unsupported.
Further, you really can't disable SecureXL anymore, merely prevent certain traffic from templating.

[PhoneBoy]

More than one bridge is supported, yes.
Where you'll run into trouble is when the traffic traverses the gateway a second time.

VSX will have additional licensing costs, yes, and impose some overhead (10% or more, depends on number of VSes and traffic patterns).
I would start by seeing how utilized the gateways are using cpsizeme and reviewing the proposed configuration with your Check Point SE. 

[chethan_m]

Did you check by disabling SecureXL ?