DEL_REASON_PEER_NOT_RESPONDING with Cisco VPN client and ASA

I recently came across an issue while converting a Cisco PIX 6.3.3 firewall to a Cisco ASA firewall running 7.2(5).

It was a simple problem, caused by a simple oversight, but it took quite a while for the cause to become apparent.

If a VPN client attempted to connect (using IPSEC/UDP), it would fail and a log of the session would show DEL_REASON_PEER_NOT_RESPONDING as the cause. The ASA never seemed to show any relevant debug information, in fact it seemed to be oblivious to the fact that a client was trying to connect.

Here is the full client log (in this case from an OSX machine), with the peer address changed to 1.1.1.1:

Cisco Systems VPN Client Version 4.9.01.0230

Copyright (C) 1998-2009 Cisco Systems, Inc. All Rights Reserved.

Client Type(s): Mac OS X

Running on: Darwin 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4-1/RELEASE 1386 i386 Config file directory: /etc/opt/cisco-vpnclient

1              17:40:35.421 08/11/2010 Sev=Info/4     CM/Ox43100002 Begin connection process

2              17:40:35.422 08/11/2010 Sev=Info/4     CM/Ox43100004 Establish secure connection using Ethernet

3              17:40:35.422 08/11/2010 Sev=Info/4     CM/Ox43100024 Attempt connection with server “1.1.1.1”

4              17:40:35.422 08/11/2010 Sev=Info/4     CVPND/Ox43400019 Privilege Separation: binding to port: (500).

5              17:40:35.422 08/11/2010 Sev=Info/4     CVPND/Ox43400019 Privilege Separation: binding to port: (4500).

6              17:40:35.422 08/11/2010 Sev=Info/6     IKE/Ox4300003B Attempting to establish a connection with 1.1.1.1.

7              17:40:35.510 08/11/2010 Sev=Info/4     IKE/Ox43000013 SENDING >>> ISAKMP OAK AG (SA, KE, NON, ID, VID(Xauth), VID(dpd), VID(Frag), VID(Nat-T), VID(Unity)) to 1.1.1.1

8              17:40:35.552 08/11/2010 Sev=Info/4     IPSEC/Ox43700008 IPSec driver successfully started

9              17:40:35.552 08/11/2010 Sev=Info/4     IPSEC/Ox43700014 Deleted all keys

10             17:40:40.552 08/11/2010 Sev=Info/4     IKE/0x43000021 Retransmitting last packet!

11             17:40:40.552 08/11/2010 Sev=Info/4     IKE/0x43000021 SENDING >>> ISAKMP OAK AG (Retransmission) to 1.1.1.1

12             17:40:45.552 08/11/2010 Sev=Info/4     IKE/0x43000021 Retransmitting last packet!

13             17:40:45.552 08/11/2010 Sev=Info/4     IKE/0x43000021 SENDING >>> ISAKMP OAK AG (Retransmission) to 83.244.132.215

14             17:40:50.552 08/11/2010 Sev=Info/4     IKE/0x43000021 Retransmitting last packet!

15             17:40:50.552 08/11/2010 Sev=Info/4     IKE/0x43000013 SENDING >>> ISAKMP OAK AG (Retransmission) to 1.1.1.1

16             17:40:55.552 08/11/2010 Sev=Info/4     IKE/Ox43000017 Marking IKE SA for deletion (I_Cookie=15E3249D9DD68494 R_Cookie=0000000000000000) reason = DEL_REASON_PEER_NOT_RESPONDING

17             17:40:56.052 08/11/2010 Sev=Info/4     IKE/Ox4300004B Discarding IKE SA negotiation (I_Cookie=15E3249D9DD68494 R_Cookie=0000000000000000) reason = DEL_REASON_PEER_NOT_RESPONDING

18             17:40:56.052 08/11/2010 Sev=Info/4      CM/Ox43100014 Unable to establish Phase 1 SA with server “1.1.1.1” because of “DEL—REASON—PEER—NOT—RESPONDING”

19             17:40:56.052 08/11/2010 Sev=Info/5      CM/Ox43100025 Initializing CVPNDry

20             17:40:56.053 08/11/2010 Sev=Info/4      CVPND/Ox4340001F Privilege Separation: restoring MTU on primary interface.

21             17:40:56.053 08/11/2010 Sev=Info/4     IKE/Ox43000001 IKE received signal to terminate VPN connection

22             17:40:56.552 08/11/2010 Sev=Info/4      IPSEC/Ox43700014 Deleted all keys

23             17:40:56.552 08/11/2010 Sev=Info/4     IPSEC/Ox43700014 Deleted all keys

24             17:40:56.552 08/11/2010 Sev=Info/4      IPSEC/Ox43700014 Deleted all keys

25             17:40:56.552 08/11/2010 Sev=Info/4      IPSEC/Ox4370000A IPSec driver successfully stopped

There are lots of other articles explaining what DEL_REASON_PEER_NOT_RESPONDING might mean, but none say what turned out to be the (in hindsight) obvious answer… no crypto map had been applied to the outside interface.

The PIX had the single line:

crypto map remote interface outside

(where remote was the name of the list of commands that matched the incoming LAN to LAN and dynamic VPN clients)

This had been missed from the ASA configuration.

Once entered, everything sprang into life. I don’t know whether the error was made by me tweaking parts of the configuration or ignored by the Cisco PIX to ASA Migration tool (seems unlikely) but as usual, it is obvious when know what is missing.

Advertisements

2 thoughts on “DEL_REASON_PEER_NOT_RESPONDING with Cisco VPN client and ASA

  1. Sherry Zameer May 18, 2011 at 6:58 am Reply

    Dear Raza,

    That does not make sense since we have the issue isolated on one site only. And the same configuration from other sites do not have the not responding error returned.

    • Raza Rizvi May 18, 2011 at 8:22 am Reply

      There are lots of other suggestions around and maybe one of those will solve the issue for you. I documented this one as no one else seemed to have listed it, and it is the most glaringly obvious omission – not having a crypto map in place.

      If it is just one site might the intervening ISP be blocking packets?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: