firewall sandwich load balancing (fwd)

[David Lang]

On Fri, 7 Jul 2006, Roberto Nibali wrote:

>>> Are you talking about a setup as described for example in chapter 19 of 
>>> this:
>>> 
>>> http://www116.nortelnetworks.com/docs/bvdoc/alteon/appl_switch/315394-J.00.pdf 
>> looking this up now...
>> I can't follow the link. I'll have to dig through the site to try and find 
>> it.
>
> Try this one:
>
> http://tinyurl.com/e54yy

I'm reading it now, with the basic approach it looks like it's doing the job, 
but since they are load balancing servers as well as firewalls it is looking 
very ugly in it's configuration. With this as your introduction to the concept 
it's no wonder you find it to be a hack and unreliable.

the four-subnet approach is what I'm talking about, but with the addition of an 
additional load balancer on the fourth subnet to do the server load balancing, 
so everything else can pretend that there is only a single server.

the whole business with setting the outbound routes is a mess, they use the 
free-metric option as an advanced thing, but if I'm reading it right a 
four-subnet free-metric config is the simplest of the ones they show (at least 
to configure) and probably the most reliable as well.

thanks for sending me this link, it's convinced me to stay well away from the 
nortel load balancers (they were questionable in terms of capacity to begin 
with)

>>>> I am trying to find an option that doesn't have the firewall being a 
>>>> single point of failure. yes, if these were linux firewalls I could use 
>>>> heartbeat (linux-ha) to provide failover, but that can't load balance, 
>>>> and it doesn't work if I use commercial firewalls instead of linux
>>> 
>>> If you buy a commercial firewall, you will most probably have some sort of 
>>> built-in failover.
>> 
>> there are a couple huge advantages of not useing the built-in failover for 
>> commercial firewalls
>> 
>> 1. with external boxes you can have firewalls of different types that you 
>> failover/load balance between (avoiding vendor lock-in and you have a much 
>> easier time dealing with major upgrades of a single vendors firewalls)
>
> I don't understand the term "vendor lock-in". The way I sometimes deal with 
> major upgrades in business critical environments is to have a pilot/test 
> network setup up as equal to the existing as possible. Then either retransmit 
> some captured traffic for point-testing or using port-mirroring to test the 
> upgrade. The upgrade process itself can easily be tested in such a setup. 
> This works perfect with Raptor/Axent firewalls or Checkpoint or our firewall.

at high bandwidth levels it's really hard to test things properly in a lab. As 
such there's a huge sigh of relif when you can put in one of the new ones but 
have things configured so that if something goes wrong it fails over to the old 
one. this is hard enough to do with a single vendor useing their HA solution (it 
frequently breaks across major version upgrades, just when you need it the most) 
but people still fall into the 'well, it's just an upgrade of the existing 
product, that's less risky then changing to another vendor's product'. with 
external load boxes this doesn't matter and you can do major changes with very 
little risk (since anything that goes wrong will just put you back where you 
started)

> Thanks for the interesting discussion and sorry for wasting your time without 
> giving you a workable solution,

it's never a waste of time to explain the problem in more detail, I attempted to 
simplify things that apparently caused more confusion when the intent was to 
avoid introducing distractions.

David Lang