| Author |
Message |
jbeez
Guest
|
 Posted:
Thu Dec 08, 2005 5:20 pm Post subject:
vpn redundancy PIX and 3000 series |
|
|
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?
-J |
|
| Back to top |
|
 |
Walter Roberson
Guest
|
| Posted:
Thu Dec 08, 2005 6:52 pm Post subject:
Re: vpn redundancy PIX and 3000 series |
|
|
In article <1134061957.882906.85430@z14g2000cwz.googlegroups.com>,
jbeez <jerodbunch@gmail.com> wrote:
| Quote: | 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 |
|
| Back to top |
|
|
Walter Roberson
Guest
|
| Posted:
Thu Dec 08, 2005 8:52 pm Post subject:
Re: vpn redundancy PIX and 3000 series |
|
|
In article <1134072808.022333.152450@o13g2000cwo.googlegroups.com>,
jbeez <jerodbunch@gmail.com> wrote:
| Quote: | 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,
|
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..
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26) |
|
| Back to top |
|
|
jbeez
Guest
|
| Posted:
Fri Dec 09, 2005 2:13 am Post subject:
Re: vpn redundancy PIX and 3000 series |
|
|
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 Roberson wrote:
| Quote: | In article <1134061957.882906.85430@z14g2000cwz.googlegroups.com>,
jbeez <jerodbunch@gmail.com> 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 |
|
|
| Back to top |
|
|
Walter Roberson
Guest
|
| Posted:
Fri Dec 09, 2005 8:36 pm Post subject:
Re: vpn redundancy PIX and 3000 series |
|
|
In article <1134158858.590388.52790@f14g2000cwb.googlegroups.com>,
jbeez <jerodbunch@gmail.com> wrote:
| Quote: | 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.
|
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.)
--
All is vanity. -- Ecclesiastes |
|
| Back to top |
|
|
jbeez
Guest
|
| Posted:
Sat Dec 10, 2005 2:07 am Post subject:
Re: vpn redundancy PIX and 3000 series |
|
|
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 |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in