Routing might be a problem, or even changes of routing after tunnel flap. Only recently we made significant improvements in ASA code in this regard.
That being said:
- Are you expecting ASA to initiate traffic or just respond.(There is no problem as far as I know to apply same crypto map to two interfaces, but we sill check routing table to pick which link we will choose to go out through)
- Have you considered using dynamic RP in the tunnels (OSPF to be exact) and route tracking to static default?
I can tell you right now that load balancing will be dificault to achieve, but redundancy might be possible.
what I want is that they work redundancy, both in response to traffic or in initiate traffic. I do not care load balancing. I do not understand if in this time i can use the wan failover. If no, is ther a work around?
I am trying to get Dual ISP VPN IPsec site to site to work.
I have an ASA with SLA tracking on 2 separate Interfaces and IPs - this has an IPsec VPN site to site to another ASA with a single interface and IP
i have tested outbound access fails over fine; all working well.
The issue is with the VPN site to site failover.
if (interesting to VPN) traffic exists in both directions failover "appear" to work ok...
if traffic is less then further investigation shows a problem with "symmetry"
let me clarify
site with 1 ISP pinging destination at site with 2 ISPs via the IPsec tunnel; all is well when primary interface is working.
Now assuming theres no traffic (other than the ping replies above) coming from dual ISP site to singe ISP site then
when the PRI interface is lost on the dual ISP ASA, the SLA tracking it correctly brings up the default route on the secondary interface.
non vpn traffic / nat etc all continues to work fine; but the site to site VPN is broken because although the SA are removed on the dual ISP ASA, the other site is still using the original VPN SA to the (now unavailable) primary address of the dual ISP ASA.
Until this SA on the single ISP ASA is torn down / cleared etc, the VPN will not re-establish.
it will "fix itself" if interesting vpn traffic is sourced from the dual ISP site....
the workaround is to leave interesting traffic (ping -t ) running between sites
or manually clear crypto ips sa/isa sa at the singe ASA site
or reduce SA timers to 120 secs; this is a fudge as it means lots of unneccessary crypto overheads..
I wonder if theres another way or maybe a trick i am missing.
I also am not sure if the bug reference in the previous post is relevant to this issue?
CSCsy19222 Bug Details
below you see the crypto isa sa detail for the
ASAsingleISP(config)# sh cry is sa d
Active SA: 1 Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey) Total IKE SA: 1
1 IKE Peer: 10.10.10.10 Type : L2L Role : initiator Rekey : no State : MM_ACTIVE Encrypt : 3des Hash : SHA Auth : preshared Lifetime: 86400 Lifetime Remaining: 85647 ASAsingleISP(config)#
ASAdualISP(config)# sh cry is sa
There are no isakmp sas ASAdualISP(config)#
it seems to me there needs to be some way for the initiator end to "know" that the other end is not responding, so to try the other peer....
not sure if this is a (lack of a timeout / keepalive / ) or a bug.....
thanks for any inputs
I got this working; I had not got the right isakmp keepalive settings on the tunnel
it works fine now
Message was edited by: firstname.lastname@example.orgI got this working; I had not got the right isakmp keepalive settings on the tunnel
it works fine now
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...