Static Crypto Map Entry (Priority)
RS_MCP
Member Posts: 352
Hi All,
I have dual IPSec Site-to-Site VPN tunnels running on my main Cisco ASA 5520, The tunnels have been up and traversing traffic in both directions for quite some time and all of a sudden on one day, one of my sites could send traffic but not recieve any.
I troubleshooted very hard in terms of bouncing the tunnels, checking the configuration etc, but it just so happened that changing the static crypto map entry 'priority' to a lower number resolved the issue.
Why is this and why did this cause traffic to stop all of a sudden?
All is working now and it has remained stable for a few weeks.
Thank you for your help in advance.
I have dual IPSec Site-to-Site VPN tunnels running on my main Cisco ASA 5520, The tunnels have been up and traversing traffic in both directions for quite some time and all of a sudden on one day, one of my sites could send traffic but not recieve any.
I troubleshooted very hard in terms of bouncing the tunnels, checking the configuration etc, but it just so happened that changing the static crypto map entry 'priority' to a lower number resolved the issue.
Why is this and why did this cause traffic to stop all of a sudden?
All is working now and it has remained stable for a few weeks.
Thank you for your help in advance.
Comments
-
millworx Member Posts: 290I don't know if this is exactly related, and I don't know where I read it, but as a general rule, you want to make your crypto map priority lower that your isakmp policy number. Most of the time it works just fine and really doesn't matter, but I did read that somewhere.
Is this the only crypto map on your box?Currently Reading:
CCIE: Network Security Principals and Practices
CCIE: Routing and Switching Exam Certification Guide -
shednik Member Posts: 2,005Definitely need some more information to give you a specific reason, but as it has already been asked were there multiple entries in your crypto map? If changing the priority fixed the issue it was more then likely hitting a different priority on the map for the interface.
-
RS_MCP Member Posts: 352I don't know if this is exactly related, and I don't know where I read it, but as a general rule, you want to make your crypto map priority lower that your isakmp policy number. Most of the time it works just fine and really doesn't matter, but I did read that somewhere.
Is this the only crypto map on your box?
Crypto map entry lower than the ISAKMP policy...? You would to show me the read for that. No, I have multiple static crypto maps on my ASA for multiple sites. -
RS_MCP Member Posts: 352Definitely need some more information to give you a specific reason, but as it has already been asked were there multiple entries in your crypto map? If changing the priority fixed the issue it was more then likely hitting a different priority on the map for the interface.
"it was more then likely hitting a different priority on the map for the interface"
Would you mind explaining in more detail, I am not understanding. -
shednik Member Posts: 2,005"it was more then likely hitting a different priority on the map for the interface"
Would you mind explaining in more detail, I am not understanding.
Do you have multiple entries in the crypto map?
I don't have a lot of time now to dig into it too much, working on an issue with one of my ASA clusters but take a look here.
IPSec Example
If you have entry 5 and entry 10 and entry 10 was the one you wanted it to use and moving it to entry 3 or 4 made it work means it was matching on number 5 for some reason. Crypto maps are sequential like an ACL, Didn't the CCSP exams cover this fairly in depth? I would expect it would but I haven't studied for the exams yet.
Hope this help. -
RS_MCP Member Posts: 352"Do you have multiple entries in the crypto map?"
I have a number of "Source" networks but "Destination" is a single network on each individual static crypto map entry. -
shednik Member Posts: 2,005"Do you have multiple entries in the crypto map?"
I have a number of "Source" networks but "Destination" is a single network on each individual static crypto map entry.
I meant multiple sequence numbers not networks. -
viper75 Member Posts: 726 ■■■■□□□□□□Do you have any Dynamic crypto maps? If you do, change their priority number to a higher number.CCNP Security - DONE!
CCNP R&S - In Progress...
CCIE Security - Future... -
RS_MCP Member Posts: 352I meant multiple sequence numbers not networks.
I have a number of static crypto maps with each assigned a priority, not sure what you mean by sequence numbers? -
RS_MCP Member Posts: 352Do you have any Dynamic crypto maps? If you do, change their priority number to a higher number.
No, they are all static crypto maps and I have no dynamic. The default dynamic crypto map is assigned the highest (65335). -
RS_MCP Member Posts: 352Hi All,
I raised a TAC request with Cisco today and their VPN specialist engineer was also unable to understand the problem I had, he does not know why either, I'm sure we can find out??? -
burbankmarc Member Posts: 460If it's not matching traffic to a different crypto map entry then it's probably a bug. What version of the ASA software are you running?
-
RS_MCP Member Posts: 352burbankmarc wrote: »If it's not matching traffic to a different crypto map entry then it's probably a bug. What version of the ASA software are you running?
ASA Version: 8.2(1) -
RS_MCP Member Posts: 352Hi All,
A response from the Cisco TAC Engineer:
CSCtb53186 Bug Details
Duplicate ASP crypto table entry causes firewall to not encrypt traffic
Symptom:
When testing 100 site to site vpn connections on an ASA running 8.2.1 one or two tunnels would not encrypt traffic.
The connections were established and dropped multiple times before seeing this issue.
Conditions:
"sho asp table vpn-context detail " shows duplicate crypto table entries.
Two current and one left over from previous connection.
This creates the problem of the traffic not being encrypted.
Workaround:
1. Reload ASA.or
2. Upgrade to get the fix for both CSCtb53186 and CSCtd36473. CSCtd36473 is a defect with a very similar symptom but different root cause.
This bug is resolved on version 8.2(4)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please let me know your thoughts? -
burbankmarc Member Posts: 460Well reloading your ASA all the time isn't very effective. I would upgrade the software for sure.
I like to patch and upgrade though, it's just the way I am. I know some sysadmins/network engineers can go years without updates. If that works for you, cool, but I always seem to run into bugs like the OP. -
aaku_us Registered Users Posts: 1 ■□□□□□□□□□Guys i had a similar problem with phase 2 not completing. What i did is moved the crypto map higher up on the list and it started working. Also my cry was static not dynamic. I have had this issue with two clients alrfeady. My question is after upgrading the software...did the problem ever returned? did the upgrade resolve the issue? Initial thoughts from the tac engineer were similar...he informed me that the IOS may need to be upgraded.
-
xXErebuS Member Posts: 230Have fun upgrading from 8.2 to 8.3+.
For record what shednik was trying to get at is did you have:
access-list first extended permit ip host X.X.X.X host X.X.X.X
access-list second extended permit ip any any
access-list third extended permit ip host X.X.X.X host X.X.X.X
crypto map crymap1 10 match address first
crypto map crymap1 20 match address second
crypto map crymap1 30 match address third
Obviously the third crypto statment will not work correctly.... I think you already know this and it sounds like a bug but I thought I would explain for anyone reading the thread who may have the issue shednik was explaining.