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 126.96.36.199:
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 “188.8.131.52”
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 184.108.40.206.
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 220.127.116.11
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 18.104.22.168
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 22.214.171.124
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 126.96.36.199
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 “188.8.131.52” 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.