It is possible to disable the external cache. Thus, conntrackd directly injects the flow-states into the in-kernel Connection Tracking System of the backup firewall. You can do it by enabling the DisableExternalCache option in the conntrackd.conf configuration file:

Sync {
	Mode FTFW {
		 [...]
		 DisableExternalCache Off
	}
}
 

You can also use this option with the NOTRACK and ALARM modes. This increases CPU consumption in the backup firewall but now you do not need to commit the flow-states during the master failures since they are already in the in-kernel Connection Tracking table. Moreover, you save memory in the backup firewall since you do not need to store the foreign flow-states anymore.

You can also disable the internal cache by means of the DisableInternalCache option in the conntrackd.conf configuration file:

Sync {
	Mode NOTRACK {
		 [...]
		 DisableInternalCache Off
	}
}
 

However, this option is only available for the NOTRACK mode. This mode provides unreliable flow-state synchronization between firewalls. Thus, if flow-states are lost during the synchronization, the protocol provides no way to recover them.

You can use up to three different transport layer protocols to synchronize flow-state changes between the firewalls: UDP, TCP and Multicast. UDP and multicast are unreliable but together with the FT-FW mode provide partial reliable flow-state synchronization.

The preferred choice is FT-FW over UDP, or multicast alternatively. TCP introduces latency in the flow-state synchronization due to the congestion control. Under flow-state message are lost, the FIFO delivery becomes also a problem since the backup firewall quickly gets out of sync. For that reason, its use is discouraged. Note that using TCP only makes sense with the NOTRACK mode.

You can set redundant dedicated links without using bonding, you have to configure as many redundant links as you want in the configuration file. In case of failure of the master dedicated link, conntrackd failovers to one of the backups. An example of this configuration is the following:

Sync {
	Mode FTFW {
		 [...]
	}
	# default master dedicated link
        UDP Default {
                IPv4_address 192.168.2.1
                IPv4_Destination_Address 192.168.2.2
                Port 3780
                Interface eth3
                SndSocketBuffer 24985600
                RcvSocketBuffer 24985600
                Checksum on
        }
	# backup dedicated link
        UDP {
               IPv4_address 192.168.1.3
               IPv4_Destination_Address 192.168.1.4
               Port 3780
               Interface eth2
               SndSocketBuffer 24985600
               RcvSocketBuffer 24985600
               Checksum on
        }
	[...]
}
 

Since Linux kernel >= 2.6.34, iptables provides the CT iptables target that allows to reduce the amount of Connection Tracking events that are delivered to user-space. However, you will have to use a Linux kernel >= 2.6.38 to profit from this feature, since several aspects of the event filtering were broken.

The following example shows how to only generate the assured and destroy events:

 # iptables -I PREROUTING -t raw -j CT --ctevents assured,destroy
 

	Assured flows
	One flow is assured if the firewall has seen traffic for it in both directions.

Reducing the amount of events generated helps to reduce CPU consumption in the active firewall.

	Check your Linux kernel version first
	The synchronization of expectations require a Linux kernel >= 3.5 to work appropriately.

The connection tracking system provides helpers that allows you to filter multi-flow application protocols like FTP, H.323 and SIP among many others. These protocols usually split the control and data traffic in different flows. Moreover, the control flow usually announces layer 3 and 4 information to let the other peer know where the data flows will be open. This sort of protocols require that the firewall inspects the content of the packet, otherwise filtering by layer 3 and 4 selectors like addresses and ports become a real nightmare. Netfilter already provides the so-called helpers that track this protocol aspects to allow deploying appropriate filtering. These helpers create expectation entries that represent expected traffic that will arrive to the firewall according to the inspected packets.

In case that you have enabled tracking of these protocols, you may want to enable the state-synchronization of expectation as well. Thus, established flows for this specific protocols will not suffer any disruption.

To enable the expectation support in the configuration file, you have to use the following option:

Sync {
       ...
       Options {
               ExpectationSync {
                       ftp
                       sip
                       ras    # for H.323
                       q.931  # for H.323
                       h.245  # for H.323
               }
       }
}

The example above enables the synchronization of the expectations for the FTP, SIP and H.323 helpers.

In my testbed, there are two firewalls in a primary-backup configuration running keepalived. They use a couple of floating cluster IP address (192.168.0.100 and 192.168.1.100) that are used by the client. These firewalls protect one FTP server (192.168.1.2) that will be accessed by one client.

In ASCII art, it looks like this:

         192.168.0.100      192.168.1.100
                  eth1      eth2
                       fw-1
                     /      \       FTP
        client ------       ------ server
      192.168.0.2    \      /   192.168.1.2
                       fw-2
 

This is the rule-set for the firewalls:

    -A FORWARD -m state --state RELATED -j ACCEPT
    -A FORWARD -i eth2 -m state --state ESTABLISHED -j ACCEPT
    -A FORWARD -i eth1 -p tcp -m tcp --dport 21 --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j ACCEPT
    -A FORWARD -i eth1 -p tcp -m state --state ESTABLISHED -j ACCEPT
    -A FORWARD -m state --state INVALID -j LOG --log-prefix "invalid: "

Before going ahead, make sure nf_conntrack_ftp is loaded.

The following steps detail how to check that the expectation support works fine with FTP traffic:

You may want to try disabling the expectation support and repeating the steps to check that it does not work without the state-synchronization.