VMware Edge Gateway VPN to Cisco ASA

KB ID 0001658

Problem

I was asked to setup a VPN to help out a colleague this week. When I had a look, one end turned out to be an Edge Gateway, I wasn’t that concerned, I’d done similar things in my prior role, I just didn’t have access to the vCloud or VMware at this datacenter.

Depite my best efforts on the ASA, the tunnel refused to come up, it took a little looking ‘under the covers’ to accurately diagnose the problem. But to save you my pain, I’ll post the setup of both ends so yours will be a little less stressful.

VMware Edge Gateway VPN Setup

Locate the Edge Gateway in vCloud Director > VPN > Create new VPN > Tick ‘Enable This VPN‘ configuration > Set the local and remote networks > Local ID is the local public IP of the Edge Gateway > Remote ID is the pubic IP of the Cisco ASA > Set the encryption protocol as AES256 > Copy the pre-shared-key (Warning: some browsers wont select all of the key, and you will end up characters short, make sure you have it all!) > OK.

On the ‘Firewall’ Tab allow all traffic TO and FROM the remote subnet, (behind the Cisco ASA).

Note: There no need to make a NAT Exemption.

Cisco ASA VPN Setup (For Edge Gateway)

Note: The version of Edge Gateway I was using, was using (once AES256 is selected) 

  • IKE Version: 1
  • Encryption:AES-256
  • Hashing: SHA
  • Diffie Hellman: Group 2
  • Perfect Forward Secrecy: Enabled (group 2)

I’m aware that newer Edge Gateways support IKEv2 but debugging the incoming requests told me mine was using IKEv1.

[box]

crypto ikev1 enable outside
!
crypto ikev1 policy 10
 authentication pre-share
 encryption aes-256
 hash sha
 group 2
 lifetime 86400
!
object network OBJ-vCloud-SN
subnet 172.16.10.0 255.255.255.0
object network OBJ-Site-SN
subnet 172.22.10.0 255.255.255.0
!
access-list VPN-INTERESTING-TRAFFIC extended permit ip object OBJ-vCloud-SN object OBJ-Site-SN
nat (inside,outside) source static OBJ-vCloud-SN OBJ-vCloud-SN destination static OBJ-Site-SN OBJ-Site-SN no-proxy-arp route-lookup
!
tunnel-group 123.123.123.123 type ipsec-l2l
tunnel-group 123.123.123.123 ipsec-attributes
pre-shared-key gT65C9Muwjx4q73tXaxu9gge6psqyr83qcu93xL8xkdk594yzNgf4jeoj7ax85Nc
isakmp keepalive threshold 10 retry 2
!
crypto ipsec ikev1 transform-set VPN-TRANSFORM esp-aes-256 esp-sha-hmac
!
crypto map CRYPTO-MAP 1 match address VPN-INTERESTING-TRAFFIC
crypto map CRYPTO-MAP 1 set pfs group2
crypto map CRYPTO-MAP 1 set peer 123.123.123.123
crypto map CRYPTO-MAP 1 set ikev1 transform-set VPN-TRANSFORM
!
crypto map CRYPTO-MAP interface outside
!

[/box]

WARNING

Above assumes;

  1. Your interfaces are called inside, and outside.
  2. You DO NOT have any existing VPNs configured, (if you do, change the name of the CRYPTO-MAP (above) to match the name of your cryptomap and use a higher number, e.g. ‘outside_map 2‘).

Troubleshooting Edge Gateway End of the VPN

You need access to the underlying VMware infrastructure > Select Networking and Security > Locate the NSX Edge > VPN > IPsec VPN > Show IPsec Statistics > Here you can see some meaningful error massages if theres a problem.

Troubleshooting Cisco ASA End of the VPN

I’ve covered this to death in the past, so rather than reinvent the wheel;

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

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

Related Articles, References, Credits, or External Links

NA

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

Cisco – Cracking and Decrypting Passwords (Type 7 and Type 5)

