Site-to-site VPN between two ASA5505

firestormnet · ‎10-03-2013

Hi All.

Really need your help guys. I'm stuck in configuring a site-to-site VPN between two ASA5505. It doesn't even establish Phase1. I was using ASDM then checking over CLI, but can't find a problem.

1) Main_office,

Cisco Adaptive Security Appliance Software Version 8.4(3)

Device Manager Version 7.1(3)

2) Remote_office,

Cisco Adaptive Security Appliance Software Version 7.2(4)

Device Manager Version 5.2(4)

As you can see they've got 2 different IOS, so one is using ikev1 amd ikev2, another one is isakmp. I'm not sure if it's a problem or they should establish VPN anyway.

The diagram looks like that:

LAN ------------ ASA5505 ----------------------internet -------------------------- 1941 router --------------------------------- ASA5505 ------------------LAN

10.1.11.0 Remote WAN 88.8.8.8 WAN 99.9.9.9 Doing NATing, 192.168.115.1 .2 Main_office 192.168.110.0

Debug from Main_office ASA:

Oct 03 14:21:56 [IKEv1]Group = 88.8.8.8, IP = 88.8.8.8, Can't find a valid tunnel group, aborting...!

Oct 03 14:22:04 [IKEv1]IP = 88.8.8.8, Header invalid, missing SA payload! (next payload = 4)

Oct 03 14:22:12 [IKEv1]IP = 88.8.8.8, Header invalid, missing SA payload! (next payload = 4)

Oct 03 14:22:20 [IKEv1]IP = 88.8.8.8, Header invalid, missing SA payload! (next payload = 4)

Debug from Remote ASA:

Oct 03 12:44:31 [IKEv1]: IP = 99.9.9.9, Removing peer from peer table failed, no match!

Oct 03 12:44:31 [IKEv1]: IP = 99.9.9.9, Error: Unable to remove PeerTblEntry

Oct 03 12:44:48 [IKEv1]: IP = 99.9.9.9, Information Exchange processing failed

Oct 03 12:44:56 [IKEv1]: IP = 99.9.9.9, Information Exchange processing failed

Oct 03 12:45:03 [IKEv1]: IP = 99.9.9.9, Information Exchange processing failed

Also I attached a file with both configs and some debug.

Please note that

tunnel-group 99.9.9.9 has PSK $$$$$$$ on both sides.

And tunnel-group 88.8.8.8 with PSK xxxxxx works for other two remote user VPNs.

Any help will be highly appretiated.

Thanks.

Jouni Forss · ‎10-03-2013

Hi,

Main Office ASAs "tunnel-group" IP address is different than that in the "crypto map" section of the configuration on the same device. Unless ofcourse this is a typo when masking the public IP addresses.

You should remove all the configurations from the "tunnel-group" and "group-policy" related to "ikev2" because the other device running 7.2 software doesnt support it so its pointless.

Also the Crypto ACLs are different on the devices (check the Main Office ACLs destination IP compared to the source IP on the Remote office)

Main Office

object network INSIDE_NET

subnet 192.168.110.0 255.255.255.0

object network Remote_Network

host 192.168.55.1

access-list outside_cryptomap_1 extended permit ip object INSIDE_NET object-group Remote

Remote Office

access-list outside_2_cryptomap extended permit ip 10.1.11.0 255.255.255.0 192.168.110.0 255.255.255.0

The Remote Office also seems to have 2 "tunnel-group" configurations? Other for its own IP address and another for the other sites IP address?

- Jouni

firestormnet · ‎10-03-2013

Hi Jouni.

Thanks for your quick reply.

1) In tunnel-group there is no typo. Let me explain, on Main ASA:

crypto map outside_map0 2 set peer 88.8.8.8 - WAN ip of Remote ASA (it should be right).

tunnel-group 99.9.9.9 type ipsec-l2l - 99.9.9.9 - is just a name of tunnel-group, and it should be the same on both side if I understand right. I can't use tunnel-group 88.8.8.8 on Main ASA as it's already used in Remote ASA with different PSK for other 2 remote vpns.

2) I'll remove ikev2, but at the moment it doesn't make any harm, so it shouldn't be a problem in that.

3)object network Remote_Network

host 192.168.55.1

description Remote NMC

object network Remote_Network2

subnet 10.1.11.0 255.255.255.0

description Remote Network 2

object network NETWORK_OBJ_192.168.110.0_24

subnet 192.168.110.0 255.255.255.0

object-group network Remote

description Remote network ranges

network-object object Remote_Network

network-object object Remote_Network2

This is a full config. So Remote_Network is a DMZ part of Remote network. I'm not worried about DMZ part now, as long as site-to-site would start working.

4) There are more tunnel-groups on both ASAs and they're all operational and active.

As I mentioned, on Remote ASA tunnel-group 88.8.8.8 is already in use, so I've created a

tunnel-group 99.9.9.9 type ipsec-l2l for a new VPN.

Hope, you're understanding better now. It may look complicated and I did some silly mistake, and somebody can correct me.

Thanks.

Jouni Forss · ‎10-04-2013

Hi,

Seems I looked at the remote network part wrong though even so there is still difference in the Crypto ACL with regards to the host IP address 192.168.55.1 (The other sites crypto acl makes no mention of it and it would be ideal that the crypto ACL are mirror images of each others on the VPN gateways)

I am not sure what the idea with the "tunnel-group" configurations are. I have never before seen anyone specify any IP address in a "tunnel-group" for VPN client use.

What I do know is that the L2L VPN with addition to the "crypto map" configurations needs a "tunnel-group" configuration thats name is the peer IP address of the other VPN gateway. To my understanding this is a must if you are using PSK authentication. If you are using the L2L VPN peer IP address as the "tunnel-group" name for VPN Client use for some reason then I am not sure will the ASA accept a same named "tunnel-group" for the L2L VPN. I still dont see the idea of naming the VPN Client "tunnel-group" with other devices public IP address.

- Jouni

firestormnet · ‎10-07-2013

Hi.

1) Checking the crypto ACL on both sides:

Main office:

object network INSIDE_NET

subnet 192.168.110.0 255.255.255.0

object network Remote_Network

host 192.168.55.1

object network Remote_Network2

subnet 10.1.11.0 255.255.255.0

object-group network Remote

network-object object Remote_Network

network-object object Remote_Network2

crypto map outside_map0 2 match address outside_cryptomap_1

access-list outside_cryptomap_1 extended permit ip object INSIDE_NET object-group Remote

Remote Office:

name 192.168.110.0 Main_Office description Main office LAN

access-list outside_2_cryptomap extended permit ip 10.1.11.0 255.255.255.0 Main_Office 255.255.255.0

crypto map mymap 2 match address outside_2_cryptomap

Yes, there is missing "object network Remote_Network host 192.168.55.1" in Remote office ACL. I can add that but I don't think it can prevent to establish a Phase 1, maybe I'm wrong.

2) Actually if you use ASDM to setup IPsec it will automatically by default create a Tunnel-group with IP address of remote site. I did that and it didn't work. Then I tried manually to put Word Name of Tunnel-group, and it didn't work as well, and it was setup in Aggressive mode only. The problem is that I can manually create tunnel -group in Remote office ASA wizard, but in Main office it doesn't give that option, so it creates a tunnel-group with IP address.

As you mention VPN client, I'm not setting up VPN client, I'm doing site-to-site vpn.

3) I will change the tunnel-group IP address. It didn't work before but after some changes and understanding will give a try.

Thanks.

firestormnet · ‎10-07-2013

I've changed an ACL on Main office, removed extra networks then created a new Tunnel-group with the same IP address as Remote site. I can't see anything now. When I do debug on both sides, it shows no entries. Any clues?

Jouni Forss · ‎10-07-2013

Hi,

I would start by using "packet-tracer" command that matches to the traffic that should hit the L2L VPN configurations

packet-tracer input inside tcp 12345

Issue this command atleast 2 times before taking any of the following output or checking any of the below mentioned things.

In the output we would be looking for a Phase for VPN.

If we see a Phase for VPN resulting in a DROP them the traffic matches VPN configurations but the negotiation doesnt go through (remember to issue the "packet-tracer" command twice before checking this information)
If we DONT see any Phase for VPN then there is some problems with configurations on that local device. These can be related to VPN or NAT for example.

If your "packet-tracer" commands keep dropping in the VPN Phase then I would suggest first taking the output of

show crypto isakmp sa

After you have issued the "packet-tracer" a couple of times. Check what the above output is to know if the Phase 1 goes through.

If Phase 1 is fine (negotiation gone through) then it would be time to check the Phase2 configurations or NAT for errors.

- Jouni

firestormnet · ‎10-22-2013

Hi.

Finally, everything works as planned.

Thanks for reminding me a packet-tracer completely forgot about it. Still sometimes it doesn't show correctly for some reason, showing ACL deny even I applied Permit any any. But it doesn't matter as VPN is working now.

Thanks for your time and help.

Regards,