cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9339
Views
16
Helpful
16
Replies

ASA SiteToSite Tunnel Issue

nshinde01
Level 1
Level 1

Hello Experts, 

When I am trying to establish a tunnel between 2 ASAs, its not building up. I ran some crypto debugs and came across following error message. 

Jan 07 2016 05:18:20: %ASA-5-713050: Group = X.X.X.X, IP = X.X.X.X
Connection terminated for peer
X.X.X.X. Reason: Peer Terminate Remote Proxy 0.0.0.0, Local Proxy 0.0.0.0

Assuming an issue with crypto ACL, am I correct? (I do not have access to ASA at remote site to verify)

P.S. I am using object-groups in crypto ACL on my side of the ASA. Is it not recommended? 
ASA in running code 9.2

16 Replies 16

Diego Lopez
Level 1
Level 1

Hello,

You can't really tell with this messages that there is an acl mismatch with the remote side but is a possibility, seems to be a problem in phase 2 and this is one of the things that you need to check with the remote ASA when you get access.

I don't see a problem using objects, objects will actually simplify the job just be careful and make sure you don't add more networks than the ones you need for the VPN.

I have done quite a few site to site VPN between ASAs which use object-groups and they work well. I wonder about the line that indicates that both local proxy and remote proxy are 0.0.0.0. Does this suggest that perhaps the crypto ACL has a line with permit ip any any? Using permit ip any any can cause unexpected behaviors when used in the crypto ACL.

We might be able to provide better advice if the original poster would post the config of his ASA.

HTH

Rick

HTH

Rick

You can have a look at the config on my side, I am doing policy PAT on my side. I do not have access to remote end config.
!

crypto ikev1 policy 13

authentication pre-share

encryption aes-256

hash sha     

group 2

lifetime 86400

exit

!
object-group network Inside

netowrk 192.168.1.0 255.255.255.0

network 192.168.20.0 255.255.255.0
network 192.168.5.0 255.255.255.0
network 192.168.6.0 255.255.255.0
network 192.168.15.0 255.255.255.0

network 192.168.17.0 255.255.255.0
network 10.2.10.0 255.255.255.0
network 10.3.10.0 255.255.255.0
network 10.4.10.0 255.255.255.0
network 10.8.10.0 255.255.255.0

network 10.11.10.0 255.255.255.0

network 10.14.10.0 255.255.255.0

network 10.18.10.0 255.255.255.0

network 10.20.10.0 255.255.255.0
!
object network PAT
host 7.128.240.83

exit
!
Object-group network RemoteReal
network-object host 10.130.152.173
network-object host 172.24.10.4

network-object host 10.130.146.161

exit

!
nat (inside,outside) source dynamic Inside PAT destination static RemoteReal RemoteReal
!
access-list CryptoACLMap60 permit ip object PAT object-group RemoteReal

!

!

crypto map pjb-vpn 60 match address CryptoACLMap60

crypto map pjb-vpn 60 set peer X.X.X.X

crypto map pjb-vpn 60 set ikev1 transform-set ESP-AES-256-SHA

crypto map pjb-vpn 60 set security-association lifetime seconds 28800

!

tunnel-group X.X.X.X type ipsec-l2l

tunnel-group X.X.X.X ipsec-attributes

ikev1 pre-shared-key ******

!

 

P.S. Remote end is running on code 8.2(I do not think it would cause any issue though) 

The way that the interesting traffic is configured is fine because you are translating your real traffic to a single IP with the dynamic nat that you configured, the ASA does Nat before checking the VPN acl.

The rest of the configuration looks fine too.

What I will suggest is that you can run a packet tracer to make sure you are hitting the nat that you configured 

packet-tracer input inside icmp 192.168.1.5 8 0 10.130.152.173 de 

look for the first Nat phase that you get an make sure is this statement.

If is hitting the correct nat I will say the next step will be checking with the remote side and make sure they configure the interesting traffic with the translated ip instead of the real networks and check all the phase 2 parameters, a VPN is built between 2 devices you cannot pretend have a site to site tunnel working with access to a single device. 

Yes, packet-tracer shows that it hits the NAT statement that I configured. 

Remote side is ASA running on 8.2 and I guess order of operation is different on it. So could you please suggest how should crypto ACL be on remote end? 

If you do a "show access-list CryptoACLMap60" your ACL should look like this:

access-list CryptoACLMap60 permit ip host 7.128.240.83 host 10.130.152.173 

access-list CryptoACLMap60 permit ip host 7.128.240.83 host 172.24.10.4

access-list CryptoACLMap60 permit ip host 7.128.240.83 host 10.130.146.161

The remote side should look like this:

access-list CryptoACLMap permit ip host 10.130.152.173 host 7.128.240.83

access-list CryptoACLMap permit ip host 172.24.10.4 host 7.128.240.83

access-list CryptoACLMap permit ip host 10.130.146.161 host 7.128.240.83

you can also use objects if you prefer but when you run the command "show access-list CryptoACLMap" should look like that.

Thanks for your time and reply, 

I guess below message is enough to say that phase 1 is complete. I do not see that in 'sh crypto ikev1 sa' output though. 
Jan 07 2016 05:18:20: %ASA-5-713119: Group = X.X.X.X, IP = X.X.X.X, PHASE 1 COMPLETED

I have seen some bugs caused by using object-groups in crypto ACL. So thought better to confirm if its okay to use them in crypto-acl. 

Also can you please take a look at following document,
http://www.cisco.com/c/en/us/td/docs/ios/sec_data_plane/configuration/guide/15_1/sec_data_plane_15_1_book/sec_object_group_acl.html#wp1132617
Which mentions a restriction on using object-group in crypto ACL. 


That link is for a document about IOS Routers. If you are configuring your VPN on ASA then the document for IOS Routers does not apply to you.

When I have done site to site VPN with addresses that are dynamically translated I have used the inside/real address in the crypto ACL rather than the translated address. I suggest that you change your crypto ACL from this

access-list CryptoACLMap60 permit ip object PAT object-group RemoteReal

to this

access-list CryptoACLMap60 permit ip object Inside object-group RemoteReal

HTH

Rick

HTH

Rick

Thanks for clearing that doubt about object-groups. 

Isn't crypto ACL is processed after the NAT statements? 

I would suggest that you try the crypto ACL with my suggestion and tell us if the behavior changes.

HTH

Rick

HTH

Rick

As my tunnel is UP. I can confirm, we do need to call translated subnets in crypto ACL even if its policy PAT. 

Thank you very much for your assistance

Thank you for posting back to the forum to let us know that you solved the issue and that the VPN is now up and working.

HTH

Rick

HTH

Rick

I will agree that this information my apply to routers because acls with objects on a crypto maps don't work well and affect the traffic of the router because it creates an SA with an any any statement when the site to site tunnel is up sending all the traffic over the VPN, I've seem it before on routers but ASA have no problems at all, I can't remember how many site to site tunnel I have built between ASAs using objects and they work great and using objects make you life easier, you can even reuse the object to create the required nat exemption.

Could not agree with you more. Object-groups make life easier. 

Getting Started

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: