Simplest failover solution for iptables firewall (router)

Simplest failover solution for iptables firewall (router)

[Anton Melser]

Hi,
Now that I have my policy-based routing NAT FW working as expected
(thanks for everyone's previous comments!), I would like it to be
resilient. The more I think about it the less I want to bother with
true HA (so keeping track of connections). My solution can handle
20-30 seconds of downtime with no real problems. And if on the odd
occasion it went up to 2-3 minutes it wouldn't actually be that much
of a biggie either. Basically, I just don't want to be woken up at
3:54am on a Tuesday morning because of a kernel panic :-). If it can
wait t'ill 7:30 then that is all the resilience I actually need.
The keys here are simplicity and resources. It should be as simple as
possible, and shouldn't require very much in terms of memory and
processor resources. I could possibly even get away with scripting
something up in bash but I would much rather not as I'm very lazy :-).
Does anyone have experience with such a setup? It looks as though at a
minimum there is keepalived and pacemaker+heartbeat. Is one
better/worse for a specialised firewal box?
Thanks
Anton

Re: Simplest failover solution for iptables firewall (router)

[Jon Lewis]

On Mon, 9 Jan 2012, Anton Melser wrote:

> Now that I have my policy-based routing NAT FW working as expected
> (thanks for everyone's previous comments!), I would like it to be
> resilient. The more I think about it the less I want to bother with
> true HA (so keeping track of connections). My solution can handle
> 20-30 seconds of downtime with no real problems. And if on the odd
> occasion it went up to 2-3 minutes it wouldn't actually be that much

Heartbeat can do this.  You'll want to setup something (could just be a 
shell script either run by hand or by cron) to rsync certain things like 
the iptables config to the standby FW...and setup a cron job on the 
standby FW to restart iptables when necessary, i.e.

# has iptables been updated?
* * * * * root test /etc/sysconfig/iptables -nt /var/lock/subsys/iptables && service iptables restart

Setup properly, if FW1 dies or loses its uplink, etc., FW2 will take over, 
and open connections will be lost, but other than that, life will go on.

> Does anyone have experience with such a setup? It looks as though at a
> minimum there is keepalived and pacemaker+heartbeat. Is one
> better/worse for a specialised firewal box?

I've been using the old heartbeat (comes with CentOS/RHEL 4/5.x) for this. 
As of 6.x, heartbeat is deprecated and you're expected to use pacemaker 
instead.

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

Re: Simplest failover solution for iptables firewall (router)

[Anton Melser]

...
> Heartbeat can do this.  You'll want to setup something (could just be a
> shell script either run by hand or by cron) to rsync certain things like the
> iptables config to the standby FW...and setup a cron job on the standby FW
> to restart iptables when necessary, i.e.
>
> # has iptables been updated?
> * * * * * root test /etc/sysconfig/iptables -nt /var/lock/subsys/iptables &&
> service iptables restart
>
> Setup properly, if FW1 dies or loses its uplink, etc., FW2 will take over,
> and open connections will be lost, but other than that, life will go on.

That's perfect.

> I've been using the old heartbeat (comes with CentOS/RHEL 4/5.x) for this.
> As of 6.x, heartbeat is deprecated and you're expected to use pacemaker
> instead.

Perfect thanks. I'll give it a try this weekend.
Cheers
Anton

Re: Simplest failover solution for iptables firewall (router)

[Michal Soltys]

On 12-01-09 22:11, Anton Melser wrote:
> Hi,
> Does anyone have experience with such a setup? It looks as though at a
> minimum there is keepalived and pacemaker+heartbeat. Is one
> better/worse for a specialised firewal box?

There's also a carp port usable in linux:

http://www.ucarp.org/project/ucarp

In particular, check:
http://download.pureftpd.org/pub/ucarp/README

No firsthand experience though, but paired with conntrackd it's reported 
to work fine.