08-04-2010 02:42 AM
Hello!
Periodically we are suffering a problem with L2L tunnel between 5505 and 5520
Sometimes there is no access from 5505's local LAN to one of the 5520's LAN
ex: ping from inside interface 5505 (10.1.13.1) to 5520 (10.1.1.1) doesn't work
5505:
- from cry isa sa we can see the peer - it's OK
- in cry ip sa pe there is the necessary sa, but encaps doesn't increase and still no ping
- all other sa's from the acl work correctly
Debug from 5505:
%ASA-3-713042: IKE Initiator unable to find policy: Intf outside, Src: 10.1.13.1, Dst: 10.1.1.1
%ASA-3-313001: Denied ICMP type=8, code=0 from 10.1.1.1
ACL's on both sides are correct
clear isakmp sa helps to solve the problem
p.s. asa 5505 has two isp and two different crypto maps with 5520
Solved! Go to Solution.
08-04-2010 03:39 AM
does this happen whenever your primary or secondary isp fails
08-20-2010 05:26 PM
hmmm, thats wierd, try putting the same crypto map on both the interfaces. i mean do not use different crypto maps, use the same crypto map and give it a shot once
it has worked for me before, but i have seen few of my collegues complain about the same.
i will leave it open for someone who has seen this behaviour answer this question
08-04-2010 03:39 AM
does this happen whenever your primary or secondary isp fails
08-05-2010 06:58 AM
yes, the problem starts after the 1st_isp route on 5505 fails and asa tries to establish the tunnel using the 2nd_isp
according to logs this process repeats several times
08-05-2010 07:38 AM
what code are you running
08-05-2010 07:44 AM
so whats happening when your isp fails and the default route changes to secondary, the vpn session still has sa's between the ip of the other end and yuor primary ip which failed
so it waits till the tunnels renegotiate and i think thats when it starts flowing
am i right till this point???
08-06-2010 03:25 AM
here is more detailed information about the problem
at first the primary route goes down, but then comes back, after this we can see the following:
we have several sa's in our tunnel. Some of them work (let's name it sa+) and others don't (sa-)
from 'cry ip sa pe' we can see that (sa+) have primary Crypto map tag: *primary-ras*
and (sa-) have Crypto map tag: *secondary-ras*
it comes out that (sa's-) do not return from the backup tunnel
08-09-2010 04:13 AM
we are ising Cisco ASA Software Version 8.2(1)
speaking about the process of 1st isp failer - it happens very quickly, thats why, we can see the problem only after the 1st isp comes back
so, when asa returns to primary ip, the vpn session from 5520 already has the correct 1st isp ip
but on asa 5505 some of the 'cry ip sa pe' still has 2nd isp's Crypto map tag
for unknown reasons they are not able to return back to 1st isp
08-20-2010 10:26 AM
Yes, basically you are right.
My situation is a bit more complex.
I have two crypto maps, one for primary provider (and interface), and second for the backup provider (and interface).
At some time, default route jumps from primary provider to backup provider, and then jumps back.
And the problem can be seen with 'sh cry ip sa | i map tag'
Some sa's turns to primary crypto map, and some still use backup crypto map.
That's the point.
The command 'clear cry sa' solves the problem. If I could run it automatically when route changes..
08-20-2010 05:26 PM
hmmm, thats wierd, try putting the same crypto map on both the interfaces. i mean do not use different crypto maps, use the same crypto map and give it a shot once
it has worked for me before, but i have seen few of my collegues complain about the same.
i will leave it open for someone who has seen this behaviour answer this question
08-25-2010 12:45 AM
Dear jathaval , thank you very match for your help!
your suggestions were really very useful. We've moved away the secondary crypto map and added the 'answer-only/orginate only' sheme.
Now it works correctly!
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: