Is conntrackd really pfsync+CARP for Linux?

Say it aint' so Joe, but conntrack-tools says it "provides and equivalent of OpenBSD's pfsync."

What can do the conntrack-tools for me?

Lots of cool things. conntrackd covers the specific aspects of stateful Linux firewalls to enable high availability solutions and it can be used as statistics collector of the firewall use as well. The command line interface conntrack provides an interface to add, delete and update flow entries, list current active flows in plain text/XML, current IPv4 NAT'ed flows, reset counters atomically, flush the connection tracking table and monitor connection tracking events among many other.

This is something I've been wondering about for a while and it looks like this project has been around since 2006.

Here is a presentation on the capabilities of this. There isn't much test data here, but based on the stats in the talk, the performance of conntrackd (my testing/production observations was done on similar hardware DL-145G3) look a significantly worse than FreeBSD/OpenBSD with PF+pfsync+CARP. Note that the CARP/VRRP functionality is performed by keepalived.

*BSD can be used in the Enterprise for high availability gigabit packet filtering, but it would be interesting to see if anyone is using iptables+conntrackd+keepalived for this?

Update
This presentation about a successful migration from Linux to OpenBSD confirmed my suspicions about conntrackd not being ready for prime time. And This USENIX article provided an interesting comparison between OpenBSD and Iptables.

Linux is, in general, more efficient than OpenBSD. In both router and bridge configurations, it spends less time forwarding packets. Furthermore, iptables filters packets more quickly than PF, with only one exception (in our testing): if the transport-layer protocol of the transit packet, say, UDP, differs from the specifiedtransport-protocol type of a sequence of rules—“protocol type” set to “TCP”in this example—PF ignores those rules and confronts the packet only with the rest of the set, acting more efficiently than Linux, which confronts the packet with all the rules in the set.

This feature of PF is very interesting. UDP-based attacks are very insidious, and most firewalls have rules to prevent many types of UDP datagram from accessing the network. Nevertheless, most traffic from and to a protected network is made up of TCP streams (protocols such as HTTP, SMTP, and FTP all use TCP). In such a case, PF may be more effective: it does not spend processing time comparing TCP packets with the set of rules destined to block UDP datagrams, avoiding delay in processing legitimate packets. Finally, unlike iptables, PF performs automatic optimization of the rule set, processing it in multiple linked lists [7, 8]. A way to optimize the search on the rule set for iptables is to resort to the “jump” parameter [18] for jumping to a subset of rules (i.e., a chain) reserved for TCP or UDP packets, depending on protocol type.

Of course even discounting performance, the iptables rulesets are much less elegant than ipf/pf.