Tag Archives: AES-256

Cisco ASA Site To Site VPN IKEv2 “Using CLI”

Posted on by
42

KB ID 0001429

Problem

Note: This is for Cisco ASA 5500, 5500-x, and Cisco Firepower devices running ASA Code.

You want a secure IPSEC VPN between two sites using IKEv2.

Note: If the device you are connecting to does not support IKEv2 (i.e. it’s not a Cisco ASA, or it’s running code older than 8.4) then you need to go to the older version of this article;

Cisco ASA 5500 Site to Site VPN IKEv1 (From CLI)

Solution

Before you start – you need to ask yourself “Do I already have any IPSEC VPN’s configured on this firewall?” Because if it’s not already been done, you need to enable ISAKMP IKEv2 on the outside interface. To ascertain whether yours is on or off, issue a “show run crypto ” command and check the results, if you do NOT see  “crypto ikev2 enable outside” then you need to issue that command.

[box]

PetesASA# show run crypto
crypto ikev2 enable outside << Mines already enabled and its IKE version 2
crypto ikev2 policy 10
 encryption aes-256
 integrity sha256
 group 19
 prf sha256
 lifetime seconds 86400
crypto ikev2 enable outside

[/box]

1. I’m going to create access control lists next, one to tell the ASA what is “Interesting traffic”, that’s traffic that it needs to encrypt.

So below I’m saying “Don’t NAT Traffic from the network behind the ASA (10.254.254.0) that’s going to network behind the VPN device at the other end of the tunnel (172.16.254.0).

[box]

PetesASA(config)#object network Site-A-SN
PetesASA(config-network-object)#subnet 10.254.254.0 255.255.255.0
PetesASA(config)#object network Site-B-SN
PetesASA(config-network-object)#subnet 172.16.254.0 255.255.255.0
PetesASA(config)#access-list VPN-INTERESTING-TRAFFIC line 1 extended permit 
ip object Site-A-SN object Site-B-SN
PetesASA(config)#nat (inside,outside) source static Site-A-SN Site-A-SN 
destination static Site-B-SN Site-B-SN no-proxy-arp route-lookup

[/box]

2. Now I’m going to create a “Tunnel Group” to tell the firewall it’s a site to site VPN tunnel “l2l”, and create a shared secret that will need to be entered at the OTHER end of the site to site VPN Tunnel. I also set a keep alive value.

Note: Ensure the Tunnel Group Name is the IP address of the firewall/device that the other end of the VPN Tunnel is terminating on.

[box]

PetesASA(config)# tunnel-group 123.123.123.123 type ipsec-l2l
PetesASA(config)# tunnel-group 123.123.123.123 ipsec-attributes
PetesASA(config-tunnel-ipsec)# ikev2 remote-authentication pre-shared-key 1234567890
PetesASA(config-tunnel-ipsec)# ikev2 local-authentication pre-shared-key 1234567890
PetesASA(config-tunnel-ipsec)# isakmp keepalive threshold 10 retry 2
PetesASA(config-tunnel-ipsec)# exit

[/box]

3. Now we need to create a policy that will setup how “Phase 1” of the VPN tunnel will be established. It sets the encryption type (AES-256), the hashing/integrity algorithm (SHA-256), The Diffie Hellman group exchange version, and the Level of PRF (Pseudo Random Function). Finally it sets the timeout before phase 1 needs to be re-established. It sets the timeout value to 86400 seconds (That’s 1440 Minutes – or 24 hours if your still confused 🙂 ).

[box]

PetesASA(config)# crypto ikev2 policy 10
PetesASA(config-ikev1-policy)# encryption aes-256
PetesASA(config-ikev1-policy)# integrity sha256
PetesASA(config-ikev1-policy)# group 19
PetesASA(config-ikev1-policy)# prf sha256
PetesASA(config-ikev1-policy)# lifetime 86400

[/box]

4. We stated above that we are going to use AES-256 and SHA-256, for Phase 1, so let’s use the same for the IPSEC proposal (Phase 2), ‘Transform Set’.

[box]

PetesASA(config)# crypto ipsec ikev2 ipsec-proposal VPN-TRANSFORM
PetesASA(config-ipsec-proposal)# protocol esp encryption aes-256
PetesASA(config-ipsec-proposal)# protocol esp integrity sha-1

[/box]

5. Finally we need to create a “Cryptomap”, this is the ‘thing’ that fires up the tunnel, when the ACL INTERESTING TRAFFIC is used, it also defines the transform set for “Phase 2” of the VPN Tunnel, that will also use 3DES and SHA and PFS. And last of all we apply that Cryptomap to the outside interface.

[box]

