Bgp does not Established when Standby become Active

[cstaffbrad]

4400 Next Generation Firewall HA Appliance
Cluster Mode HA (Active,Standby) R80.40 Take 118
Configuration in place a per sk108958

We have implemented Dynamic routing protocol
as per sk108958 but when Cluster-1 is in the active state, the bgp traffic is processed
according to the implicit rule 0. But when Cluster-2 became active,
I see bgp traffic being drop by rule 100.

The workaround is to create a rule and allow the bgp traffic rule
in order to have the bgp status in the established state.

The question now is why is BGP traffic handled with implicit rule
when cluster-1 is Active? and does not apply to cluster-2 when
this becomes active?

Is this specific BGP rule necessary? is this official solution ?
is it by design or is it a bug?

sk39960 explained how to allow bgp traffic
How to allow dynamic routing protocols (OSPF, BGP, PIM, RIP, IGRP) traffic through Check Point Security Gateway
If this is the right solution, then why is the bgp traffic handled by an implicit rule?

[PhoneBoy]

What precise traffic is being allowed by the implicit rule on the primary versus an explicit rule on the secondary when it is active?

[cstaffbrad]

[Albin]

Looks like the traffic is sourced from the GW itself on the implied rule. Outgoing traffic is an implied rule.

Is the dropped traffic also sourced locally? That would be unexpected.

You need a BGP rule to accept the traffic for incoming BGP. 

[cstaffbrad]

Yes, The Dropped traffic is also sourced locally.

[the_rock]

@Albin gave a good explanation. Do you have an actual rule that would accept incoming BGP? Something for protocol 179?

[cstaffbrad]

I don't know if I understand your question correctly, but I think the description of the problem should answer your question.

"The workaround is to create a rule and allow the bgp traffic rule in order to have the bgp status in the established state. The question now is why is BGP traffic handled with implicit rule when cluster-1 is Active? and does not apply to cluster-2 when this becomes active?"

[the_rock]

My bad, missed that part, sorry about that. Cant say I ever seen that before, does not make a whole lot of sense, since rule would apply to the cluster regardless. Im wondering, when member 2 is active, what does clish -c "show route bgp" show? Do you see all the BGP routes there like on member 1 that works?

[cstaffbrad]

No problem. Yes, I see BGP routes like 1 that works. 

[the_rock]

I would probably open TAC case...I find that behavior very odd. Not sure if you tried rebooting  member 2 or not, but it might be worth a shot.

[Joerg_Schneider]

This was a old discussion without solution in checkmates. And I know nearly nothing about BGP.
My idea and question is:
Is a actual connection droped during failover or is it impossible to establish a new connection after failover?
The accepted outgoing connection is originating from member gateway-1 IP?
So I think a actual connection originating from member gateway IP cannot survive a cluster failover. How could state table entry change its source IP to member gateway-2 IP to work on the new active cluster member?

[Chris_Atkinson]

There isn't enough config detail here for a clear  picture. Granted there is also a VPN involved.

Is Graceful restart configured?

Is the Router_ID set the same on both members?

Were the BGP peer "local address" settings manipulated on one member compared to the other?

What do the precise rules allowing the traffic look like?

Do the remote devices correctly target the VIP as the BGP peer?

What version & JHF was the gateway etc