Would like confirmation if asa checks routing table before crypto
maps.  I have a pt-pt link between two sites that is terminating on
asas and would like to have a backup internet tunnel terminating on
the same asas.  Is this possible?

On Thu, 25 Oct 2007 22:26:04 +0000, linguafr wrote:

> Would like confirmation if asa checks routing table before crypto
> maps.  I have a pt-pt link between two sites that is terminating on
> asas and would like to have a backup internet tunnel terminating on
> the same asas.  Is this possible?

For outgoing traffic the ASA should check routing table before crypto maps.

"Ingolf" <ingolf@please.nomail> wrote in message 
news:ffsgcr$bnn$1@tapir.blue-cable.net...
> On Thu, 25 Oct 2007 22:26:04 +0000, linguafr wrote:
>
>> Would like confirmation if asa checks routing table before crypto
>> maps.  I have a pt-pt link between two sites that is terminating on
>> asas and would like to have a backup internet tunnel terminating on
>> the same asas.  Is this possible?
>
> For outgoing traffic the ASA should check routing table before crypto 
> maps.

Your right  ,  and it's important to understant it if you have tunnels  on 
multi-interfaces
PIX or ASA .  If you apply a cryptomap on an interface  you must make sure 
that
the inside subnet of your VPN peer  is routed on the interface your crypto 
is applied.

We rarelly think about it because  we usually  have a default route on the 
outside interface
where the crypto is applied . But if you apply your crypto on a third 
interface , then you will need
a route statement for the Peer ip address  AND a route statement for the 
peer  inside subnet.

 route [tunnel interface] [Peer ip address] [gateway of your tunnel 
interface]
 route [tunnel interface] [Peer inside subnet] [whatever address from the 
tunnel interface]

Why  [whatever address from the tunnel interface] ?  Because  once the 
packet is routed on the
interface itself , it will trigger the crypto map . And the packet , once 
encrypted,  uses
the first route statement .

If you want to test this  in lab , just plug two PIX  outside interfaces 
togheter and build a VPN .
Let say PIX1  have  10.1.1.1 255.255.255.0  on the outside   and  PIX2 
10.1.1.2 255.255.255.0.

Since  both peers IP are on the same subnet , you would think that you don't 
need any route.
Error ,  the VPN will not work .  Now add a route statement

route outside 0.0.0.0 0.0.0.0 10.1.1.3

And the VPN will work  even  if  10.1.1.3  is unreachable .

I think  the  "route command"  should allow to omit the gateway . It's not 
very logical to
resolve a routing problem by adding a route pointing to a gateway that don't 
even exist.


I know that from  7.0 , there is now  a "tunneled"  parameters , but i 
haven't play with it yet
and by reading the doc  i am not sure  it address this  routing 
fuzziness.... 

On Oct 26, 9:13 am, "mcaissie" <mcais...@nospam.sympatico.ca> wrote:
> "Ingolf" <ing...@please.nomail> wrote in message
>
> news:ffsgcr$bnn$1@tapir.blue-cable.net...
>
> > On Thu, 25 Oct 2007 22:26:04 +0000, linguafr wrote:
>
> >> Would like confirmation if asa checks routing table before crypto
> >> maps.  I have a pt-pt link between two sites that is terminating on
> >> asas and would like to have a backup internet tunnel terminating on
> >> the same asas.  Is this possible?
>
> > For outgoing traffic the ASA should check routing table before crypto
> > maps.
>
> Your right  ,  and it's important to understant it if you have tunnels  on
> multi-interfaces
> PIX or ASA .  If you apply a cryptomap on an interface  you must make sure
> that
> the inside subnet of your VPN peer  is routed on the interface your crypto
> is applied.
>
> We rarelly think about it because  we usually  have a default route on the
> outside interface
> where the crypto is applied . But if you apply your crypto on a third
> interface , then you will need
> a route statement for the Peer ip address  AND a route statement for the
> peer  inside subnet.
>
>  route [tunnel interface] [Peer ip address] [gateway of your tunnel
> interface]
>  route [tunnel interface] [Peer inside subnet] [whatever address from the
> tunnel interface]
>
> Why  [whatever address from the tunnel interface] ?  Because  once the
> packet is routed on the
> interface itself , it will trigger the crypto map . And the packet , once
> encrypted,  uses
> the first route statement .
>
> If you want to test this  in lab , just plug two PIX  outside interfaces
> togheter and build a VPN .
> Let say PIX1  have  10.1.1.1 255.255.255.0  on the outside   and  PIX2
> 10.1.1.2 255.255.255.0.
>
> Since  both peers IP are on the same subnet , you would think that you don't
> need any route.
> Error ,  the VPN will not work .  Now add a route statement
>
> route outside 0.0.0.0 0.0.0.0 10.1.1.3
>
> And the VPN will work  even  if  10.1.1.3  is unreachable .
>
> I think  the  "route command"  should allow to omit the gateway . It's not
> very logical to
> resolve a routing problem by adding a route pointing to a gateway that don't
> even exist.
>
> I know that from  7.0 , there is now  a "tunneled"  parameters , but i
> haven't play with it yet
> and by reading the doc  i am not sure  it address this  routing
> fuzziness....

