topic Re: Tech Tip - Dynamic Routing: BFD in Firewall and Security Management

Tech Tip - Dynamic Routing: BFD

Chris_Atkinson — Mon, 17 Nov 2025 03:18:13 GMT

Background

Bidirectional Forwarding Detection (BFD) is a fast fault detection protocol used to monitor links between network devices like routers and switches. It's purpose is to detect link failures (to quickly facilitate routing around them) rather than device failures which is an important distinction in the case of a clustered pair of Firewalls.

In a ClusterXL environment "Standby" cluster members do not respond to BFD. Hence when considering the configuration of BFD we need to pay attention to the underlying network fabric and parameters such as the ClusterXL dead timeout. Does the network topology require / warrant BFD and what is it really achieving for us?

Timers & Best Practices

For a non-clustered security gateway the calculated BFD timeout should be at least 1 second, preferably 3 seconds (or more) for reliability. For more details, see RFC 5880.
On Cluster Members, make sure the calculated timeout is longer than the time necessary for the cluster to complete an unattended failover in your environment. We recommend that you first test failover in your environment.

Do not use the IP Reachability Detection feature in combination with the Graceful Restart feature in dynamic routing protocols, unless the routing protocols support the BFD "c-Bit".

Source: Check Point R82 Gaia Advanced Routing Admin Guide - IP Reachability Detection Configuring in Gaia Clish

Access Policy

Routing related protocols such as BGP, OSPF etc need to be allowed by the security gateway access policy in order for routing adjacencies / neighbors to be able to form successfully. In general this traffic is not covered by implied rules.

Configuration of the necessary rules for common routing protocols are covered by the following knowledge article; similar rules are required to allow BFD traffic as an example (UDP destination ports control: 3784 & echo: 3785) e.g.

Source	Destination	Service	Action	Install On
BFD neighbors Relevant Security Gateways	BFD neighbors Relevant Security Gateways	BFD-Single_hop	Accept	Relevant Security Gateways

sk39960: How to allow Dynamic Routing protocols traffic (OSPF, BGP, PIM, RIP, IGRP) through Check Point Security Gateway

Priority Queues

As relevant to BFD should be default in current versions, please see: sk105762: Firewall Priority Queues in R80.x / R81.x

Re: Tech Tip - Dynamic Routing: BFD

akurtasanov — Wed, 29 Apr 2026 17:13:18 GMT

Should Explicit NAT rule with Hide under VIP for BFD service be used in the ClusterXL?

Re: Tech Tip - Dynamic Routing: BFD

Chris_Atkinson — Wed, 29 Apr 2026 23:23:47 GMT

I don't recall having to manipulate NAT relative to BFD in the past, what's the scenario / version that you are trying to deploy - what are you seeing?

Re: Tech Tip - Dynamic Routing: BFD

akurtasanov — Thu, 30 Apr 2026 03:30:55 GMT

In the case of using NoNat rules. We have a top-level NoNat rule for the 10.0.0.0/8 network and all BFD requests fall under it. BGP itself, according to traffic data, ignores this rule and works fine. And according to the documentation, it is not entirely clear whether the BFD in the clusterxl should initially leave the active node under the VIP address or its own address of the active node, but in the latter case, it is not clear how to set up the BFD session.

As Example:
ClusterXL VIP - 10.0.0.1, Node1 - 10.0.0.2, Node2 - 10.0.0.3
BGP node - 10.0.0.4

In the case of NoNat, we have a BGP session between 10.0.0.1 and 10.0.0.4.
If configure BFD, the session 10.0.0.2 and 10.0.0.4 or 10.0.0.3 and 10.0.0.4 appears (depends on which node is the primary one).
But due to the fact that BGP peering is between 10.0.0.1 and 10.0.0.4, BFD is not working correctly.
And it's not entirely clear from the documentation how the BFD should behave initially, whether it's worth making Hide Nat Rule for 10.0.0.2 and 10.0.0.3 under 10.0.0.1 or somehow configuring 4 BFD sessions, although it's unclear how.

Re: Tech Tip - Dynamic Routing: BFD

Chris_Atkinson — Thu, 30 Apr 2026 05:45:45 GMT

The number of BFD sessions needed is based on links not multiplied by cluster members, the cluster is a single logical router.

Re: Tech Tip - Dynamic Routing: BFD

akurtasanov — Thu, 30 Apr 2026 06:33:59 GMT

Therefore, in my case, I have to overlap he NoNat rule
src 10.0.0.0/8 dst 10.0.0.0/8 Srv Any NewSrc Original NewDst Original
with more prioritized Hide Nat Rule like this
src 10.0.0.0/8 dst 10.0.0.4 Srv BFD NewSrc Hide_10.0.0.1 NewDst Original

Is that right?

Re: Tech Tip - Dynamic Routing: BFD

Chris_Atkinson — Thu, 30 Apr 2026 08:17:04 GMT

Has the settings described in sk34180 been changed for your environment?

Re: Tech Tip - Dynamic Routing: BFD

akurtasanov — Thu, 30 Apr 2026 08:33:29 GMT

No. By default perform_cluster_hide_fold is true. Nothing changed.
I was planning to get a simple answer:
1) Yes, bfd should be with VIP
2) No, bfd works without VIP with the private address of the active node.
And then sort it out further or open the case in TAC

Re: Tech Tip - Dynamic Routing: BFD

Chris_Atkinson — Thu, 30 Apr 2026 09:26:59 GMT

It should be the VIP. Actually I think your case is already described here:

https://community.checkpoint.com/t5/Firewall-and-Security-Management/ClusterXL-BFD-Bidirectional-Forwarding-Detection/td-p/64486