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.

In this Article, we will be breaking down the right questions to ask when configuring a VPN and how to configure a Site to Site on the ASA.

ASA Version

The configuration of the Site to Site will be presented in different variations at the end of this Article. This is for those using either 7.x through 9.x code of the ASA as things are different between the code versions. I will start with 9 (8.3+) code since this should be the version most are running today and I will follow that up with 7.x-8.2. The Site to Site configuration between these code versions vary so I will present the same configuration in all variations between the code versions.

With all VPNs, we need to gather some information before we get started. Always ask the following as they are crucial to getting the VPNs configured correctly the first time. To jump straight to configuration, click here.

Is the remote side requesting Route Based or Policy Based VPNs?

This is helpful to understand first and foremost your limitations. Until 9.7+, the ASA was not capable of performing a true Route Based VPN. The ASA was only capable of performing Policy Based VPNs but there is always ways to kind of get around those limitations but we will cover that in another Article. For now, if the answer is Policy Based, move on to the next question.

What is the Peer IP?

We need to know the IP of the other VPN Concentrator at the other end. It is also helpful to know if this device is behind a NAT device. That means the devices IP address would actually be a Private IP and would have to be NAT’d to reach your ASA. If this is the case, issues could arise based on the Router settings in front of the device and how the device sends its Identity to your ASA. In most cases, you will be creating the Tunnel Group based on their Public IP so it is good to make sure that this is the Identity (IP) coming from their device to build the tunnel. You should also ask that the other side has NAT-Traversal and IPsec passthrough configured on their edge Router in this particular case as well.

What is the Authentication Method?

Authentication Method is usually a pre-shared-key (password) that the Remote side will share with you. You need to make sure that you have the same password so that you both have the same key on both ends. Sometimes, a Remote client will ask for RSA Certificates instead of pre-shared-keys but that is for another discussion.

If the answer to this question is pre-shared-key then you will need to find the best way to share this key with each other so that you can configure this on your ASA for their Peer IP.

What are the Phase 1 Settings?

With these settings, it is not necessary to understand each one in detail. All we need to do is make sure that our values match on both sides. I will do my best to provide a little bit of detail if you wish to pick the best for your needs but, in the end, your goal should be to match these values. All values in red are the default values that will be used when you create a policy.

Encryption: des | 3des | aes-128 | aes-192 | aes-256

The encryption is the way you plan on locking your data. The longer the bits, the harder it is to break the key. That is really oversimplifying encryption but in the end, it is easier to remember that the higher the bits, generally the safer/stronger it is. (The above is not in bit order, just encryption type then bit order. des is 64 bit and 3des is 192 bits)

Hash: md5 | sha-1

These are used for authenticating the source of an IP packet and verifying the integrity of its content. The VPN device will generate a hash and send it to the remote VPN device. It will use this to compare the hashes to check for packet integrity along with authenticating the remote device. If this value changes, then it can assume the segment was altered. As for which to choose for yourself, md5 has been broken before so I would recommend using sha-1. Now, md5 is faster to compute then sha-1 but usually this is negligible in network performance. Again, in the end, your goal should be to match the other sides settings.

Diffie-Helman (DH):  1 | 2 | 5 | 7

DH is used for the key exchange between your ASA and the Remote device. The larger the number, the more bits that are used, which in turn makes it that much more secure. Now, with that in mind, the larger the number, the longer the processing to use the keys. As always, we are just trying to match the other sides configuration for the most part so do not think too much into these values.

Lifetime(Seconds): 120 – 2147483647 (86400)

Lifetime is the amount of time Phase 1 will stay active until it needs to re-key the tunnel. You always want this value greater then the lifetime that you will use in Phase 2.

What are the Phase 2 Settings?

Phase 2 is the Second tunnel that will be built within the Phase 1 tunnel. If you have multiple networks that will be communicating with the remote side, each will get their own Phase 2. In most cases, every network combination will use the exact same Phase 2 settings. You will notice that the questions we need for Phase 2 are very similar to that of Phase 1 but do have some slight additions and options.

Encryption: esp-des | esp-3des | esp-aes | esp-aes-192 | esp-aes-256 | esp-null

