«

I have mulptiple remote sites configured with site-to-site IPSEC VPN's
back to the HQ. Most remote sites have 837 routers while the HQ has a
PIX.
My requirement is to have redundant routes to the HQ from the remote
sites through two different ISP's.
In essence I would like to have two VPN's configured with differing
costs to the HQ network which would allow me to control which tunnel
is used primarily. However, I beleive that this cannot be done as I
cannot associate a cost to a VPN route to the same network.
I can set two peers for the single VPN which would allow me to provide
differing redundant paths into the single network from two ISP's. My
question is ... do you know a way that I can specify which peer should
be used primarily, I would like to provide lower bandwidth on the
second 'redundant' line and would like this peer to be used only if
the primary one is not available. Does the VPN 'attempt' the first
peer in the list always or does it vary?

Many Thanks For Any Assistance

Camac

In article < >,
says...
> I have mulptiple remote sites configured with site-to-site IPSEC VPN's
> back to the HQ. Most remote sites have 837 routers while the HQ has a
> PIX.
> My requirement is to have redundant routes to the HQ from the remote
> sites through two different ISP's.
> In essence I would like to have two VPN's configured with differing
> costs to the HQ network which would allow me to control which tunnel
> is used primarily. However, I beleive that this cannot be done as I
> cannot associate a cost to a VPN route to the same network.
> I can set two peers for the single VPN which would allow me to provide
> differing redundant paths into the single network from two ISP's. My
> question is ... do you know a way that I can specify which peer should
> be used primarily, I would like to provide lower bandwidth on the
> second 'redundant' line and would like this peer to be used only if
> the primary one is not available. Does the VPN 'attempt' the first
> peer in the list always or does it vary?
>

You can do it using any routing protocol that will work over VPN. It's
pretty simple...

--
-Ivan.

*** Use Rot13 to see my eMail address ***

In article < >,
Camac <> wrote:
:I have mulptiple remote sites configured with site-to-site IPSEC VPN's
:back to the HQ. Most remote sites have 837 routers while the HQ has a
IX.

:My
:question is ... do you know a way that I can specify which peer should
:be used primarily, I would like to provide lower bandwidth on the
:second 'redundant' line and would like this peer to be used only if
:the primary one is not available. Does the VPN 'attempt' the first
eer in the list always or does it vary?

On a PIX that has been rebooted, the first peer listed will be
the first tried, and traffic will not be sent to the second
peer unless the first becomes unreachable. However, the PIX would
then continue to use that second peer until it became unreachable:
it will not go back to the first peer automatically. Even clearing
the current security associations is not enough to force the
traffic back to the first peer: according to the command reference,

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.

Thus, if a VPN link times out due to inactivity, then when more
data becomes available, the PIX will attempt to go back to the
peer it was last using, -not- go to the first peer on the list.



Ah, I just noticed an interesting point. Suppose the first peer
connection goes down, and the PIX proceeds to the second peer. Suppose
the link comes back up, and traffic becomes available to the first
remote peer's tunnel. The first remote peer would then attempt to form
an IPSec connection back to the PIX in order to transfer that data.
That's a negotiation request, so if that quoted sentance is correct,
the PIX outbound traffic would then switch over to the first peer
because of the negotion request clause.

This works both ways, though: if the connection has been great on the
first peer, but the second peer gets traffic and so tries to negotiate
a tunnel back to the PIX, then the second peer would then be the latest
one that tried to negotiate, so the traffic would switch over to the
second peer even though there was no problem with the first!

Heh, if your latencies were just right, then if that clause is
accurate, you could end up switching right back again, because there
might be a packet in transit from the first peer that arrives after the
PIX completed the switch to the second peer, so the first would be the
"last peer that the PIX Firewall received" traffic from. I do not,
though, know what [if anything] happens to security associations if a
peer comes along and tries to negotiate that flow. If the old SA's are
kept so that tunnels are built to both peers, then you could
potentially end up switching between the two indefinitely, as responses
come back from the other end and so trigger swapping. Somehow, I
suspect that the quoted sentance is a simplification

This logic is premised upon the remote peer receiving traffic that
needs to be tunneled and so attempting to negotiate. The circumstances
under which it received that traffic would depend on how you configure
the device which choses which of the remote VPN peers to route to. And
the stability of the swap could [if the clause is accurate] depend
whether there is traffic in transit because of latencies in
transmission or latencies in switching over to the new device.


Obviously, the design around the peer choice was not designed with
fallback connections in mind.
--
Everyone has a "Good Cause" for which they are prepared to spam.
-- Roberson's Law of the Internet

