Vincent C Jones wrote:
> In article <Nch4c.8253$E73.2831@fe29.usenetserver.com>,
> Illusion <spam@myarse.com> wrote:
>>>> Hi,
>>>>
>>>> We have two Internet routers with firewalls downsteam of them - we
>>>> only use one as primary and one as failover - they arent load
>>>> balanced or multihomed or anything. Currently the firewalls
>>>> originate the default routes which is OK if the primary firewall
>>>> goes down then it fails over to the backup connection. But if
>>>> something upstream of the primary firewall goes down the firewall
>>>> wont know will it? If the link between the firewall and the router
>>>> goes down i'm guessing the firewall would know and would stop
>>>> originating the default route. But what if there is just no
>>>> response from the Internet router but the link is still up? I
>>>> think the
>>>> firewall will still originate the default route?
>>>>
>>>> If I run OSPF on our primary Internet router and originate the
>>>> deafult route from there, then that will solve the above issue I
>>>> think? But then what about upstream of our Internet router i.e our
>>>> ISP's end? What happens if the previous situation applies to this
>>>> part of the link i.e our link is still up but the remote router
>>>> does
>>>> not respond to IP? Is there some sort of keepalive that can be used
>>>> or does this happen by default in the OSPF protocol?
>>>>
>>>> Sorry if thats a bit confusing but thanks in advance for any help.
>>>>
>>>> Cheers, Dan
>>>
>>> Been there, done that... Routing through a firewall is generally a
>>> bad idea for security. If you chose to use OSPF, make sure that it
>>> is only used to determine if the firewall is connected and not as a
>>> means to learn routes (be very careful of what routes learned by
>>> one side of
>>> the firewall are passed on to routers on the other side of the
>>> firewall...
>>> think about what will happen to your network when an untrusted
>>> device outside the firewall starts advertising reachability of
>>> internal destinations or otherwise does what you did not program it
>>> to do...)
>>>
>>> See the white paper "Configuration for Transparently Redundant
>>> Firewalls" on my web site for how I solved the problem back in the
>>> days before firewalls ran routing protocols. There are more details
>>> in
>>> my book.
>>>
>>> Good luck and have fun!
>>
>> Hi Vincent,
>>
>> Thanks for the link, a very interesting read and a desirable setup!
>> But unfortunately we do not have the hardware or budget to
>> accomplish something like that :-(
>>
>> I have OSPF setup only on the internal network cards of the
>> firewalls, to learn internal routes. So they only know of internal
>> routes and have a deafult route to their respective Internet
>> routers. They each originate a default route, with a higher metric
>> for the firewall connected to the slower backup Internet link. I
>> dont run OSPF on the DMZ interfaces or the external interfaces
>> currently.
>>
>> This works good if the primary firewall fails, but what i want to
>> try and work out is how to be aware of the primary internet router
>> failing, and the router upstream of our Internet router (which is
>> connected via 10MB metro Ethernet circuit).
>>
>> If I run OSPF on the primary Internet router I could stop the
>> firewall from advertising internal routes to it, which would make it
>> a bit more secure.
>>
>> How can I be aware of failures of the ISP's router or that end of
>> the link?
>>
>> Thanks for any info,
>>
>> Cheers, Dan
>
> Run BGP between your primary Internet router and its ISP (see Chapter
> 8
> for some ideas :-) or the multihoming white paper for a quick
> summary), inject a default route into OSPF based on BGP seeing the
> Internet so
> your firewall knows you have a connection.
>
> ISP won't run BGP? Live life on the bleeding edge and look at using
> "ping based routing table entries" recently introduced in 12.3T to
> determine whether or not to introduce a default route. This could be
> done on the inside router as long as you let ICMP echo & echo response
> through your firewalls.
>
> Hint: Install a mechanism to routinely verify your backup path works,
> or
> you will discover the hard way that when you need it, you should have
> called in a repair order earlier...
>
> Good luck and have fun!

Thanks again Vincent, will look into this!

Cheers, Dan