You will see your options above are the same as they were in Phase 1, except for the esp keyword and null. The esp keyword is just letting you know that this being used on a ESP packet, which is what IPSec sends once traffic is encrypted. Encapsulating Security Payload (ESP) is its own protocol so it is not TCP or UDP so make sure the other side is allowing this protocol to their device. As for null, this means you can actually apply no Encryption on Phase 2 if you wish to do so but most never use this option.

Hash: esp-md5-hmac  | esp-sha-hmac | esp-none

Again, we see that esp keyword but this just means this is being used on a ESP packet. As for hmac, this stands for ‘hash message authentication code’ but this just means it is using this a hashing authentication mechanism. You will notice that there is a none option now. This is if you wish to not add a HMAC to the Phase 2 Tunnels which could hinder security a little but would allow for faster processing. In the end, we just need to match this setting to what the remote location is using.

Diffie-Helman (DH):  1 | 2 | 5 | Not Available

DH is not required in Phase 2 and is allowed to be omitted. This is an optional addition and gets referenced as Perfect Forward Secrecy (PFS) in most cases. This will allow for each Phase 2 Tunnel to generate their own keys. This does mean more security but also adds more computing cycles that your ASA will have to go through per packet.

Lifetime(Seconds): 120 – 2147483647 (28800)

Amount of time that Phase 2 can stay active before it needs to re-key the Phase 2 tunnel. This value should be lower then your Lifetime in Phase 1.

Lifetime(Kilobytes): 10 – 2147483647 | Unlimited (4608000)

Kilobyte Lifetime is a lifetime value that was not available in Phase 1. Just as the Lifetime(Seconds), this will tell the ASA how much data can go over the Phase 2 Tunnel before the Phase 2 Tunnel needs to perform a re-key. In this case, which ever Lifetime (Seconds or Kilobytes) is met first, the Tunnel will re-key. You can also set this value to Unlimited which will, in essence, turn this feature off. This comes in handy since some remote devices do not Support Kilobyte Lifetimes.

What is the Encryption Domain?

Lastly, we need to know the interesting traffic that will be traversing this VPN Tunnel. We need to match these exactly on both sides or issues will arise. Each Source and Destination Network combination will build their own Phase 2 Tunnel. All we need to know on the ASA is to configure an ACL of our Local Source Networks to the Remote Destination Networks. Note, that if your Netmasks are off, that the tunnel may sometimes build but not in all scenarios.

For example, if we have a 192.168.100.0/24 configured as our Local Network.If the Remote side configures our Network as 192.168.100.0/22 on their side of the VPN, only our Local ASA will be able to build the Phase 2 VPN Tunnel for that network. This is because our /24 range fits inside of their /22 IP range. Their device will accept our proposal and build with our /24, even though they have /22 configure. The reverse, however, would not work since their /22 is larger the our configured /24.

Building the Site to Site VPN

Now that we have gotten most of our questions out of the way, we can begin configuring the ASA for the new Site to Site.

We will use the following as an example configuration with the following answers.

Policy Based VPN

Peer IP: 50.56.228.50
Pre-shared-key: Th1nkN3t$ec
Phase 1-
   Encryption: aes-128
   Hash: sha-1
   DH Group: 2
   Lifetime: 86400

Phase 2-
   Encryption: esp-aes-256
   Hash: esp-sha-hmac
   PFS (DH): NA
   Lifetime (s): 28800
   Lifetime (k): 4608000

Encryption Domain:
   Local: 192.168.100.0/22
   Remote: 172.16.240.0/24

Our Public IP for this tunnel (their peer IP) will be 50.57.228.150

 ASA Code 9.x (8.3+)

I will be using a Crypto map called MyVPNMap but use the crypto map already configured on your device. If you do not have one, then please pick which ever map name works best for you. I will also be referencing my Internal Network name as INSIDE and my Outbound interface as OUTSIDE but please change these to match your device.

I like to first create my ACL that will be used as our Encryption Domain. We will also be creating object-groups for our Local and Remote Networks which will be useful for making changes later to the VPN and NAT.

object-group network MyVPN-LOCAL
 network-object 192.168.100.0 255.255.255.0

object-group network MyVPN-REMOTE
 network-object 172.16.240.0 255.255.255.0

access-list MyVPN extended permit ip object-group MyVPN-LOCAL object-group MyVPN-REMOTE

Now that we have created our object-groups and ACL, we should create our Identity NAT for our Encryption Domain. This is to ensure that communication does not try to use any NATs that may prevent this traffic from traversing the tunnel. (Default PAT Outbound for example). If you do not understand the NAT below, do not worry too much. I do have a Article that breaks down NAT if you wish to understand more but for now, I would recommend using the NAT below in most cases.

