vpn redundancy PIX and 3000 series

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.

"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...

I am using easyvpn on the 501s, and I'm not so concerned with the

3002hw clients because I've been slowly making the branch managers replace those with pix 501s, for some reason the performance on the 501s is dominating the 3002hw clients for our branches, everyone we replace is telling us how much better their connection is after its replaced.

So I was just reading up some more and found a setup for pix to pix easyvpn setup. I just need to figure out how I'm going to do routing instead of the static routes, and how I'm going to have some sort of authentication sharing between the 3020 and the pix525 because right now all the branches are setup to authenticate to the 3020 internal user database.

-J

Walter Robers> > >Is it possible to have pix501 firewalls and 3002hw clients setup so

It's a non-trivial hurdle. Consider the possibilities that will have to be dealt with:

a) the 525 goes down.

a1) Was it broadcasting routing information directly to all the internal hosts -- if so, then it will stop broadcasting and the (somehow) higher cost info for the 3xxx will come to the forefront and things might work. But this depends upon the 525 or 3xxx being able to broadcast routes of different metrics, and depends upon all the internal hosts being able to listen to that same kind of routing information. Including, for example, the printers.

a2) Was the 525 not directly broadcasting the routing information, and instead some internal router was deciding between the 525 and 3xxx? If so then can the internal router detect that the PIX is dead and switch routes?

b) the 525 hangs but the NIC stays up

b1) direct broadcasts would stop, as per a1.

b2) Will the internal router be able to detect that the 525 is down even though its ethernet link is still up?

c) the 525 wedges, stays up and still responds to pings, but stops passing traffic beyond itself

c1) directly broadcast routes might or might not keep going

c2) would the internal router be able to detect that the 525 is functionally down even though it answers pings?

d) the 525 stays up, but the ISP WAN link goes down

d1) In PIX 6.x, the 525 cannot itself detect that an interface is down (don't know about 7.0), so the 525 will keep broadcasting routes

d2) the 525 would still be happy to answer pings, so can the router figure out the 525 ISP interface is dead?

e) the 525 stays up, the ISP WAN link stays up, but the router at the other end of the ISP WAN link has stopped listening

e1) this tends to affect ADSL especially: the "last mile" link to the ISP tends to say up but the PPPoE server fails

f) the 525 stays up, the ISP WAN link stays up, but something else on the route inbetween dies

g) ... something on the route inbetween gets overcongested and starts dropping large numbers of packets, possibly dropping bursts, possibly dropping individual packets as far as your server end can tell; throughput gets completely trashed

h) due to hardware or software or power-supply fault, the 525 starts into a cycle of reboots, coming up for short times and going down again

h1) going back down after it has been alive long enough to answer pings but not long enough to have started up the tunnel negotiation

h2) going back down mid-way through negotiations

h3) going back down after the tunnel has been back up a short time

i) there is no i.

j) Vincent C. Jones wrote a book about what can go wrong in these kinds of setups..

I haven't given enough information, let me explain a little more.

I have a fiber ring comming into a managed switch owned by my primary isp, I recieve an ethernet port off of that for 10mbit up/down of bandwidth. That goes to a WAN vlan, my pix has an interface into the wan vlan. Inside, none of my workstations, printers, etc point to the pix for their default route, everything is routed through a L3 core switch, we have several vlans routing through this.

The 3020 has it's wan connection in our wan vlan, right on our public block. The core switch *currently* has a static route for 10.2/16 to point to the internal interface of the 3020, and the remote sites are of course 10.2/16 subnets. I am currently looking into OSPF to handle interrior routing so I can dump that static route, that way they can terminate on either the 3020 or the pix. As far as internet goes, I also have a ds3 comming in for a PRN circuit, I'll be converting that to a standard internet connection and working on a BGP setup for my wan netblock to be routed on both internet providers. How they will play together, I have yet to determine. That would handle the internet provider going down, and then I guess the only thing left for this redundancy excercise here would be incase of an equipment failure I would have a backup. I wonder if a failover pix unit would take over the vpn tunnels on it too? hrm

-J

Okay, in that case go back to my previous posting and re-read it, skipping (a1), (b1), (c1). For each scenario you propose, ensure that the setup will handle everything else I posted about.

e.g., you talk about OSPF, but what mechanism will the device generating OSPF use to be able to detect that your fibre is lit but the remote router has taken a bathroom break ?

Then go read Vincent C. Jones' whitepapers, and see if you can find a copy of his book. (It's out of print, so it'd have to be a used copy so Vincent won't earn anything from your purchase -- but on the other hand, if there's a lively trade in used copies, it helps make the case for a reprint or new edition.)