[TriLUG] BSD/Linux firewall with multiple ISP and failover?

[Aaron S. Joyner]

Jon Carnes wrote:

>On Sat, 2006-01-28 at 17:04, Aaron S. Joyner wrote:
>
>  
>
>>You want something that allows you to have multiple paths to the 
>>internet, and should one of those paths die, you want to switch to using 
>>the alternate path.  This is actually a very easy thing to do, and only 
>>requires a second ethernet interface in the firewall in question (note 
>>the word interface, not network card, as technically this could be done 
>>with a managed switch, vlans, and some craziness if you want to keep 
>>your existing hardware platform)
>>
>>... detail snipped...
>>
>>Come back and post again if you can't get it working correctly.  :)
>>
>>Good luck Greg,
>>Aaron S. Joyner
>>    
>>
>
>Hmmm, interesting but a bit complex. I prefer to simply have the
>secondary take over the IP address of the primary - when the primary
>goes down.
>
>... detail snipped...
>
>===
>I like this because the Fail-over server does all the checking. It uses a secondary network (192.168.10.0) that is shared with the Primary Firewall. All testing is done across the secondary network. This lets you manipulate the primary network (192.168.1.0) and move the gateway for that network anytime you want, while still letting you test to see if the Primary Firewall comes back up.
>
>It's elegant and it works great.
>Good Luck - Jon Carnes
>  
>
I don't disagree that your solution is elegant and effective, Jon.  It 
just solves a different problem.  :)  You're solving the problem of 
firewall redundancy, and getting multiple internet paths as a sort of 
bonus.  In the scenario you describe, consider what happens if the 
internet connection of the first server fails, but the internal 
interface of the server is quite happy and responding to pings.  This 
isn't at all uncommon, for example when the ISP has issues, you have a 
DSL modem die, there's a line cut outside your buliding and DSL or Cable 
sync goes away, etc, etc.  The failover test will not detect a failover, 
and internet service for the internal network goes away, even though 
there is a usable internet connection connected to the 'failover' 
server.  You could expand on your failover script by setting up a few 
static routes on the failover server to route through the 192.168.10.1 
IP address and ensure you can actually ping those remote IPs through the 
first server, which would give you a better understanding of if the 
actual "internet" connection is working.  You'd also want to ensure that 
the 'failover' ISP is working before you try and switch, or you'll end 
up in a scenario where things constantly switch back and forth to no 
effect, because neither ISP is functional.  At this point, you will have 
implemented the solution I suggested, minus a tiny bit of complexity 
with iproute rules, because you used two seperate routing tables on two 
seperate pieces of hardware, instead of two routing tables on one piece 
of server.  It also naturally requires throwing more hardware at the 
problem, when in Greg's original case it sounds like he wants to keep 
hardware to a minimum (fanless box, etc).  I don't disagree that he 
should consider the box as likely a point of failure as the internet 
connection, though, so going in the over-all direction you describe is 
still not a bad idea.

Aaron S. Joyner