From: Alexei Monastyrnyi (alexeim73@gmail.com)
Date: Tue Jan 20 2009 - 11:29:55 ARST
Hi fellow engineers.
I am having troubles configuring VPN tunnel failover between two sites.
Here is a setup.
I am running ASA 5510 code 7.2.4 on HQ and a branch office. HQ is
multi-site with primary and backup Internet connections.
Branch office is single site and has the following ctypto map towards HQ:
crypto map mymap 17227 match address ipsec-branch-hq
crypto map mymap 17227 set connection-type originate-only
crypto map mymap 17227 set peer asa-shq-prim asa-hq-bkp
crypto map mymap 17227 set transform-set 3des
HQ units have the following crypto maps for that branch:
crypto map mymap 152 match address ipsec-hq-branch
crypto map mymap 152 set connection-type answer-only
crypto map mymap 152 set peer asa-branch
crypto map mymap 152 set transform-set 3des
crypto map mymap 152 set reverse-route
I use RRI for subnets available behind that VPN tunnel and further
redistribution to OSPF inside HQ LAN to have the correct exit point for
the traffic from HQ towards the branch depending on which of prim/bkp
peers is active.
ISAKMP keepalives are enabled (by default) for corresponding L2L tunnel
groups across the board with 10 seconds between keepalives and 2 seconds
between retries (defaults as well).
VPN tunnel comes up fine between branch and either of hq sites when it
is one peer on the branch side. There is a constant interesting traffic
initiated by branch LAN towards HQ.
I have an out-of-band connection to all 3 units and if I route traffic
from branch peer IP to hq-prim peer IP to null (and vice versa) it takes
ages for the tunnel to failover to hq-bkp. Same happens if I enable
connectivity between branch and prim but break it between branch and hq-bkp.
I checked if they have made any improvements regarding L2L VPN failover
or if there were any open/resolved caveats in later versions of ASA
code, but it doesn't seem to be the case.
Any suggestions?
Cheers,
A.
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:43:39 ARST