ACL does not match proxy IDs in two tunnels

Answered Question
Feb 2nd, 2011

Hi all,

I'm getting an "ACL does not match proxy IDs" error that I'm not able to troubleshoot, googled this with a lot of results, tried some; but nothing applied.


I have setup 2 tunnels,
1/one from a pix 515e (office) to an ASA 5505 (hosted server) for my guys to access the hosted server
2/A second one from the ASA 5505 to my client's firewall so that its equipments can reach the hosted server and from the hosted server reach the equipments.

Both tunnels are working fine, my issue comes when I'm trying to join my clients equipments from my office, ie cascading the tunnels.
The setup has been done (part of it) with the help of external professional services and when we made a test it seems it was working...Seems because we've done only one test and as I'm not able anymore so I wonder if in fact it has ever worked!

This is the first time I'm trying to cascade some tunnels, no issues with other vpns I have been building.

I'm joining the configuration of the pix and the asa and an extract of the syslogs showing the error, hoping someone could point me to an obvious error I haven't seen!

Feel free to ask any information missing that could be useful, and many thanks in advance for your help!

Rgds

I have this problem too.
0 votes
Correct Answer by Marcin Latosiewicz about 3 years 2 months ago

JD,

NAT is done before crypto, for many reasons, flexibility most of all.

I checked the ACL and still see a mismatch, I mean number of ACLs and their contents MUST match the only difference being is that source and destination must be swapped between the two.

Until you correct this it will always be failing

Once you to this, you can maybe try checking where it's failing by refering to a reference I posted some time ago?

Can you maybe gather the debugs as described here:

https://supportforums.cisco.com/docs/DOC-14044#31_Debugs_used

Marcin

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (2 ratings)
hdashnau Wed, 02/02/2011 - 13:44

Lets say you have ASA/PIXs called A, B, and C. It sounds like you already have a tunnel  between A<=>B and a tunnel between A<=>C. You now want  traffic between B<=>C.

To do this, you have two ways of approaching the solution. You can either....

1.  Send the traffic between B and C through A, so that A is acting like a sort of hub to both B and C. This would mean adding  "same-security-traffic permit intra-interface" on A so that the traffic  that comes in the outside interface of A can also leave out the outside  interface of A since it will need to be redirected. To accomplish this you need to permit some additional traffic in the crypto acls on all 3 devices. The crypto ACL is the ACL you define in the crypto map with the "match address" command.  Specifically you would need to permit the following networks in each ACL:

-On A, permit B-->C and C-->B

-On B, permit B-->C

-On C, permit C-->B

or

2. Just define a new crypto map instance on B and C (and don't send it through A).

-On B, permit B-->C

-On C, permit C-->B

Remember for both scenarios above to also to make the necessary changes in your access-group acls (sh run access-group) to permit the traffic and in your nat exemption as well. In 8.2 and previous codes the nat exemption is handled with the nat (interface) 0 access-list (the 0 indicates nat exemption). For 8.3 and higher codes, you won't do nat exemption, instead youll do identity nat for the VPN networks. For more information about 8.3 nat, check these quick references:

https://supportforums.cisco.com/docs/DOC-11639

-heather

Please remember to rate all posts that help you and mark the question as resolved if you figure it out.

Telemack1 Wed, 02/02/2011 - 14:26

thanks for your  inputs hdashnau, but I forgot to mention that I don't have access to my clients fwl configuration and I was hoping to manage this without changing anyhting on its side...With some NAT?

Marcin Latosiewicz Wed, 02/02/2011 - 13:48

Jd,

Access-lists attached to crypto map on both ends of the tunnel must match

access-list outside_cryptomap_120 extended permit ip host 194.XX.XXX.45 object-group Group_client 
access-list outside_cryptomap_120 extended permit ip object-group ClientVPN_Group object-group Group_client

access-list acl_VPN_office extended permit ip object LAN_office object-group DM_INLINE_NETWORK_1 
access-list acl_VPN_office extended permit ip object-group DM_INLINE_NETWORK_2 object LAN_office

Can you make sure that those two access-lists match each other? (Of course source and destination SHOULD be swapping places)

This is what's causing the failure:

2011-02-02 18:52:26    Local4.Error    172.24.11.244    Feb 02 2011 17:31:09: %PIX-3-713061: Group = 188.XXX.XXX.167, IP = 188.XXX.XXX.167, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 194.XX.XXX.45/255.255.255.255/0/0 local proxy 159.XXX.XXX.85/255.255.255.255/0/0 on interface outside

Let's see "show access-list NAME_OF_ACCESS_LIST" output for both ACLs I mentioned above.

Marcin

Telemack1 Wed, 02/02/2011 - 14:32

Thanks Marcin,

You point me to a mistake, I think I was missing one entry on the crypto. I added it as you can see on the attached file with the details of the ACLs, but still same error.

I'm guessing there is some NAT issue?

PS: first time I'm using Cisco support community, I appreciate your help both and getting answers so quickly after my firt post!

Correct Answer
Marcin Latosiewicz Thu, 02/03/2011 - 07:04

JD,

NAT is done before crypto, for many reasons, flexibility most of all.

I checked the ACL and still see a mismatch, I mean number of ACLs and their contents MUST match the only difference being is that source and destination must be swapped between the two.

Until you correct this it will always be failing

Once you to this, you can maybe try checking where it's failing by refering to a reference I posted some time ago?

Can you maybe gather the debugs as described here:

https://supportforums.cisco.com/docs/DOC-14044#31_Debugs_used

Marcin

Telemack1 Fri, 02/04/2011 - 13:36

Traffic was not natted on the ASA correctly, had to NAT from the outside to the outside:

nat (outside,outside) source static LAN_office Network_NAT_Clientname destination static Group_VPN-Clientname_Remote Group_VPN-Clientname_Remote unidirectional

Plus change the ACLs related.

I want to thank you all for your help; Marcin I'm keeping your link as reference!

Rgds

Marcin Latosiewicz Sat, 02/05/2011 - 04:04

JD,

Awesome!

I guess one can look at config all the time one wants and not find the mistake if it's the most obvious.

I'll give your post full marks ;-)

Marcin

Actions

Login or Register to take actions

This Discussion

Posted February 2, 2011 at 12:39 PM
Stats:
Replies:7 Avg. Rating:5
Views:5731 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard