This is what I am getting - Page 2

ronald.lawrimore · ‎08-29-2014

I am trying to connect my onsite ASA to a remote ASA and without success. I have done the before to another 3rd Party and it works.

Does anybody see anything wrong with the configuration that was sent to me to input into my ASA other than what I XXX out.

crypto isakmp policy 132
   auth pre-share
   enc aes-256
   hash sha
   group 2
   lifetime 28800

access-list ACL-USIDBReplication permit ip 192.168.100.32 255.255.255.255 172.27.123.20 255.255.255.255

crypto ipsec transform-set USITransform esp-aes-256 esp-sha-hmac

crypto map Outside_map 10 match address ACL-USIDBReplication
crypto map Outside_map 10 set peer 54.XXX.XXX.XXX
crypto map Outside_map 10 set pfs
crypto map Outside_map 10 set transform-set USITransform
crypto map Outside_map 10 set security-association lifetime seconds 28800
crypto map Outside_map 10 set security-association lifetime kilobytes 4608000

tunnel-group 54.XXX.XXX.XXX type ipsec-l2l
tunnel-group 54.XXX.XXX.XXX ipsec-attrib
pre-shared-key XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

ronald.lawrimore · ‎09-02-2014

This is what I am getting over and over again. Unfortunately I cannot check the other end since it is a third party. What gets me is that I have another VPN that is setup almost exactly the same except for the key, peer IP and encryption level and it works just fine.

CiscoASA(config)# debug crypto isakmp 6
CiscoASA(config)# Sep 02 07:15:32 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
Sep 02 07:15:33 [IKEv1]: Group = 54.213.54.244, IP = 54.213.54.244, Duplicate Phase 1 packet detected. Retransmitting last packet.
Sep 02 07:15:33 [IKEv1]: Group = 54.213.54.244, IP = 54.213.54.244, P1 Retransmit msg dispatched to MM FSM
Sep 02 07:15:37 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
Sep 02 07:15:42 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
Sep 02 07:15:47 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
Sep 02 07:15:49 [IKEv1 DEBUG]: Group = 54.213.54.244, IP = 54.213.54.244, IKE MM Initiator FSM error history (struct &0xd63a6790) <state>, <event>: MM_DONET
Sep 02 07:15:49 [IKEv1]: Group = 54.213.54.244, IP = 54.213.54.244, Removing peer from peer table failed, no match!
Sep 02 07:15:49 [IKEv1]: Group = 54.213.54.244, IP = 54.213.54.244, Error: Unable to remove PeerTblEntry
Sep 02 07:15:52 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
Sep 02 07:15:52 [IKEv1]: IP = 54.213.54.244, IKE Initiator: New Phase 1, Intf inside, IKE Peer 54.213.54.244 local Proxy Address 192.168.100.32, remote Prox)
Sep 02 07:15:52 [IKEv1 DEBUG]: IP = 54.213.54.244, Oakley proposal is acceptable
Sep 02 07:15:52 [IKEv1]: IP = 54.213.54.244, Header invalid, missing SA payload! (next payload = 4)
Sep 02 07:15:52 [IKEv1]: IP = 54.213.54.244, Connection landed on tunnel_group 54.213.54.244
Sep 02 07:15:52 [IKEv1]: Group = 54.213.54.244, IP = 54.213.54.244, Automatic NAT Detection Status: Remote end IS behind a NAT device This end e
Sep 02 07:15:57 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
Sep 02 07:16:02 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
Sep 02 07:16:03 [IKEv1]: Group = 54.213.54.244, IP = 54.213.54.244, Duplicate Phase 1 packet detected. Retransmitting last packet.
Sep 02 07:16:03 [IKEv1]: Group = 54.213.54.244, IP = 54.213.54.244, P1 Retransmit msg dispatched to MM FSM

Richard Burts · ‎09-02-2014

In this debug output I see multiple instances of where the remote peer sends a key acquire message but no indication of any other traffic from them. Perhaps if the debug ran longer there might be other messages from them, or perhaps they are really not sending anything else. Perhaps you can check with the person at the remote peer and find what they are seeing on their end?

And on the positive side there are several messages look like there might be some negotiation going on that we have not yet seen in the debug output. In particular this message

Oakley proposal is acceptable

and this message

Connection landed on tunnel_group

are perhaps a bit encouraging.

HTH

Rick

HTH

Rick

ronald.lawrimore · ‎09-03-2014

The 3rd party is insistent it is an issue on our end. He has asked that I do a NAT for this. Not sure why since all of our NAT is done by our ISP on there firewall.

access-list USI extended permit ip host 192.168.100.32 host 172.27.123.20

I currently have a single NAT rule to exempt all inside network to Any outside.

I have attached a basic layout of what we have. Again, a VPN to another 3rd Party works.

ASA5505 VPN IPSEC Config Issue