Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Madmaks
Contributor

Problem that is bridge Mode between Aruba Switch and Fortigate

Hi,

 

My plan is to position the Check Point device in bridge mode between the FortiGate firewall and the Aruba switch, and demonstrate the benefits of Check Point.

The FortiGate firewall and the Aruba switch are connected via LACP (Link Aggregation) and operate in trunk mode. Multiple VLANs are defined under this trunk. However, when I place the Check Point firewall between the two devices in bridge mode, no traffic passes through to me.

I have configured the VLANs under the Br1 interface on the Check Point device to match the VLANs defined on the FortiGate, but the result remains the same—no traffic is being received.

Ekran Resmi 2024-10-01 16.30.47.png

0 Kudos
14 Replies
AkosBakos
Leader Leader
Leader

Hi @Madmaks 

What does the Smartlog show?

What does #fw ctl zdebug + drop shows?

The picture is correct? Aruba and Forti sides are LACP, and the CP has only 1 Interface? Both side must be the same.  "one-legged" bond wont't work in this situation.

Akos

 

----------------
\m/_(>_<)_\m/
0 Kudos
Madmaks
Contributor

When I run  zdebug I could not see any drop.  Smartlog show just showing  log of mgmt interface.

 

Why do you think it won't work with a single interface? After all, that's what LACP is for. Even with a single interface, LACP will ensure that packets pass through one line.

The key point here is whether Check Point interferes with L2 traffic. For example, if it can only recognize IPv4, IPv6, and ARP traffic but not all traffic types, then that might be a reason for LACP not to work. Otherwise, I don’t see why it shouldn’t work. We can discuss this further

 

May be following solution will be help me, what about think?

 

Allow / Drop Ethernet Frames with Specific Protocols

By default, Security Gateway in the Bridge mode allows Ethernet frames that carry protocols other than IPv4 (0x0800), IPv6 (0x86DD), or ARP (0x0806) protocols.

Starting in R77.10, administrators can configure a Security Gateway in the Bridge mode to accept or drop Ethernet frames that carry specific protocols.

Note: In a cluster environment, this procedure must be performed on all members of the cluster.

Which Ethernet frames
should be allowed/dropped
Instructions
Allow Ethernet frames only with
IPv4, IPv6, and ARP protocols
  1. Add this line to the $FWDIR/boot/modules/fwkern.conf file (spaces are not allowed):
    fwaccept_unknown_protocol=0

  2. Reboot the Security Gateway.
Allow Ethernet frames
with any protocol
(other than IPv4, IPv6, or ARP)
(default)
  1. Add this line to the $FWDIR/boot/modules/fwkern.conf file (spaces are not allowed):
    fwaccept_unknown_protocol=1

  2. Reboot the Security Gateway.
0 Kudos
Chris_Atkinson
Employee Employee
Employee

The Check Point probably should have two bonds configured to participate in LACP for this topology irrespective of how many slave interfaces are up/down.

CCSM R77/R80/ELITE
0 Kudos
Madmaks
Contributor

Are you suggesting I do LACP on Checkpoint?

0 Kudos
AkosBakos
Leader Leader
Leader

Hi @Madmaks 

And I think if you do a TCPDUMP on the CP, you see nothing.

Yes, you need to do a BOND on CheckPoint site:

Why?

Because the CheckPoint site can't negotiate on LACP, because neither the ETH4 nor ETH5 is not a member of a bond (LACP group). How can the "talp" LACP if is not configured? 

Go further: if they never negotiate on LACP the traffic won't flow on a degradeted bond. This is my experience

Configure a simple bond, and see what happen. 

Akos

----------------
\m/_(>_<)_\m/
0 Kudos
Madmaks
Contributor

Yes, I technically understand everything you mentioned.

Initially, I thought the same, but then I considered that if the Check Point is in bridge mode, it should also forward the LACP negotiation (L2) packets required for the link aggregation to work.

However, from what I understand now, in bridge mode, the Check Point does not forward these LACP negotiation packets, meaning it doesn't fully function as a true bridge.

Alright, I'll try what you suggested. Thanks

0 Kudos
AkosBakos
Leader Leader
Leader

Hi @Madmaks 

Yes I understood. and thanks for understanding me. 

I think here is where the dog is buried:

When an IEEE 802.3ad aggregation is configured, link aggregation control protocol data units (LACPDUs) are exchanged between the server machine (host system) and the adjacent switch. Only the active channel, which could be either the primary channel or the backup adapter, exchanges LACPDU with the adjacent switch.

This is what doesn't happen.

Please keep me updated 🙂

Akos

----------------
\m/_(>_<)_\m/
0 Kudos
Madmaks
Contributor

Thanks for your explanation.  I want to ask you something. Do you think another vendor (I prefer not to mention the name) doing a PoC with this customer could have accomplished this using the virtual wire feature? Do you have any thoughts on this. 

0 Kudos
AkosBakos
Leader Leader
Leader

Hi @Madmaks 

I know this vendor, but I am not familiar with ther products. IEEE 802.3ad is a standard, and I thing nobody can bypass it. Rules are rules. 🙂

Akos

 

----------------
\m/_(>_<)_\m/
0 Kudos
Madmaks
Contributor

Based on this logic, do you think I also need to define the VLANs under the Bridge interface (Br1 and Br2) as Br1.100 and Br1.200, for example?

0 Kudos
AkosBakos
Leader Leader
Leader

No you don't need to configure VLAN.

Check this SK: https://support.checkpoint.com/results/sk/sk34312

Akos

----------------
\m/_(>_<)_\m/
0 Kudos
Madmaks
Contributor

0 Kudos
AkosBakos
Leader Leader
Leader

But our brainstorming was worth the time. :-).  I said the same with my words 🙂

Every word of Timothy are gold 🙂

 

----------------
\m/_(>_<)_\m/
0 Kudos
Madmaks
Contributor

Thank you again.  

In fact, if there is such an SK (https://support.checkpoint.com/results/sk/sk34312), there should definitely be an SK related to the topic we discussed as well.

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events