KB ID 0000940 

Problem

Decrypt Type 7 Cisco Passwords

The Internet is full of sites that have something like the tool below, tap your ‘encrypted’ password in and it will reveal the Cisco password.

 

Input Type 7 Obfuscated Password: Output Plain Text Password:

As you can see I’ve specifically written ‘obfuscated’ above, because the password isn’t actually encrypted at all. All that happens is the Vigenere algorithm is used to obfuscate the password. While tools like the one above are all well and good, your Cisco router will do exactly the same for you, to demonstrate, paste the following into the tool above.

107D1C09560521580F16693F14082026351C1512

Hopefully you will get the password Sup3rS3cr#tP@ssword.

Your router can also convert that to clear text for you;

[box]

Petes-Router#
Petes-Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Petes-Router(config)#key chain decrypt
Petes-Router(config-keychain)#key 0
Petes-Router(config-keychain-key)#key-string 7 107D1C09560521580F16693F14082026351C1512
Petes-Router(config-keychain-key)#exit
Petes-Router(config-keychain)#exit
Petes-Router(config)#exit
Petes-Router#
*Mar 1 00:04:48.691: %SYS-5-CONFIG_I: Configured from console by console
Petes-Router#show key chain decrypt
Key-chain decrypt:
key 0 -- text "Sup3rS3cr#tP@ssword"
accept lifetime (always valid) - (always valid) [valid now]
send lifetime (always valid) - (always valid) [valid now]
Petes-Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Petes-Router(config)#no key chain decrypt

[/box]

So whats the point of these type 7 passwords? Well the only real benefit of them is if someone is looking over your shoulder while you are looking at the config, they can’t see actual passwords in the config.

The passwords in my config are in clear text? That’s because there are three levels of password storage 0 (not encrypted), 7 (weakly encrypted), and (5 strongly encrypted). If you want to convert your config to display them as 7 you need to enter the service password-encryption command;

[box]

Petes-Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Petes-Router(config)#service password-encryption
Petes-Router(config)#

Before

username pete password 0 Password123

After

username pete password 7 142713181F13253920796166

[/box]

If Type 7 passwords are so weak, how do I use Type 5 passwords? When creating accounts use the secret command like so;

[box]

Petes-Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Petes-Router(config)#username petelong secret Password123
Petes-Router(config)#

Displays in the config as;

username petelong secret 5 $1$VkQd$Vma3sR7B1LL.v5lgy1NYc/

[/box]

Decrypting Type 5 Cisco Passwords

 

Decrypting a Type 5 Cisco password is an entirely different ball game, they are considered ‘secure’ because they are ‘salted’ (have some random text added to the password to create an MD5 hash) however that random salt is shown in the config.

[box]

username attackme secret 5 $1$TMnL$iAFs16ZXx7x18vR1DeIp6/

[/box]

Well armed with the salt and the hash, we can use exactly the same method that Cisco use to create the encrypted password, by brute force attacking the password, this might sound like a difficult piece of hacking ninja skill, but we simply use openssl on a Linux box (here I’m using CentOS 6.5), all you need is a wordlist.txt file (search the Internet).

Feed openssl the salt, and a piece of the hash (see the example above), and it will run through, (grep) the wordlist until it finds a match, where it spits out the decrypted password an the original hash like so;

[box]

[root@pnl-server1 ~]# openssl passwd -1 -salt TMnL -table -in wordlist.txt | grep 8vR1DeIp6
SECRETPASSWORD $1$TMnL$iAFs16ZXx7x18vR1DeIp6/
[root@pnl-server1 ~]#

[/box]

The decrypted password is SECRETPASSWORD

Note: The limitation here is the password has to be in the wordlist.txt file,but if you are adept at searching the Internet there are some impressive wordlist files out there, just make sure you use one that has full line breaks. Also remember, the longer the wordlist, the longer it takes.

Related Articles, References, Credits, or External Links

NA