PetesASA(config)# crypto map CRYPTO-MAP 1 match address VPN-INTERESTING-TRAFFIC 
PetesASA(config)# crypto map CRYPTO-MAP 1 set peer 123.123.123.123
PetesASA(config)# crypto map CRYPTO-MAP 1 set ikev2 ipsec-proposal VPN-TRANSFORM
PetesASA(config)# crypto map CRYPTO-MAP interface outside
 

[/box]

5. Don’t forget to save your hard work with a “write mem” command.

[box]

PetesASA(config)#
PetesASA(config)# write mem
Building configuration...
Cryptochecksum: 5c8dfc45 ee6496db 8731d2d5 fa945425

8695 bytes copied in 3.670 secs (2898 bytes/sec)
[OK]
PetesASA(config)#

[/box]

6. Simply configure the other end as a “Mirror Image” of this one.

ASA 5500 Site to Site IKEv2 VPN Copy and Paste Config

Note: This uses AES-256 and SHA-256. It also assumes your outside interface is called ‘outside’. Check! I’ve seen them called Outside (capital O), wan, and WAN.

[box]

!
crypto ikev2 policy 10
 encryption aes-256
 integrity sha256
 group 19
 prf sha256
 lifetime seconds 86400
crypto ikev2 enable outside
!
object network OBJ-SITE-A
subnet 10.0.0.0 255.255.255.0
object network OBJ-SITE-B
subnet 10.0.3.0 255.255.255.0
!

access-list VPN-INTERESTING-TRAFFIC extended permit ip object OBJ-SITE-A object OBJ-SITE-B
nat (inside,outside) source static OBJ-SITE-A OBJ-SITE-A destination static OBJ-SITE-B OBJ-SITE-B no-proxy-arp route-lookup
!
tunnel-group 2.2.2.2 type ipsec-l2l
tunnel-group 2.2.2.2 ipsec-attributes
ikev2 remote-authentication pre-shared-key 1234567
ikev2 local-authentication pre-shared-key 1234567
isakmp keepalive threshold 10 retry 2
!
crypto ipsec ikev2 ipsec-proposal VPN-TRANSFORM
 protocol esp encryption aes-256
 protocol esp integrity sha-1
!
crypto map CRYPTO-MAP 1 match address VPN-INTERESTING-TRAFFIC
crypto map CRYPTO-MAP 1 set peer 2.2.2.2
crypto map CRYPTO-MAP 1 set ikev2 ipsec-proposal VPN-TRANSFORM
crypto map CRYPTO-MAP interface outside
!
 
[/box]

Simply change the values in red where;

  • 10.0.0.0 255.255.255.0 is the network behind the ASA you are working on.
  • 10.0.3.0 255.255.255.0 is the destination network behind the device you are connecting to.
  • 2.2.2.2 is the peer IP address of the device you are attempting to connect to.
  • 1234567 Is the shared secret you will use at both ends.

Related Articles, References, Credits, or External Links

NA

Cisco ASA Site to Site VPN’sSite to Site ISAKMP VPN (Main Mode)

Posted on by

KB ID 0000213

Problem

As with most things, before you have a hope of fixing something, you will stand a better chance if you know how it works in the first place. Below is a quick run though of what’s happening with your site to site VPN‘s and how they work.

For the entire process we will have two Cisco ASA 5500 firewalls and a site to site VPN.

Solution

What’s an Initiator and a Responder?

1. Our Laptop 192.168.1.50 wants to talk to a server on the other site at 172.16.1.50

2. To get out of the local network the Laptop goes through the ASA at its local site, The ASA knows that traffic destined for 172.16.1.50 needs to be sent down the VPN tunnel, so it needs to bring up the tunnel. IT BECOMES THE INITIATOR, contacts the ASA on the other site THAT BECOMES THE RESPONDER.

3 Once that’s complete the tunnel is up and traffic can pass.

So how does it bring up the Tunnel?

To establish an ISAKMP VPN tunnel 3 things have to happen.

1. Phase 1 has to complete.

2. Phase 2 has to complete.

3. The Traffic has to be allowed to pass.

VPN Phase 1 (ISAKMP)

This stage brings up the first secure tunnel (eventually there will be three tunnels) and for it to establish the firewalls need to agree what they are going to do to bring up the tunnel, then Secure the tunnel. This process uses SIX MESSAGES (Note: We are dealing to Main Mode here not Aggressive mode). Both firewalls need a matching Phase 1 Policy to continue. And the Policy is proposed in MESSAGE1 and accepted in MESSAGE2.

A Phase 1 policy consists of,

1. The Authentication method (either a pre shared key or an RSA signature is usual).

2. The Encryption method (DES, 3DES, AES, AES-192, or AES-256).

