ASA-LAB1# show isakmp sa                                                 

IKEv1 SAs:

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

1   IKE Peer: 50.56.229.98
    Type    : L2L             Role    : initiator 
    Rekey   : no              State   : MM_ACTIVE

ASA-LAB1# show isakmp sa | begin 50.56.229.98
1   IKE Peer: 50.56.229.98
    Type    : L2L             Role    : initiator 
    Rekey   : no              State   : MM_ACTIVE

ASA-LAB1#   show isakmp sa

IKEv1 SAs:

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

1   IKE Peer: 50.56.229.98
    Type    : user            Role    : initiator 
    Rekey   : no              State   : MM_WAIT_MSG2

ASA-LAB2(config)# show isakmp sa

IKEv1 SAs:

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

1   IKE Peer: 50.57.228.150
    Type    : user            Role    : responder 
    Rekey   : no              State   : MM_WAIT_MSG3

ASA-LAB1# show isakmp sa

IKEv1 SAs:

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

1   IKE Peer: 50.56.229.98
    Type    : user            Role    : initiator 
    Rekey   : no              State   : MM_WAIT_MSG4

ASA-LAB2# show isakmp sa

IKEv1 SAs:

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

1   IKE Peer: 50.57.228.150
    Type    : L2L             Role    : responder 
    Rekey   : no              State   : MM_WAIT_MSG5

ASA-LAB1# show isakmp sa

IKEv1 SAs:

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

1   IKE Peer: 50.56.229.98
    Type    : user            Role    : initiator 
    Rekey   : no              State   : MM_WAIT_MSG6

The post ISAKMP (IKE Phase 1) Status Messages MM_WAIT_MSG appeared first on Think Netsec.

When troubleshooting VPNs, the easiest way to figure out what is wrong with the VPN is to have the other side send traffic. This will allow you to narrow down their settings, assuming that the remote side has their side configured correctly and has routing correct.

What I will cover here is building a VPN strictly from debug output alone. The only thing that is not able to be learned via debugs is the pre-shared key so make sure that this is accurate. Most of this article will be assuming that no other VPNs are configured on the ASA currently. If you wish to see more about Site to Site VPN Configuration, check out my Site to Site Article.

What is needed to begin

Check to see if your Firewall already has IKEv1 VPNs configured and, if not, enable IKEv1. The quickest way to verify is to run the following:

show run crypto | include enable

This will show you which interfaces are enabled for IKEv1 (or IKEv2).

If nothing is enabled, then you will need to enable IKEv1 on the appropriate interface. In this case, it is the OUTSIDE interface.

crypto isakmp enable OUTSIDE (Pre 8.3)
crypto ikev1 enable OUTSIDE (Post 8.3)

– Verify

ASA-LAB1(config)# show run crypto | include enable
crypto ikev1 enable OUTSIDE

After you have enabled IKEv1, make sure that you have the Pre-shared key noted somewhere as this will be needed to configure the VPN.

Using Debugs to determine the Peer IP

Sometimes the Remote location may provide the wrong Peer IP. In this case, we are assuming the Peer IP provided is incorrect but the Remote side states they are trying to build the VPN currently. By enabling debugs for crypto messages, you can determine the possible peer IP.

There are several different debug types and varying degrees on the verbosity of the debugs but for this portion, we only need debugs for ISAKMP messages.

To enable this, we need the following

debug crypto isakmp 2 (Pre 8.3)
debug crypto ikev1 2 (Post 8.3)

If the other side is trying to build the tunnel, you should see a message like the following. (Note: If you have other VPNs already configured, you will also see messages from these tunnels. Try to ignore any existing peers messages and find the IP the presents a similar message below. The one referenced is specifically showing that no map is applied to the interface at all to match against. This could state anything such as no proposal chosen or does not match an existing map)

ASA-LAB1# debug cry ikev1 2
ASA-LAB1# Aug 20 15:55:14 [IKEv1]IP = 50.56.229.98, No crypto map bound to interface... dropping pkt
Aug 20 15:55:22 [IKEv1]IP = 50.56.229.98, No crypto map bound to interface... dropping pkt

Assuming that this peer IP is the Clients Peer IP, we can now try to add some of the configuration for this peer. To turn off debugs, run the following command

undebug all

