Slashdot Mirror

Lets say you have a Linux iptables firewall that does connection tracking. You allow all outbound connections, but inbound connections must be ESTABLISHED or RELATED. iptables is maintaining state there. Lets say you use keepalived for failover between two firewalls (one that is sitting there as a hot spare). In the event the first firewall crashes and you fail over with keepalived, the state information iptables tracks on the connection is gone, therefore the inbound media that you were streaming would no longer be ESTABLISHED or RELATED unless the client made another outbound connection. If I understand the parent to your comment, OpenBSD's pf has the ability to track connection state between the failover boxes, thus eliminating this problem. See this.

So use pfsync and CARP on your OpenBSD-based routers running on commodity hardware and have more redundant ones. Have your router automatically email you when fail-over happens (and you're down to only two or three spares) and you can throw the broken one in the bin and replace it with a new one at your leisure, and still be cheaper than Cisco.

Linux-HA fails firewalls just fine.
Linux-HA will failover the IP address but it does not share state between the firewalls so has the potential to break long-running connections. OpenBSD can be configured to share the stateful inspection table using pfsync see here.

You always has OpenBSD that comes with pf (packet filter), CARP (redundancy) and pfsync (firewall synchronizing)

You can find an example here

CARP: http://www.countersiege.com/doc/pfsync-carp/

OpenBSD to the rescue. I've heard CARP has been ported to FreeBSD a few months ago. Perhaps we'll see something like this in Linux sometime soon.

I've personally used LVS in a 2.6 kernel using keepalived (honestly probably the single most useful programs I've ever used, its exceptionally great software) to deploy a Mail cluster supporting SMTP/POP3 (and their SSL counterparts) in addition to Webmail over HTTP/HTTPS. It worked very well. I used dual Opteron 242's in MSI K1-1000 Chassis with a RaidZone RAID10 backend, it worked phenominally well.

SMTP, POP3, and HTTP are very forgiving protocols with respect to an LVS node going down, because people will simply either "re-check" their mail, click refresh or the software will wait long enough to be reconnected. Obviously any streaming software suffers, but this is why I mentioned CARP.

CARP: http://www.countersiege.com/doc/pfsync-carp/ OpenBSD to the rescue. I've heard CARP has been ported to FreeBSD a few months ago. Perhaps we'll see something like this in Linux sometime soon. I've personally used LVS in a 2.6 kernel using keepalived (honestly probably the single most useful programs I've ever used, its exceptionally great software) to deploy a Mail cluster supporting SMTP/POP3 (and their SSL counterparts) in addition to Webmail over HTTP/HTTPS. It worked very well. I used dual Opteron 242's in MSI K1-1000 Chassis with a RaidZone RAID10 backend, it worked phenominally well. SMTP, POP3, and HTTP are very forgiving protocols with respect to an LVS node going down, because people will simply either "re-check" their mail, click refresh or the software will wait long enough to be reconnected. Obviously any streaming software suffers, but this is why I mentioned CARP.

You might want to look into OpenBSD and CARP.

Firewall Failover

"In test environments, we have run up to 4 pfsync+carp hosts (all different architectures: i386, sparc, sparc64, and amd64!), randomly rebooting them. TCP sessions were not interrupted through over two days of such torture testing."

Linux has UCARP, but has no way for the stateful firewall to do transparent failover.

Don't really feel like researching enough detail for a comprehensive summary of the other stuff.

The two main components provided by OpenBSD are CARP (the Common Address Redundancy Protocol), which allows a backup host to assume the identity of the primary, and pfsync, which ensures that firewall states are synchronised so that the backup can take over exactly where the master left off and no connections will be lost.

CARP
The Common Address Redundancy Protocol manages failover at the intersection of Layers 2 and 3 in the OSI Model (link layer and IP layer). Each CARP group has a virtual MAC (link layer) address, and one or more virtual host IP addresses (the common address). CARP hosts respond to ARP requests for the common address with the virtual MAC address, and the CARP advertisements themselves are sent out with this as the source address, which helps switches quickly determine which port the virtual MAC address is currently "at".

The master of the address sends out CARP advertisement messages via multicast using the CARP protocol (IP Protocol 112) on a regular basis, and the backup hosts listen for this advertisement. If the advertisements stop, the backup hosts will begin advertising. The advertisement frequency is configurable, and the host which advertises most frequently is the one most likely to become master in the event of a failure.

A reader who is familiar with VRRP will find this is somewhat familiar, however there are some significant differences:

* The CARP protocol is address family independent. The OpenBSD implementation supports both IPv4 and IPv6, as a transport for the CARP packets as well as common addresses to be shared.
* CARP has an "arpbalance" feature that allows multiple hosts to share a single IP address simultaneously; in this configuration, there is a virtual MAC address for each host, but only one IP address.
* CARP uses a cryptographically strong SHA-1 HMAC to protect each advertisement.

Besides these technical differences, there is another significant difference (perhaps the most important one, in fact): CARP is not patent encumbered. See this page for details on the history of CARP and our reasons for avoiding a VRRP implementation.

pfsync
pfsync transfers state insertion, update, and deletion messages between firewalls. Each firewall sends these messages out via multicast on a specified interface, using the PFSYNC protocol (IP Protocol 240). It also listens on that interface for similar messages from other firewalls, and imports them into the local state table.

In order to ensure that pfsync meets the packet volume and latency requirements, the initial implementation has no built-in authentication. An attacker who has local (link layer) access to the subnet used for pfsync traffic can trivially add, change, or remove states from the firewalls. It's possible to run the pfsync protocol on one of the "real" networks, but because of the security risks, it is strongly recommended that a dedicated, trusted network be used for pfsync. This can be as simple as a crossover cable between interfaces on two firewalls