nat (INSIDE,OUTSIDE) source static MyVPN-LOCAL MyVPN-LOCAL destination static MyVPN-REMOTE MyVPN-REMOTE no-proxy-arp route-lookup

With our NAT and ACL now configured, we will add our Phase 1 configuration for the VPN. Notice I set my policy as 100 but any value here will work so long as you are not overriding an existing policy.

crypto ikev1 policy 100
 authentication pre-share
 encryption aes
 hash sha
 group 2
 lifetime 86400

To complete the Phase 1 configuration, we will create our Tunnel-group so that we can bind our pre-shared-key with our Peer IP.

tunnel-group 50.56.228.50 type ipsec-l2l
tunnel-group 50.56.228.50 ipsec-attributes
 ikev1 pre-shared-key Th1nkN3t$ec

With all of Phase 1 completed on your ASA, we will create our Transform Set (Phase 2 Encryption and Hash) for the VPN.

crypto ipsec ikev1 transform-set AES256-SHA esp-aes-256 esp-sha-hmac

Next, we will complete the VPN by configuring our Crypto map. Our Crypto map will bind our ACL and Phase 2 settings together with the Peer IP.

crypto map MyVPNMap 100 match address MyVPN
crypto map MyVPNMap 100 set peer 50.56.228.50
crypto map MyVPNMap 100 set ikev1 transform-set AES256-SHA

If this is your first VPN on your ASA, you will need to enable IKEv1, set you Identity to your ASAs IP address and bind your new Crypto Map to your Outside interface.

crypto map MyVPNMap interface OUTSIDE
crypto isakmp identity address
crypto ikev1 enable OUTSIDE

When the Remote side has completed their end of the VPN, you should be able to bring the Tunnel up and pass traffic if al routing etc is already accurate.

Here is all of the configuration for 8.3+ below in one snippet.

object-group network MyVPN-LOCAL
 network-object 192.168.100.0 255.255.255.0

object-group network MyVPN-REMOTE
 network-object 172.16.240.0 255.255.255.0

access-list MyVPN extended permit ip object-group MyVPN-LOCAL object-group MyVPN-REMOTE

nat (INSIDE,OUTSIDE) source static MyVPN-LOCAL MyVPN-LOCAL destination static MyVPN-REMOTE MyVPN-REMOTE no-proxy-arp route-lookup

crypto ikev1 policy 100
 authentication pre-share
 encryption aes
 hash sha
 group 2
 lifetime 86400

tunnel-group 50.56.228.50 type ipsec-l2l
tunnel-group 50.56.228.50 ipsec-attributes
 ikev1 pre-shared-key Th1nkN3t$ec

crypto ipsec ikev1 transform-set AES256-SHA esp-aes-256 esp-sha-hmac

crypto map MyVPNMap 100 match address MyVPN
crypto map MyVPNMap 100 set peer 50.56.228.50
crypto map MyVPNMap 100 set ikev1 transform-set AES256-SHA

! Only do the following if this is your first VPN

crypto map MyVPNMap interface OUTSIDE
crypto isakmp identity address
crypto ikev1 enable OUTSIDE

ASA 8.0-8.2 Code

object-group network MyVPN-LOCAL
 network-object 192.168.100.0 255.255.255.0

object-group network MyVPN-REMOTE
 network-object 172.16.240.0 255.255.255.0

access-list MyVPN extended permit ip object-group MyVPN-LOCAL object-group MyVPN-REMOTE

! This is an ACL used to prevent NAT from occurring.
access-list nonat extended permit ip object-group MyVPN-LOCAL object-group MyVPN-REMOTE

! This is where we bind the above 'nonat' ACL to state that this traffic is to be excluded from NAT
nat (INSIDE) 0 access-list nonat

crypto isakmp policy 100
 authentication pre-share
 encryption aes
 hash sha
 group 2
 lifetime 86400

tunnel-group 50.56.228.50 type ipsec-l2l
tunnel-group 50.56.228.50 ipsec-attributes
 pre-shared-key Th1nkN3t$ec

crypto ipsec transform-set AES256-SHA esp-aes-256 esp-sha-hmac