If you are not seeing any debugs then make sure there are no control plane ACLs applied to the interface. You can confirm this by performing the following. If you see something appear like there is below then you will need to make sure that UDP port 500 is permitted along with the ESP protocol in the applied ACL.

ASA-LAB1(config)# show run access-group | i control-plane
access-group 100 in interface OUTSIDE control-plane

Configure Tunnel Group and add a Crypto Map

By creating the Tunnel group, the ASA can try to build Phase 1 of the VPN tunnel. In this case, the Pre-shared key is Th1nkN3tSec.

tunnel-group 50.56.229.98 type ipsec-l2l
tunnel-group 50.56.229.98 ipsec-attributes
    ikev1 pre-shared-key Th1nkN3tSec

Verify there is not a map currently being used for the OUTSIDE interface.

show run crypto | include interface OUTSIDE

If nothing comes up, then create a new MAP. If one exists, then add to the existing MAP later.

In this case, no MAP has been created yet so we will use a new one called VPNMAP.

crypto map VPNMAP interface OUTSIDE

Debugging Phase 1

Assuming that 50.56.229.98 is our peer, the debugs now should be limited to just this peer so that all other existing VPNs do not appear in the output. The following debug command will limit all crypto debugs to just this peer.

debug crypto condition peer 50.56.229.98

To see the encryption, hash etc that the peer is requesting for Phase 1, the debugs will need to be set to max verbosity.

debug crypto isamkp 255 (Pre 8.3)
debug crypto ikev1 255 (Post 8.3)

A lot of text should be coming across the terminal so performing ‘undebug all’ may be necessary to stop to read it. There should be some output similar to the output below.