I'm running ospf over the pt-pt, so, my assumption is that if that
goes down and the ospf route goes away, this traffic will take the
default route via a tunnel

"linguafr" <billf@lfnetworking.com> wrote in message 
news:1193419553.770317.278430@q5g2000prf.googlegroups.com...
> On Oct 26, 9:13 am, "mcaissie" <mcais...@nospam.sympatico.ca> wrote:
>> "Ingolf" <ing...@please.nomail> wrote in message
>>
>> news:ffsgcr$bnn$1@tapir.blue-cable.net...
>>
>> > On Thu, 25 Oct 2007 22:26:04 +0000, linguafr wrote:
>>
>> >> Would like confirmation if asa checks routing table before crypto
>> >> maps.  I have a pt-pt link between two sites that is terminating on
>> >> asas and would like to have a backup internet tunnel terminating on
>> >> the same asas.  Is this possible?
>>
>> > For outgoing traffic the ASA should check routing table before crypto
>> > maps.
>>
>> Your right  ,  and it's important to understant it if you have tunnels 
>> on
>> multi-interfaces
>> PIX or ASA .  If you apply a cryptomap on an interface  you must make 
>> sure
>> that
>> the inside subnet of your VPN peer  is routed on the interface your 
>> crypto
>> is applied.
>>
>> We rarelly think about it because  we usually  have a default route on 
>> the
>> outside interface
>> where the crypto is applied . But if you apply your crypto on a third
>> interface , then you will need
>> a route statement for the Peer ip address  AND a route statement for the
>> peer  inside subnet.
>>
>>  route [tunnel interface] [Peer ip address] [gateway of your tunnel
>> interface]
>>  route [tunnel interface] [Peer inside subnet] [whatever address from the
>> tunnel interface]
>>
>> Why  [whatever address from the tunnel interface] ?  Because  once the
>> packet is routed on the
>> interface itself , it will trigger the crypto map . And the packet , once
>> encrypted,  uses
>> the first route statement .
>>
>> If you want to test this  in lab , just plug two PIX  outside interfaces
>> togheter and build a VPN .
>> Let say PIX1  have  10.1.1.1 255.255.255.0  on the outside   and  PIX2
>> 10.1.1.2 255.255.255.0.
>>
>> Since  both peers IP are on the same subnet , you would think that you 
>> don't
>> need any route.
>> Error ,  the VPN will not work .  Now add a route statement
>>
>> route outside 0.0.0.0 0.0.0.0 10.1.1.3
>>
>> And the VPN will work  even  if  10.1.1.3  is unreachable .
>>
>> I think  the  "route command"  should allow to omit the gateway . It's 
>> not
>> very logical to
>> resolve a routing problem by adding a route pointing to a gateway that 
>> don't
>> even exist.
>>
>> I know that from  7.0 , there is now  a "tunneled"  parameters , but i
>> haven't play with it yet
>> and by reading the doc  i am not sure  it address this  routing
>> fuzziness....
>
> I'm running ospf over the pt-pt, so, my assumption is that if that
> goes down and the ospf route goes away, this traffic will take the
> default route via a tunnel
>

I don't see any reason why it wouldn't work. And you can easily test the 
tunnel
without rerouting everything . You can just add a static route  for  PC1 to 
PC2 on your outside interface and it will have precedence over the ospf 
route.