Re: vpn redundancy PIX and 3000 series
- From: roberson@xxxxxxxxxxxxxxxxxx (Walter Roberson)
- Date: Thu, 8 Dec 2005 18:52:22 +0000 (UTC)
In article <1134061957.882906.85430@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
jbeez <jerodbunch@xxxxxxxxx> wrote:
>Is it possible to have pix501 firewalls and 3002hw clients setup so
>they can vpn into a pix525 firewall, and if the internet connection the
>525 uses goes down, to failover to a 3020 vpn concentrator thats
>connected by a different internet connection?
I do not know about the 3002 hw clients. The PIX 5xx have no difficulty,
at least at the naive level, provided the new peer is reached through
the same interface (and of course the 501 only has one outside interface.)
crypto map TheCryptoMap 100 set peer 123.45.67.8 222.111.0.43
This will start by trying to use 123.45.67.8 but if that is
unreachable or if contact with it is lost, then it will switch over
to 222.111.0.43 .
I say "at the naive level" because when the 525 comes back up,
the 5xx will not notice, and will continue to use 222.111.0.43
until something interrupts that service, at which point it will
try 123.45.67.8 again.
There is -some- provision for switching back, but it involves the
far end starting a connection back to 5xx -- which is not possible
if the 5xx is coming in on a crypto dynamic map (e.g., because it
has a variable IP address.) The documentation on this switch back
is difficult to understand. But if you have a support contract, you
could always ask Cisco what the #$#@#@ the section really means.
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/cmdref/c.htm#wp1035036
"The peer that packets are actually sent to is determined by the last
peer that the PIX Firewall received either traffic or a negotiation
request from for a given data flow. If the attempt fails with the first
peer, IKE tries the next peer on the crypto map list."
Looks clear at first, but suppose you are talking to B and A comes
back up and [knows how to reach you and] asks for the tunnel to be
negotiated. But in the meantime, B, not knowing that A has come up,
is still sending you data. So you could bounce your destination
traffic in between the two depending on accidents of data timing?
Unless, that is, when A came back, as part of the IKE negotiation sequence
it sent along a "clear all SA" token and the "identity" that it
provided matched B's identity... which would have to be an
"ike identity hostname" configuration rather than "ike identity address"
configuration, and A and B would have had to have been set up with
the same hostname. But then B would see the line as having gone down
and if it still has traffic queued to send, it is going to try
to reestablish the link... sending a "clear all SA" as part of the
process and thus knocking A off again...
So unless I'm missing something, the only way you can get the
automatic resumption to work properly is if you are in a configuration
where -something- at the server end is providing routes of different cost
through A and B (and "rip inside default" isn't going to work for that
since you can't attach a cost to that... perhaps you can use
"router ospf default-information originate metric", but it is not clear
you could inject that information over into rip...). Then when A
comes back up, the server traffic starts getting queued against it,
and although there might still be some traffic queued at B, it will
be a limited number of peer bounces before all that traffic has made
it over to the 5xx and A interrupts again and B stops trying to reconnect
because it doesn't have anything to send...
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers
.
- Follow-Ups:
- Re: vpn redundancy PIX and 3000 series
- From: jbeez
- Re: vpn redundancy PIX and 3000 series
- References:
- vpn redundancy PIX and 3000 series
- From: jbeez
- vpn redundancy PIX and 3000 series
- Prev by Date: Re: subnets in access lists...
- Next by Date: Re: IDS & Spoofing -- PIX 6.3(4)
- Previous by thread: vpn redundancy PIX and 3000 series
- Next by thread: Re: vpn redundancy PIX and 3000 series
- Index(es):
Relevant Pages
|