IKEv1 Recv RAW packet dump
2d 52 d8 dc 44 74 d9 e5 00 00 00 00 00 00 00 00 | -R..Dt..........
01 10 02 00 00 00 00 00 00 00 00 ac 0d 00 00 3c | ...............!
00 00 00 01 00 00 00 01 00 00 00 30 01 01 00 01 | ...........0....
00 00 00 28 01 01 00 00 80 04 00 05 80 01 00 07 | ...(............
80 0e 00 c0 80 02 00 02 80 03 00 01 80 0b 00 01 | ................
00 0c 00 04 00 01 51 80 0d 00 00 14 90 cb 80 91 | ......Q.........
3e bb 69 6e 08 63 81 b5 ec 42 7b 1f 0d 00 00 14 | !.in.c...B{.....
7d 94 19 a6 53 10 ca 6f 2c 17 9d 92 15 52 9d 56 | }...S..o,....R.V
0d 00 00 14 4a 13 1c 81 07 03 58 45 5c 57 28 f2 | ....J.....XE\W(.
0e 95 45 2f 00 00 00 18 40 48 b7 d5 6e bc e8 85 | ..E/....@H..n...
25 e7 de 7f 00 d6 c2 d3 c0 00 00 00 | %..........

RECV PACKET from 50.56.229.98
ISAKMP Header
Initiator COOKIE: 2d 52 d8 dc 44 74 d9 e5
Responder COOKIE: 00 00 00 00 00 00 00 00
Next Payload: Security Association
Version: 1.0
Exchange Type: Identity Protection (Main Mode)
Flags: (none)
MessageID: 00000000
Length: 2885681152
Payload Security Association
Next Payload: Vendor ID
Reserved: 00
Payload Length: 60
DOI: IPsec
Situation:(SIT_IDENTITY_ONLY)
Payload Proposal
Next Payload: None
Reserved: 00
Payload Length: 48
Proposal #: 1
Protocol-Id: PROTO_ISAKMP
SPI Size: 0
# of transforms: 1
Payload Transform
Next Payload: None
Reserved: 00
Payload Length: 40
Transform #: 1
Transform-Id: KEY_IKE
Reserved2: 0000
Group Description: Group 5
Encryption Algorithm: AES-CBC
Key Length: 192
Hash Algorithm: SHA1
Authentication Method: Preshared key
Life Type: seconds
Life Duration (Hex): 00 01 51 80
Payload Vendor ID
Next Payload: Vendor ID
Reserved: 00
Payload Length: 20
Data (In Hex):
90 cb 80 91 3e bb 69 6e 08 63 81 b5 ec 42 7b 1f
Payload Vendor ID
Next Payload: Vendor ID
Reserved: 00
Payload Length: 20
Data (In Hex):
7d 94 19 a6 53 10 ca 6f 2c 17 9d 92 15 52 9d 56
Payload Vendor ID
Next Payload: Vendor ID
Reserved: 00
Payload Length: 20
Data (In Hex):
4a 13 1c 81 07 03 58 45 5c 57 28 f2 0e 95 45 2f
Payload Vendor ID
Next Payload: None
Reserved: 00
Payload Length: 24
Data (In Hex):
40 48 b7 d5 6e bc e8 85 25 e7 de 7f 00 d6 c2 d3
c0 00 00 00
Aug 20 16:27:45 [IKEv1]IP = 50.56.229.98, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 172

With this message, we can see what the Remote side is proposing. In this case, the following is what is being sent for Phase 1.

Encryption: AES-192
Hash: SHA1
DH Group: 5
Lifetime: 86400

Debug Output explained

To elaborate, this is how to read the debug output to determine these settings.

Encryption is found by looking at Encryption Algorithm and Key Length. In this case, Encryption Algorithm is AES-CBC with a Key Length of 192. This means that peer has chosen AES-192. If Key length was 128, for example, then this would have been AES-128 or just AES on the ASA as the default AES is 128 bits.

Hash is found by what is in the Hash Algorithm data. In this case was SHA1.

Diffie-Hellman (DH) group is found in the Group Description data. In this request it showed Group 5.

Lifetime for Phase 1 is always seconds but this is stated in the Life Type portion for verification. The Lifetime is found in the Life Duration data which is presented in HEX. This will need to be converted into DEC (decimal) which can be done via a Programming calculator or on the web. In this case, the conversion of 00 01 51 80 to DEC is 86400

Configuring Phase 1

With this information from the Payload, we can configure Phase 1 of the VPN.

If IKEv1 (ISAMKP) Policies already exist then be sure to not overwrite an existing one. In this case, one does not exist so this will be configured as policy 100.

crypto isakmp policy 100 (Pre 8.3)
authentication pre-share
encryption aes-192
hash sha
group 5
lifetime 86400

crypto ikev1 policy 100 (Post 8.3)
authentication pre-share
encryption aes-192
hash sha
group 5
lifetime 86400

Once this is configured, Phase 1 should be able to complete. If debugs are currently disabled (undebug all was ran), then re-enable the debugs with the following to verify Phase 1 is completing

debug crypto condition peer 50.56.229.98

debug crypto isamkp 2 (Pre 8.3)
debug crypto ikev1 2 (Post 8.3)

A message like the following should appear:

Aug 20 17:07:30 [IKEv1]Group = 50.56.229.98, IP = 50.56.229.98, PHASE 1 COMPLETED

If you are not seeing this message then you may be seeing one of th MM_WAIT messages. If you see MSG6, the the Pre Shared key is incorrect so be sure to validate this again. If you are seeing any other MSG number then be sure to look at the debug messages prior and confirm you have configured them the same. Each of the Messages (1-6) correspond to a portion of Phase 1 but I go over this in more detail in my MM_WAIT_MSG article if you are having issues.

Debugging Phase 2

If debugs are currently disabled (undebug all was ran), then re-enable the debugs with the following commands:

debug crypto condition peer 50.56.229.98

debug crypto isamkp 255 (Pre 8.3)
debug crypto ikev1 255 (Post 8.3)

Note that this will most likely cause a lot of text to scroll by so run ‘undebug all’ if you need to stop it and read. If you already have Phase 2 configured, and are the initiator, then you may see some No Proposal Messages. I have these explained in another article here for clarification.

If the Client is initiating, then there should be a similar output to the following:

AFTER DECRYPTION
ISAKMP Header
Initiator COOKIE: 21 5b 94 0d ad e6 69 9b
Responder COOKIE: 73 85 9d f0 23 d1 99 de
Next Payload: Hash
Version: 1.0
Exchange Type: Quick Mode
Flags: (Encryption)
MessageID: F758707B
Length: 348
Payload Hash
Next Payload: Security Association
Reserved: 00
Payload Length: 24
Data:
d5 53 1a f4 b0 1f 2d d5 14 10 12 49 f7 4b c9 d2
16 23 33 6f
Payload Security Association
Next Payload: Nonce
Reserved: 00
Payload Length: 68
DOI: IPsec
Situation:(SIT_IDENTITY_ONLY)
Payload Proposal
Next Payload: None
Reserved: 00
Payload Length: 56
Proposal #: 1
Protocol-Id: PROTO_IPSEC_ESP
SPI Size: 4
# of transforms: 1
SPI: c1 67 0a 68
Payload Transform
Next Payload: None
Reserved: 00
Payload Length: 44
Transform #: 1
Transform-Id: ESP_AES
Reserved2: 0000
Life Type: Seconds
Life Duration (Hex): 70 80
Life Type: Kilobytes
Life Duration (Hex): 00 46 50 00
Encapsulation Mode: Tunnel
Authentication Algorithm: MD5
Group Description: Group 2
Key Length: 256
Payload Nonce
Next Payload: Key Exchange
Reserved: 00
Payload Length: 24
Data:
7c 9e 9b e0 66 f5 8d e8 72 77 ce a6 10 cc 20 42
20 35 85 d2
Payload Key Exchange
Next Payload: Identification
Reserved: 00
Payload Length: 132
Data:
e2 c4 8d ac 4b 25 25 80 ac a2 42 61 e0 51 96 75
86 cb ca c7 3c df 37 9f cf 7c fc fd 5f b8 bf 66
92 34 a4 8f 2d 57 c9 d1 2d fb 9d a9 e9 37 41 27
60 ee e1 a9 ae ba 7b 82 35 6e 3a cc 79 4a bd d2
62 65 81 fb a0 fe 6a f2 27 98 39 1d fa 0f d0 ce
a7 f6 9e a2 b8 f2 72 4d bc 89 7f a2 05 01 ec a4
69 84 fe d2 70 45 5a b5 14 b3 a6 4c 8c 7b 80 e8
86 a0 64 03 79 bb 00 f7 6f 53 02 c1 1e c6 00 77
Payload Identification
Next Payload: Identification
Reserved: 00
Payload Length: 16
ID Type: IPv4 Subnet (4)
Protocol ID (UDP/TCP, etc...): 0
Port: 0
ID Data: 192.168.200.0/255.255.255.0
Payload Identification
Next Payload: Notification
Reserved: 00
Payload Length: 16
ID Type: IPv4 Subnet (4)
Protocol ID (UDP/TCP, etc...): 0
Port: 0
ID Data: 192.168.100.0/255.255.255.0
Payload Notification
Next Payload: None
Reserved: 00
Payload Length: 28
DOI: IPsec
Protocol-ID: PROTO_ISAKMP
Spi Size: 16
Notify Type: STATUS_INITIAL_CONTACT
SPI:
21 5b 94 0d ad e6 69 9b 73 85 9d f0 23 d1 99 de
Aug 20 16:59:36 [IKEv1]IP = 50.56.229.98, IKE_DECODE RECEIVED Message (msgid=f758707b) with payloads : HDR + HASH (8) + SA (1) + NONCE (10) + KE (4) + ID (5) + ID (5) + NOTIFY (11) + NONE (0) total length : 336

With this output, we can determine the Phase 2 settings and the Encryption domain that they are sending. The local network of the local ASA is 192.168.100.0/24 in this case but we can also confirm this with the Remotes request.

With this output, we can see that our settings should be the following:

Encryption: AES-256
Hash: MD5
PFS (DH Group): Is enabled as Group 2
Lifetime (Seconds): 28800
Lifetime (KB): 4608000

Remote Network: 192.168.200.0/24
Local Network: 192.168.100.0/24

Debug Output explained

Encryption is found by looking at 2 different data points. First being the Transform-Id which shows as ESP-AES and the other being the Key Length of 256.

Hash is determined by looking at the Authentication Algorithm which in this case is MD5.

If PFS is enabled, the data point Group Description will be present with a value, which in this case is Group 2. Note, group2 is the default group when PFS is enabled on the ASA with no group specified.

Lifetime, in this case, is presented twice. One type being Seconds and the other being Kilobytes. This is determined by looking the the Life Type and looking for its corresponding Life Duration that follows it. As with Phase 1, the Lifetimes are presented in HEX so these will need to be converted. The values of 28800 Seconds and 4608000 Kilobytes are actually the default values set by the ASA but we will configure these values manually so that you can see how to set them.

The encryption domain is also present in this output. These are found under the Payload Identification portions of the output. The first reference is the Remotes Encryption domain and the second reference the Local Encryption domain. The 2 ID Types the ASA understands are Subnet and Host. In this case, the ID Type is IPv4 Subnet for both. Protocol ID is also important but this is usually 0 which means the IP type. This encompasses TCP, UDP and ICMP which is why Port is also 0 as we are not referring to a specific TCP/UDP port. The ID Data is where the network is defined. In this case, the first reference is 192.168.200.0/24 and the second reference is 192.168.100.0/24.

Configuring Phase 2

With this information, the VPN should be able to be completed.

First we need to create the Transform Set. This is where Encryption and Hash are specified. The ESP-AES256-MD5 is just the name of the transform set.

crypto ipsec ikev1 transform-set ESP-AES256-MD5 esp-aes-256 esp-md5-hmac

Next we need to create an ACL for the VPN to reference for the encryption domain. Since I will be creating MAP 200, assuming no other MAP exists in VPNMAP, I will create the ACL as 200 for an easier reference. We will also use object-groups so that adding networks in the future will be cleaner and allow for ease of configuration.

object-group network VPN-LOCAL-200
  network-object 192.168.100.0 255.255.255.0
 
object-group network VPN-REMOTE-200
  network-object 192.168.200.0 255.255.255.0
 
access-list 200 permit ip object-group VPN-LOCAL-200 object-group VPN-REMOTE-200

Next we will need to create the new MAP entry.

crypto map VPNMAP 200 match address 200 <- This binds ACL 200 to this MAP.
crypto map VPNMAP 200 set peer 50.56.229.98
crypto map VPNMAP 200 set pfs group2
crypto map VPNMAP 200 set ikev1 transform-set ESP-AES256-MD5
crypto map VPNMAP 200 set security-association lifetime seconds 28800
crypto map VPNMAP 200 set security-association lifetime kilobytes 4608000

With all of this set, we should see both Phase 1 and Phase 2 complete.

Phase 1

ASA-LAB1(config)# show isakmp sa | b 50.56.229.98
1 IKE Peer: 50.56.229.98
Type : L2L Role : responder
Rekey : no State : MM_ACTIVE

Phase 2

ASA-LAB1(config)# show ipsec sa peer 50.56.229.98
peer address: 50.56.229.98
Crypto map tag: VPNMAP, seq num: 200, local addr: 50.57.228.150

access-list 200 extended permit ip 192.168.100.0 255.255.255.0 192.168.200.0 255.255.255.0
local ident (addr/mask/prot/port): (192.168.100.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.200.0/255.255.255.0/0/0)
current_peer: 50.56.229.98

#pkts encaps: 1129, #pkts encrypt: 1129, #pkts digest: 1129
#pkts decaps: 1224, #pkts decrypt: 1224, #pkts verify: 1224

If you are having some issues with Phase 2, I have another article here that covers some of the messages you may see when troubleshooting phase 2.

Configuring Identity NAT

In most cases, the Local Encryption Domain will have NATs associated with them on the ASA. This means they will try to NAT to their corresponding Public IPs or as an Outbound PAT and not use their Local Private IPs over the VPN. In this case, we want them to use their Private IPs so we should create an Identity NAT to ensure that NAT does not take place. I do not have any NATs on my ASA but to prevent any issues in the future, it is best to always have one in place. We can use the objects created earlier to create this NAT. This is where using the groups comes in handy for when you need to add more networks in the future, it will update both the Encryption Domain and the Identity NAT.

nat (any,OUTSIDE) source static VPN-LOCAL-200 VPN-LOCAL-200 destination static VPN-REMOTE-200 VPN-REMOTE-200 no-proxy-arp route-lookup

Notice I set the source interface as any. This is useful if your Encryption Domain uses multiple networks from different interfaces. This means it can all be done with one NAT and not multiple. The route-lookup at the end allows the ASA to pick the correct interface to route the Private IP internally.

For more references for NAT, please check out either my NAT article here or visit my friends NAT article here which covers Identity NAT in greater detail.

If you would like to know more or see more articles on VPNs, please let me know. You can contact me and I will do what I can to help.

The post VPN Troubleshoot (IKEv1 Site to Site) appeared first on Think Netsec.