In article <> ,
says...
> In article < >,
> says...
> > I have mulptiple remote sites configured with site-to-site IPSEC VPN's
> > back to the HQ. Most remote sites have 837 routers while the HQ has a
> > PIX.
> > My requirement is to have redundant routes to the HQ from the remote
> > sites through two different ISP's.
> > In essence I would like to have two VPN's configured with differing
> > costs to the HQ network which would allow me to control which tunnel
> > is used primarily. However, I beleive that this cannot be done as I
> > cannot associate a cost to a VPN route to the same network.
> > I can set two peers for the single VPN which would allow me to provide
> > differing redundant paths into the single network from two ISP's. My
> > question is ... do you know a way that I can specify which peer should
> > be used primarily, I would like to provide lower bandwidth on the
> > second 'redundant' line and would like this peer to be used only if
> > the primary one is not available. Does the VPN 'attempt' the first
> > peer in the list always or does it vary?
> >
>
> You can do it using any routing protocol that will work over VPN. It's
> pretty simple...
>
>

Hm... to throw some ash to myself (haven't noticed that PIX is on HQ)...
. Bad dog....


--
-Ivan.

*** Use Rot13 to see my eMail address ***

"Walter Roberson" <> wrote in message
news:cl05bo$rku$...
> In article < >,
> Camac <> wrote:
> :I have mulptiple remote sites configured with site-to-site IPSEC VPN's
> :back to the HQ. Most remote sites have 837 routers while the HQ has a
> IX.
>
> :My
> :question is ... do you know a way that I can specify which peer should
> :be used primarily, I would like to provide lower bandwidth on the
> :second 'redundant' line and would like this peer to be used only if
> :the primary one is not available. Does the VPN 'attempt' the first
> eer in the list always or does it vary?
>
> On a PIX that has been rebooted, the first peer listed will be
> the first tried, and traffic will not be sent to the second
> peer unless the first becomes unreachable. However, the PIX would
> then continue to use that second peer until it became unreachable:
> it will not go back to the first peer automatically. Even clearing
> the current security associations is not enough to force the
> traffic back to the first peer: according to the command reference,
>
> 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.
>
> Thus, if a VPN link times out due to inactivity, then when more
> data becomes available, the PIX will attempt to go back to the
> peer it was last using, -not- go to the first peer on the list.
>
>
>
> Ah, I just noticed an interesting point. Suppose the first peer
> connection goes down, and the PIX proceeds to the second peer. Suppose
> the link comes back up, and traffic becomes available to the first
> remote peer's tunnel. The first remote peer would then attempt to form
> an IPSec connection back to the PIX in order to transfer that data.
> That's a negotiation request, so if that quoted sentance is correct,
> the PIX outbound traffic would then switch over to the first peer
> because of the negotion request clause.
>
> This works both ways, though: if the connection has been great on the
> first peer, but the second peer gets traffic and so tries to negotiate
> a tunnel back to the PIX, then the second peer would then be the latest
> one that tried to negotiate, so the traffic would switch over to the
> second peer even though there was no problem with the first!
>
> Heh, if your latencies were just right, then if that clause is
> accurate, you could end up switching right back again, because there
> might be a packet in transit from the first peer that arrives after the
> PIX completed the switch to the second peer, so the first would be the
> "last peer that the PIX Firewall received" traffic from. I do not,
> though, know what [if anything] happens to security associations if a
> peer comes along and tries to negotiate that flow. If the old SA's are
> kept so that tunnels are built to both peers, then you could
> potentially end up switching between the two indefinitely, as responses
> come back from the other end and so trigger swapping. Somehow, I
> suspect that the quoted sentance is a simplification
>
> This logic is premised upon the remote peer receiving traffic that
> needs to be tunneled and so attempting to negotiate. The circumstances
> under which it received that traffic would depend on how you configure
> the device which choses which of the remote VPN peers to route to. And
> the stability of the swap could [if the clause is accurate] depend
> whether there is traffic in transit because of latencies in
> transmission or latencies in switching over to the new device.
>
>
> Obviously, the design around the peer choice was not designed with
> fallback connections in mind.
> --
> Everyone has a "Good Cause" for which they are prepared to spam.
> -- Roberson's Law of the Internet


The newer versions of the Pix OS support OSPF. I would think that this
would be enough to manage the routing as requested and should override the
default behaviors as listed above.

In article <tFOcd.346$>, mmscooby1
@removeme.earthlink.net says...
> The newer versions of the Pix OS support OSPF. I would think that this
> would be enough to manage the routing as requested and should override the
> default behaviors as listed above.
>
>

When I read the OP for the first time, I meant the same. After some more
thinking... You can't drive multicasts trough IPSec Without GRE and not
really sure that PIX supports OSPF 'neighbor' command. It's kind of a
catch...


--
-Ivan.

*** Use Rot13 to see my eMail address ***

In article <tFOcd.346$>,
Scooby <> wrote:
:The newer versions of the Pix OS support OSPF. I would think that this
:would be enough to manage the routing as requested and should override the
:default behaviors as listed above.

I believe that IPSec encapsulation does not take place until after
routing, as crypto maps are associated with an interface,
not with a data flow. Using OSPF, multiple interfaces, and
a crypto map per interface with one peer per flow on each
interface could potentially solve the problem the OP is faced with,
but it would not, I would think, override the behaviours
I described when multiple peers are set for the same flow within
a single crypto map entry.

--
I predict that you will not trust this prediction.

"Scooby" <> wrote in message
news:tFOcd.346$...
> "Walter Roberson" <> wrote in message
> news:cl05bo$rku$...
>> In article < >,
>> Camac <> wrote:
>> :I have mulptiple remote sites configured with site-to-site IPSEC VPN's
>> :back to the HQ. Most remote sites have 837 routers while the HQ has a
>> IX.
>>
>> :My
>> :question is ... do you know a way that I can specify which peer should
>> :be used primarily, I would like to provide lower bandwidth on the
>> :second 'redundant' line and would like this peer to be used only if
>> :the primary one is not available. Does the VPN 'attempt' the first
>> eer in the list always or does it vary?
>>
>> On a PIX that has been rebooted, the first peer listed will be
>> the first tried, and traffic will not be sent to the second
>> peer unless the first becomes unreachable. However, the PIX would
>> then continue to use that second peer until it became unreachable:
>> it will not go back to the first peer automatically. Even clearing
>> the current security associations is not enough to force the
>> traffic back to the first peer: according to the command reference,
>>
>> 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.
>>
>> Thus, if a VPN link times out due to inactivity, then when more
>> data becomes available, the PIX will attempt to go back to the
>> peer it was last using, -not- go to the first peer on the list.
>>
>>
>>
>> Ah, I just noticed an interesting point. Suppose the first peer
>> connection goes down, and the PIX proceeds to the second peer. Suppose
>> the link comes back up, and traffic becomes available to the first
>> remote peer's tunnel. The first remote peer would then attempt to form
>> an IPSec connection back to the PIX in order to transfer that data.
>> That's a negotiation request, so if that quoted sentance is correct,
>> the PIX outbound traffic would then switch over to the first peer
>> because of the negotion request clause.
>>
>> This works both ways, though: if the connection has been great on the
>> first peer, but the second peer gets traffic and so tries to negotiate
>> a tunnel back to the PIX, then the second peer would then be the latest
>> one that tried to negotiate, so the traffic would switch over to the
>> second peer even though there was no problem with the first!
>>
>> Heh, if your latencies were just right, then if that clause is
>> accurate, you could end up switching right back again, because there
>> might be a packet in transit from the first peer that arrives after the
>> PIX completed the switch to the second peer, so the first would be the
>> "last peer that the PIX Firewall received" traffic from. I do not,
>> though, know what [if anything] happens to security associations if a
>> peer comes along and tries to negotiate that flow. If the old SA's are
>> kept so that tunnels are built to both peers, then you could
>> potentially end up switching between the two indefinitely, as responses
>> come back from the other end and so trigger swapping. Somehow, I
>> suspect that the quoted sentance is a simplification
>>
>> This logic is premised upon the remote peer receiving traffic that
>> needs to be tunneled and so attempting to negotiate. The circumstances
>> under which it received that traffic would depend on how you configure
>> the device which choses which of the remote VPN peers to route to. And
>> the stability of the swap could [if the clause is accurate] depend
>> whether there is traffic in transit because of latencies in
>> transmission or latencies in switching over to the new device.
>>
>>
>> Obviously, the design around the peer choice was not designed with
>> fallback connections in mind.
>> --
>> Everyone has a "Good Cause" for which they are prepared to spam.
>> -- Roberson's Law of the Internet
>
>
> The newer versions of the Pix OS support OSPF. I would think that this
> would be enough to manage the routing as requested and should override the
> default behaviors as listed above.

You cannot run ospf over a vpn without gre. I don't think there is any way
to build a gre tunnel on a pix. Ideally, there would be an IOS based router
with IPSec and an accelerator to do this job. Then the op could simply
build a dmvpn. In my opinion, unless the remote sites never need
connections to one another, the pix is the worst cisco device for
terminating multiple lan to lan vpn's at a hq location.

(Walter Roberson) wrote
> I believe that IPSec encapsulation does not take place until after
> routing,

This is a bit of a hobby horse of mine however I find:-

http://www.cisco.com/en/US/tech/tk64...80133ddd.shtml
NAT Order of Operation
Document ID: 6209

to be the most indispensable document on CCO.

It says that crypto happens after EVERYTHING.

"AnyBody43" <> wrote in message
news: om...
> (Walter Roberson) wrote
>> I believe that IPSec encapsulation does not take place until after
>> routing,
>
> This is a bit of a hobby horse of mine however I find:-
>
> http://www.cisco.com/en/US/tech/tk64...80133ddd.shtml
> NAT Order of Operation
> Document ID: 6209
>
> to be the most indispensable document on CCO.
>
> It says that crypto happens after EVERYTHING.

True. However, we are talking about a pix here. Also, an ipsec tunnel
cannot carry the multicasts required for ospf. Also, that would only get
you next hop. In a pure ipsec environment, the peer is not necessarily next
hop. To view the pier as next hop, a gre tunnel would be required. As far
as I know, the PIX can not be a gre endpoint. The closest thing to gre it
can do is pptp which is basically gre with ppp negotiation running atop of
tcp. If this were an IOS router, there are lots of configuration examples.