The conntrack-tools user manual

In order to get conntrackd working in synchronization mode, you have to fulfill the following requirements:

The daemon conntrackd in synchronization mode supports up to three replication approaches:

The three existing approaches are soft real-time asynchronous replication protocols that are aimed to have negligible impact in terms of latency and bandwidth throughput in the stateful firewall filtering.

To configure conntrackd in any of the existing synchronization modes, you have to copy the example configuration file to the directory /etc/conntrackd/ on every firewall replica. Note that _type_ is the synchronization type selected.

 (conntrack-tools-x.x.x)# cp doc/_type_/conntrackd.conf /etc/conntrackd/conntrackd.conf

Do not forget to edit the files before going ahead. There are several parameters that you have to tune to adapt the example configuration file to your setup.

	Configuration file location
	If you don't want to put the config file under /etc/conntrackd/, just tell conntrackd where to find it passing the option -C.

In the Active-Backup setup, one of the stateful firewall replicas filters traffic and the other acts as backup. If you use this approach, you have to copy the script primary-backup.sh to:

 (conntrack-tools-x.x.x)# cp doc/sync/primary-backup.sh /etc/conntrackd/

The HA manager invokes this script when a transition happens, ie. If a stateful firewall replica:

The script is simple, and it contains the different actions that conntrackd performs to recover the filtering or purge obsolete entries from the state table, among others. The script is commented, you can have a look at it if you need further information.

The Active-Active setup consists of having more than one stateful firewall replicas actively filtering traffic. Thus, we reduce the resource waste that implies to have a backup firewall which does nothing.

We can classify the type of Active-Active setups in several families:

As for 0.9.8, the design of conntrackd allows you to deploy an symmetric Active-Active setup based on a static approach. For example, assume that you have two virtual IPs, vIP1 and vIP2, and two firewall replicas, FW1 and FW2. You can give the virtual vIP1 to the firewall FW1 and the vIP2 to the FW2.

Unfortunately, you will have to wait for the support for the Active-Active setup based on dynamic approach, ie. a workload sharing setup without directors that allow the stateful firewall share the filtering.

On the other hand, the asymmetric scenario may work if your setup fulfills several strong assumptions. However, in the opinion of the author of this work, the asymmetric setup goes against the design of stateful firewalls and conntrackd. Therefore, you have two choices here: you can deploy an Active-Backup setup or go back to your old stateless rule-set (in that case, the conntrack-tools will not be of any help anymore, of course).

Once you have configured conntrackd, you can run in console mode which is an interactive mode, in that case type 'conntrackd' as root.

(root)# conntrackd

If you want to run conntrackd in daemon mode, then type:

(root)# conntrackd -d

You can verify that conntrackd is running by checking the log messages via ps. Moreover, if conntrackd is running fine, you can dump the current status of the daemon:

 # conntrackd -s
 cache internal:
 current active connections:                4
 connections created:                       4    failed:            0
 connections updated:                       0    failed:            0
 connections destroyed:                     0    failed:            0

 cache external:
 current active connections:                0
 connections created:                       0    failed:            0
 connections updated:                       0    failed:            0
 connections destroyed:                     0    failed:            0

 traffic processed:
                    0 Bytes                         0 Pckts

 multicast traffic:
                  352 Bytes sent                    0 Bytes recv
                   22 Pckts sent                    0 Pckts recv
                    0 Error send                    0 Error recv

 multicast sequence tracking:
                    0 Pckts mfrm                    0 Pckts lost
 

This command displays the number of entries in the internal and external cache:

You can dump the internal cache with the following command:

 # conntrackd -i
 tcp      6 ESTABLISHED src=192.168.2.100 dst=139.174.175.20 sport=58491 dport=993 src=139.174.175.20 dst=192.168.2.100 sport=993 dport=58491 [ASSURED] mark=0 secmark=0 [active since 536s]
 tcp      6 ESTABLISHED src=192.168.2.100 dst=123.59.27.117 sport=38211 dport=993 src=123.59.27.117 dst=192.168.2.100 sport=993 dport=38211 [ASSURED] mark=0 secmark=0 [active since 536s]
 tcp      6 ESTABLISHED src=192.168.2.100 dst=123.59.27.117 sport=38209 dport=993 src=123.59.27.117 dst=192.168.2.100 sport=993 dport=38209 [ASSURED] mark=0 secmark=0 [active since 536s]
 tcp      6 TIME_WAIT src=192.168.2.100 dst=74.125.45.166 sport=42593 dport=80 src=74.125.45.166 dst=192.168.2.100 sport=80 dport=42593 [ASSURED] [active since 165s]
 tcp      6 ESTABLISHED src=192.168.2.100 dst=139.174.175.20 sport=37962 dport=993 src=139.174.175.20 dst=192.168.2.100 sport=993 dport=37962 [ASSURED] mark=0 secmark=0 [active since 536s]
 

You can dump the external cache with the following command:

# conntrackd -e

If the replication works fine, conntrackd -s displays the active's internal cache should display the same number of entries than the backup's external cache and vice-versa.

To verify that the recovery works fine, if you trigger a fail-over, the log files should display the following information:

 [Thu Sep 18 18:03:02 2008] (pid=9759) [notice] committing external cache
 [Thu Sep 18 18:03:02 2008] (pid=9759) [notice] Committed 1545 new entries

This means that the state entries have been injected into the kernel correctly.

Problems with conntrackd? The following list of questions should help for troubleshooting: