ASA 5505 IKEv1 Encryption Stuck on AES-256

[matthewyauch]

Hi folks,

I have a very strange issue in which an ASA 5505 was installed for a remote user behind an AT&T cable modem/router combo.  The consumer device was placed in a 'DMZPlus' mode that lets the ASA use the public IP address, like a quasi bridge mode.  Don't think this information is relevant, but I don't want to leave anything out.

The ASA should have tunnels to two locations, one for VOIP and one for access to the corporate network.  After reconfiguration I found only one of the two tunnels became active.  Further troubleshooting led us to find that the remote side is apparently attempting to use aes-256 even when set to aes.  Below is the config w/ IPs and other information scrubbed. 1.1.1.1 would be the remote site, 2.2.2.2 would be the VOIP site, and 3.3.3.3 would be corporate.

Router 1 (1.1.1.1)

crypto ipsec ikev1 transform-set ESP-AES-SHA esp-aes esp-sha-hmac
crypto map outside_map 2 match address 2222_cryptomap
crypto map outside_map 2 set pfs group5
crypto map outside_map 2 set peer 2.2.2.2
crypto map outside_map 2 set ikev1 transform-set ESP-AES-SHA
crypto map outside_map 1098 match address 3333_cryptomap
crypto map outside_map 1098 set pfs group5
crypto map outside_map 1098 set peer 3.3.3.3
crypto map outside_map 1098 set ikev1 transform-set ESP-AES-SHA
crypto map outside_map interface outside
crypto ikev1 policy 10
authentication pre-share
encryption aes
hash sha
group 2
lifetime 86400
tunnel-group 3.3.3.3 type ipsec-l2l
tunnel-group 3.3.3.3 ipsec-attributes
ikev1 pre-shared-key *****
tunnel-group 2.2.2.2 type ipsec-l2l
tunnel-group 2.2.2.2 ipsec-attributes
ikev1 pre-shared-key *****

router1# show crypto ikev1 sa detail

IKEv1 SAs:

Active SA: 2
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 2

1 IKE Peer: 3.3.3.3
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
Encrypt : aes Hash : SHA
Auth : preshared Lifetime: 86400
Lifetime Remaining: 85309
2 IKE Peer: 2.2.2.2
Type : user Role : initiator
Rekey : no State : MM_WAIT_MSG2
Encrypt : aes-256 Hash : SHA
Auth : preshared Lifetime: 0

Cisco Adaptive Security Appliance Software Version 9.1(7)
Device Manager Version 6.4(5)

Compiled on Thu 14-Jan-16 09:37 by builders
System image file is "disk0:/asa917-k8.bin"

Router 2 (2.2.2.2)

crypto ipsec ikev1 transform-set ESP-AES-SHA esp-aes esp-sha-hmac
crypto map outside_map 2 match address 1111_cryptomap
crypto map outside_map 2 set pfs group5
crypto map outside_map 2 set peer 1.1.1.1
crypto map outside_map 2 set ikev1 transform-set ESP-AES-SHA
crypto map outside_map 125 match address 3333_cryptomap
crypto map outside_map 125 set peer 3.3.3.3
crypto map outside_map 125 set ikev1 transform-set ESP-AES-SHA
crypto map outside_map 125 set security-association lifetime seconds 28800
crypto map outside_map 125 set security-association lifetime kilobytes 4608000
crypto map outside_map interface outside
crypto ikev1 policy 10
authentication pre-share
encryption aes
hash sha
group 2
lifetime 86400
tunnel-group 3.3.3.3 type ipsec-l2l
tunnel-group 3.3.3.3 ipsec-attributes
ikev1 pre-shared-key *****
tunnel-group 1.1.1.1 type ipsec-l2l
tunnel-group 1.1.1.1 ipsec-attributes
ikev1 pre-shared-key *****

router2# show crypto ikev1 sa detail

IKEv1 SAs:

Active SA: 2
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 2

1 IKE Peer: 3.3.3.3
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
Encrypt : aes Hash : SHA
Auth : preshared Lifetime: 86400
Lifetime Remaining: 57738
2 IKE Peer: 1.1.1.1
Type : user Role : responder
Rekey : no State : MM_WAIT_MSG3
Encrypt : aes Hash : SHA
Auth : preshared Lifetime: 86400
Lifetime Remaining: 2144123723

Cisco Adaptive Security Appliance Software Version 9.1(7)
Device Manager Version 7.1(3)

Compiled on Thu 14-Jan-16 10:08 PST by builders
System image file is "disk0:/asa917-smp-k8.bin"

Just for funsies I tried changing all of the configuration to something like aes-192, and it made no difference (except for the corporate tunnel going down).  Anyone ever seen anything like this?

Thanks.

[Dinesh Moudgil]

Hello Matthew,

These states are achieved when the phase 1 policies are not matching on both the ends.

Please confirm you have identical phase 1 parameters on both the sides with the following commands:

show run crypto isakmp

show run crypto ikev1

If the phase 1 parameters are matching on both the sides, then make sure that the UDP port 500 and 4500 are opened for communication between your device and remote peer.

Lastly, make sure you have a proper route pertaining to remote VPN termination device.

In essence, initiator showing MM_WAIT_MSG2 means the 1st UDP packet was sent to the remote side. Responder showing MM_WAIT_MSG3  means the 1st UDP from initiator was received and responder has replied with 2nd UDP packet as well.

If the ASAs are stuck at these stages, that means 2nd UDP packet from responder never makes it to initiator side or the phase 1 proposals are not matching. If they are indeed matching, then take packet captures on outside interface for UDP packets between the devices and this will prove if the ISP is dropping the 2nd UDP packet or not. 

To confirm if it is not the phase 1 proposals issue, run the debugs as following

debug crypto condition peer <remote peer>
debug crypto isakmp 200
debug crypto ipsec 200

This will show something like "proposals not matching" if it is proposals issue else "retransmission"

if it is an ISP issue.

Hope that helps.

Regards,

Dinesh Moudgil

[Karsten Iwen]

Cisco Adaptive Security Appliance Software Version 9.1(7)

This release has some severe problems with IPsec VPNs. You should upgrade to the newest 9.1(7) interims-relase.

[matthewyauch]

Thank you for the responses.  The problem ended up being that this shoddy AT&T U-verse DSL modem/router device acts as a NAT router even when in semi bridge mode.  By putting the ASA into the DMZPlus mode, any device connected to the U-verse router can have NAT performed against it, and any ports NOT used by those devices is forwarded to the ASA by default.

Before the DMZPlus was activated for the ASA, it was connected through and NAT'd behind the U-verse router.  Its outside interface had a DHCP address within the U-verse router's internal IP address pool.  Apparently the traffic flow for this tunnel started and had a NAT session opened up to that tunnel destination with a source of the original NAT'd IP address.  After the DMZPlus mode, the ASA now showed it had the public IP address for its DHCP address, but the NAT session remained in the U-verse router's NAT memory.  Any port 500 traffic from the tunnel destination ended up trying to get NAT'd to the old IP address and did not get properly routed to the ASA.  It was a fluke that one tunnel worked and one didn't.

Rebooting the U-verse router resolved the issue.  Yay consumer gear.