CheckPoint bridge mode is not working between the Fortigate and H3C switch

[BlueGrass]

-------

17/2/2020

-------

Add screen capture on the below reply for further troubleshooting.

-------

16/2/2020

-------

HI all,

I just have a Checkpoint as bridge mode and have a scanning over the Trunk link.

Both Fortigate and H3C has a Trunk link up already before. Vlan 10 is tagged with untagged VLAN 1.

All my users are in Vlan 10.

They need to have both CP and FG scanning while visiting the internet.

Then we set up port 3 and 4 as br1 on the Check point.

FortiGate connects to p3 while h3c switch uplink to p4.

Both p3 and p4 are in the Internal zone with anti-spoofing disabled.

CP Firewall policy just has the clean up one with any to any accepted.

From the debug flow on FortiGate, I can not find the traffic to the internet, let says the dst. is "1.1.1.1"

Nevertheless, both 192.168.100.1 and 172.16.10.101 can ping mutually and have the debug log result from Fortigate.

I think this proves the CP policy working well?

Interestingly, both Firewall traffic Logging reveal the traffic is accepted if to the internet.

Only no outcome from the debug log result from Fortigate if the dst. is to internet or "1.1.1.1"

I swear to god that FortiGate original settings are good.

As we use it before and everything just normal.

Please someone helps.

Below is the lab topology after the deployment.

[_Val_]

Do you see the traffic forwarded on Check Point through the bridge? Simple "fw monitor" would answer this question

[BlueGrass]

From the Firewall policy, I can find the traffic is passed.

[BlueGrass]

So is Fortigate side, I can find the traffic is passed.

But no idea why the traffic debug flow can not find the related traffic.

[BlueGrass]

Screen for your referencing:

No output from fw ctl zdebug drop.

And Ping result if to 9.9.9.9:

[_Val_]

It is showing Check Point FW is not a problem here. Look outside for some external failure

[BlueGrass]

The Big O is not appearing from 172.16.10.101 I think?

[_Val_]

Uh, I was looking at interface names and did not look at IPs. 

You are correct, it seems FW is NAT-ing the connections, which should not happen on the bridge in the first place. Check your NAT policies.

[BlueGrass]

Please have a look at the latest reply.

I have the NAT screen for it.

I even try manually have one to force everything translated as original ...

Well, still the same.

[_Val_]

10.20.30.1 - who's this IP belonging to?

[BlueGrass]

That is Checkpoint Br1 ip address before.

I use that for Vlan 1 and mgt ip for UTM update.

Interestingly, 10.20.30.1 is good to passthrough Fortigate over the trunk and access internet

[_Val_]

and by the way, do you have _another_bridge_ on Check Point for VLAN10?

[BlueGrass]

Only Br1 is on the Checkpoint.

I even try no both tag vlan 10 and tagged Vlan 10 to Br1 also.

[Chris_Atkinson]

I assume NAT is disabled on the Check Point gateway, what other controls are active?

(Refer also sk101371,sk106319)

[BlueGrass]

Yes, NAT is disabled on the Check Point gateway level already.

Only the general UTM blades like AntiVirus, IPS, Web filter.

[Chris_Atkinson]

Is your firewall and URLF/AppC policy consolidated or in separate layers currently?

Regarding the destination, is it always specified as "Any" versus "Internet" in _all_ applicable rules...

[BlueGrass]

Take a quick look at it:

I try to rebuild the Br1 into Port1 and 2, downgrade to R80.10 and replace the H3C to Cisco 2960 now.

Still no luck.

[Chris_Atkinson]

Per Val's comment, please double check the NAT options/settings on the Gateway object itself.

[BlueGrass]

Bro, I check it more than 10 times really.

No box in NAT of the gateway was checked.

[_Val_]

can you please post Bridge config from Gaia and also the GW topology tab?

[BlueGrass]

[_Val_]

All seems to be in order. Yet, after policy push and FW reboot, do you still have ping NAT-ed on the bridge?

[BlueGrass]

Hi all,

We no longer waste our valued time on it now.

This issue is due to:

1. My test LAN 172.16.10.X/24 just conflicts with the CP built-in SSLVPN subnet. And this causes the default NAT triggered also.

2. DNAT allocation needs to be enabled on CP if you decide to change the CP built-in SSLVPN subnet to others.

Thanks to the TAC finally..... What the ... Great CP we have got. >_>