crypto map MyVPNMap 100 match address MyVPN
crypto map MyVPNMap 100 set peer 50.56.228.50
crypto map MyVPNMap 100 set transform-set AES256-SHA

! Only do the following if this is your first VPN

crypto map MyVPNMap interface OUTSIDE
crypto isakmp identity address
crypto enable OUTSIDE

ASA 7.x Code

object-group network MyVPN-LOCAL network-object 192.168.100.0 255.255.255.0 
object-group network MyVPN-REMOTE network-object 172.16.240.0 255.255.255.0 
access-list MyVPN extended permit ip object-group MyVPN-LOCAL object-group MyVPN-REMOTE

! This is an ACL used to prevent NAT from occurring. 
access-list nonat extended permit ip object-group MyVPN-LOCAL object-group MyVPN-REMOTE

! This is where we bind the above 'nonat' ACL to state that this traffic is to be excluded from NAT 
nat (INSIDE) 0 access-list nonat

crypto isakmp policy 100 
authentication pre-share 
ncryption aes 
hash sha 
group 2 
lifetime 86400

! This is the same as the tunnel-group command in the other code versions
isakmp key Th1nkN3t$ec address 50.56.228.50 netmask 255.255.255.255 no-xauth
 
crypto ipsec transform-set AES256-SHA esp-aes-256 esp-sha-hmac 
crypto map MyVPNMap 100 ipsec-isakmp
crypto map MyVPNMap 100 match address MyVPN 
crypto map MyVPNMap 100 set peer 50.56.228.50 
crypto map MyVPNMap 100 set transform-set AES256-SHA

! Only do the following if this is your first VPN 
crypto map MyVPNMap interface OUTSIDE 
crypto isakmp identity address 
isakmp enable OUTSIDE

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

AnyConnect SBL Requirements

• Must be using the AnyConnect client and the user must be using a Windows 7 or XP machine. This does not work with 8+ from what I have tested.

Instructions

1. Create the default configuration for the AnyConnect VPN.
   Note: If you plan on using a Self Signed Certificate the FQDN must be the IP of the firewall or the customer must setup a DNS entry for the FQDN.
2. Upload the SBL.xml page to the firewall.
   The key thing to change is the value between the <UseStartBeforeLogon> to true. If you are currently using a xml profile, you can also edit this line, or add, for this configuration to work.
   SBL XML file:
   

   SignOn.xml

   
   
   
   true
   true
   false
   All
   false
   Native
   false
   12
   false
   true
   false
   true
   IPv4,IPv6
   true
   DisconnectOnSuspend
   
   true
   Automatic
   SingleLocalLogon
   LocalUsersOnly
   false
   Automatic
   
   
   false
   false
   20
   4
   
   false
   
   
   
3. Add the SBL.xml file to the webvpn settings.

   ASA 8.x Code webvpn svc profiles SBL disk0:/SBL.xml ASA 9.x Code webvpn anyconnect profiles SignOn disk0:/SBL.xml

4. Add this profile along with the vpngina module to that group-policy that you applied to your AnyConnect VPN tunnel-group.

   ASA 8.x Code group-policy <groupname> attributes webvpn svc modules value vpngina svc profiles value SignOn ASA 9.x Code group-policy <groupname> attributes webvpn anyconnect modules value vpngina anyconnect profiles value SBL

5. Connect to the VPN as a new session to make sure that your new profile gets pushed from the Firewall.
6. If you used an Authorized Certificate – proceed to step 8, otherwise, follow step 9 for Self Signed Certificates

7. Self Signed Certificate steps

   1. Go to https://<Firewall IP>
   2. Click on the Lock icon in the URL. Click more information then click view certificate.
   3. Go to the details tab and click export. Save it as a X.509 certificate with chain (PEM) (*.crt,*.pem).
   4. Run Microsoft Management Console, by entering “mmc” in the run or search box (requires administrator permissions).
   5. In the MMC utility go to file and click on add/remove snap-in.
   6. You will want to add the certificates snap, and set it to computer then local computer.
   7. Open trusted root certificates and right click on certificates and click import.
   8. Locate the file you saved earlier, then import that file.
   9. Save the configuration. The name doesn’t matter.
8. Reboot the machine. Once rebooted you can click on switch users and see the following icon:
   

   

9. Use this button to login to the VPN before logging into the OS.

The post Anyconnect SBL (Start Before Logon) appeared first on Think Netsec.