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

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

Troubleshooting Phase 2 Cisco Site to Site (L2L) VPN Tunnels

KB ID 0000625 

Problem

It’s been over two years since I wrote Troubleshooting Phase 1 Cisco Site to Site (L2L) VPN Tunnels. I’ve always meant to come back and write the ‘Phase 2’ article but never got around to it.

This article is NOT intended to be a ‘fix all” for phase 2 problems, it’s designed to point you in the right direction to locate the source of the problem.

Solution

Here’s my fictional VPN setup,

1. Before you start: We are looking at phase 2 problems, MAKE SURE phase 1 has established!

[box]

Petes-ASA>
Petes-ASA> en
Password: ********
Petes-ASA# show crypto isakmp

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: 234.234.234.234
Type : L2L Role : responder
Rekey : no State : MM_ACTIVE <<<< Phase 1 has established!

[/box]

2. At the first site, issue a ‘show crypto ipsec sa’ command. Note: if you have a lot of tunnels and the output is confusing use a ‘show crypto ipsec sa peer 234.234.234.234’ command instead.

Click for Larger Image

Note: Yes I can zero in on the problem here, but your output may be different (And if you already know why are you reading this!).

3. Check the IP addresses and networks listed highlighted in yellow are correct, then repeat for the ones highlighted in pink (I don’t care if you don’t think it’s pink! I’m a man, I see in 16 colours like a Sinclair ZX Spectrum!). Check the access-list (above shown in blue text) that access-list should be referenced in the crypto map like so;

[box]

Petes-ASA# show run crypto
{Lots of output removed for the sake of space}
crypto map outside_map 1 match address outside_38_cryptomap <<<<Good!!
crypto map outside_map 1 set pfs
crypto map outside_map 1 set peer 234.234.234.234
crypto map outside_map 1 set ikev1 transform-set ESP-3DES-SHA <<<< Only seen after v8.4!
{Lots of output removed for the sake of space}

[/box]

4. Now we need to make sure that the traffic is NOT subject to NAT, issue a “show run nat” command;

[box]

Output with an Operating System Newer than 8.3 

Petes-ASA# show run nat
{Lots of output removed for the sake of space}
nat (inside,outside) source static NETWORK_OBJ_192.168.1.0_24 NETWORK_OBJ_192.168.1.0_24 destination static NETWORK_192.168.2.0_24 NETWORK_OBJ_192.168.2.0_2
{Lots of output removed for the sake of space}
Petes-ASA# show run object network <<<<Lets check those objects exist
object network obj_any
subnet 0.0.0.0 0.0.0.0
object network NETWORK_OBJ_192.168.1.0_24
subnet 192.168.1.0 255.255.255.0
object network NETWORK_OBJ_192.168.2.0_24
subnet 192.168.2.0 255.255.255.0


Output with an Operating System Older than 8.3

Petes-ASA# show run nat
nat (inside) 0 access-list inside_nat0_outbound
nat (inside) 1 192.168.1.0 255.255.255.0
Petes-ASA# show run access-list inside_nat0_outbound <<<<Lets make sure that ACL is correct
access-list inside_nat0_outbound extended permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0

[/box]

5. Now repeat the process at the other end;

Click for Larger Image

6. You will notice I’ve shown the SPI numbers in green, these should match (but be the opposite way round) at both ends. (Geek Note: These denote the TWO tunnels IPSEC brings up inside the original ISAKMP tunnel that it then passes information up one and down the other – like a two lane road).

7. If you compare both outputs look at the pkts encaps (in red) and the pkts decaps (in purple). In this case we can see that the tunnel is working as it should from the 234.234.234.234 site but no traffic is getting encrypted from the 123.123.123.123 site. THAT’S WHERE THE PROBLEM IS.

8. Now you know where the problem is you can issue a “debug crypto ipsec” command there. Then try to bring up the tunnel and analyse the output. Note: If debug shows nothing make sure there is NOT another crypto map pointing to the same subnet, with a different peer.

9. So on our ‘problem’ end we see something like;

So on that firewall, locate the ACL that is being used for the crypto map, and make sure its ‘hit count’ is going up as you try and send traffic over the VPN tunnel. If not then the ACL is wrong, there’s a routing problem or a subnet mask is wrong on the firewalls internal interface.

[box]

Petes-ASA# show run crypto
crypto ipsec ikev1 transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto map outside_map 1 match address outside_1_cryptomap << Here!
crypto map outside_map 1 set pfs
crypto map outside_map 1 set peer 234.234.234.234
crypto map outside_map 1 set ikev1 transform-set ESP-3DES-SHA
crypto map outside_map interface outside
crypto ikev1 enable outside
crypto ikev1 policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
Petes-ASA# show access-list outside_1_cryptomap
access-list outside_1_cryptomap; 1 element; name hash: 0xcf826bcb
access-list outside_1_cryptomap line 1 extended permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0 (hitcnt=93) 0xf965c6f9

[/box]

10. As a last resort recycle/restart the VPN Tunnel.

Cisco ASA 5500 – Reset / Recycle VPN Tunnels

11. You’ve done your best and still it wont establish! Then I would upgrade the ASA(s) to the latest OS (70% of the calls I log to Cisco TAC for VPN issues are fixed by simply upgrading them, 29% are caused by a configuration error, and 1% need a version of the operating system that has not been released yet). If you’re under warranty or Cisco SmartNet, you can then log a call to Cisco TAC. If not then I would suggest heading over to EE and asking for help. (You might even get hold of me).

Related Articles, References, Credits, or External Links

Troubleshooting Phase 1 Cisco Site to Site (L2L) VPN Tunnels

Cisco ASA Site to Site VPN’s

Cisco ASA5500 Site to Site VPN from ASDM

Cisco ASA 5500 Site to Site VPN (From CLI)