3. The Hashing Method (MD5 or SHA).

4. The Diffie Helman Group (1, 2 or 5 usually).

5. Lifetime (In seconds before phase 1 should be re-established – usually 86400 seconds [1 day]).

MESSAGE 1

The Initiator sends policies that it proposes to use, for phase 1 to the other ASA.

MESSAGE 2

Providing the responder has a matching policy it will accept one of those proposed by the initiator and send it back in message 2.

 

Now the two ends have agreed HOW they will establish phase 1, they then need to agree on a “Shared Key” both ends must use the same shared key, but the shared key cant be sent between them because the network link is not secure. To do this they use a Diffie Hellman key exchange, this uses a mathematical process called modular exponentiation, a simple example of how that works (The math’s involved in a real key exchange are much more complicated!).

How Diffie Hellman works (simply)

Problem Site A and Site B need to use the same secret key (which will be a big long number). they cant send that number to each other because if they do it will be seen.

Solution:

Both sites pick a random number, and they have a common number, this common number can be passed between sites, In our example Site A chooses 4 and Site B chooses 5

Both sites use the common number and raise it by the power of the random number they are using so Site A arrives at 16, and Site B at 32.

The sites then send the number they have arrived at, to the other site.

Each site uses the other sites total and raises it to the power of their original random number, this results in them both having the same key, with only the numbers 2, 16 and 32 being passed between them.

Back to our VPN Tunnel

The next two messages are the initiator and responder swapping their Diffie Hellman information, Each side produces a DH Public Key, and mathematically computes a long number called a “Nonce”

MESSAGE 3

The initiator generates a “Public Key” also called the DH Public Value or Xa It also generates a Nonce or Ni and sends both of them to the responder.

MESSAGE 4

The responder generates a “Public Key” also called the DH Public Value or Xb It also generates a Nonce or Nr and sends both of them to the initiator.

At this point both the initiator and the responder can calculate the DH Shared secret key, they then use the DH Secret Key, the “Shared Secret” that is manually entered onto both peers, and the Nonce from the other peer to create 3 DIGITAL KEYS, because of the nature of Diffie Hellman each end will produce the same keys.

Key 1 = SKEYID_d Used to work out any future IPsec keying Key 2 = SKEYID_a Used for data integrity and authentication (IKE) Key 3 = SKEYID_e Used to encrypt all further IKE traffic.

MESSAGE 5

The initiator now sends its ID to the responder (this is either its IP address or a hostname). It also sends a “Hash” this authenticates the initiator to the responder as its made from the SKEYID, the pre-shared key and other information only known to the two peers.

MESSAGE 6

Message 6 is basically the mirror of Message 5, the responder sends its ID (IP or Hostname) Back the the initiator with its “Hash” and authenticates itself back to the initiator.

At this point both peers recalculate the hash they have received from the other peer, and they should both come out the same, if this happens then the IKE SA’s are established and phase 1 is complete.

So what’s PFS?

Perfect Forward Secrecy is a method by which new keys are generated, each new key is mathematically linked to the key that came before it, the prior key being a “Grandfather” key. With PFS enabled this link is broken so a key can not be forward/reverse engineered to guess a previous/new key value). Every new negotiation produces a new fresh key.

VPN Phase 2

Once Phase 1 has completed the second stage of the VPN can start. Like phase 1 this state also requires messages to be sent between the peers, IPsec usually executes in “Quick mode” this means that there are only 3 MESSAGES.

Note: If PFS is configured only on one end then it will fail at this point with an “Attribute not supported” error.

MESSAGE 1

The Initiator sends another Hash to the responder, this is similar to the one used in phase 1 but also includes info within this message to guarantee integrity.

The Phase 2 proposal includes

1. Encapsulation method either ESP or AH.

2. Hashing method (Integrity checking) either SHA-HMAC or MD5-HMAC.

3. Diffie Hellman Group (1, 2, or 5).

4. The SPI – This number is the LABEL for the end of the tunnel the initiator will use for outbound traffic.

Tunnel mode (Tunnel or Transport). A timeout in seconds is specified, as is the ID (usually the subnet of both ends of the tunnel).

MESSAGE 2

The Responder replies with its own “Hash” with the accepted proposal and its own SPI for outgoing encrypted traffic from the responder, and finally its own Key Exchange Payload.

Once this is complete both peers generate new DH secret keys and combine them with the SKEYID_d key from phase 1 to create keys for IPsec encryption.

MESSAGE 3

The final Message is sent from imitator to responder, and serves to inform the responder that its previous message was received.

Once phase 2 is complete IPsec SA’s have been established and the tunnel is up.

 

Related Articles, References, Credits, or External Links

NA