Passed CCDP!!
After 4 months of getting lost in design guides/books I finally decided to take a shot at the CCDP exam, and passed! I’m sure the experience I gained at worked helped out even more since a good portion of job is network design.
Much like the CCDA it covered the best practice and design for a broad array of different technologies IP addressing, remote access, security, virtualization, multicast, & various other topics. Just from my own experience the difficulty of the questions varied I found the layer 3 routing protocol and IP address questions to be quite simple, what I consider along the lines of just good common sense for any network design. Compared to the data center/virtualization technologies where I found them a little bit more difficult because I don’t typically find myself playing with NX-OS often. I will say however my previous experience managing and maintaining a few VMWare ESX clusters did come in handy.
I am looking forward to a small break before I start going down another path, whether it be CCNP: Security or towards my CCIE: R&S. So for now it’s back to blogging, labbing, working, and living life!
Now to figure out what more I need to complete my CCIE lab!
Verifying IPSec tunnels.
I know my last few posts have been focused on either how IPSec functions or the configuration so now that we know how to configure IPSec how can we make sure our IPSec VPN is up, functional, and passing traffic? Well there are a few different commands we can issue to check on the status or our IPSec VPN:
Show crypto isakmp sa
This command will tell us the status of our negotiations, here are some of the common ISAKMP SA status’
The following four modes are found in IKE main mode
- MM_NO_STATE* – ISAKMP SA process has started but has not continued to form (typically due to a connectivity issue with the peer)
- MM_SA_SETUP* – Both peers agree on ISAKMP SA parameters and will move along the process
- MM_KEY_EXCH* – Both peers exchange their DH keys and are generating their secret keys. (This state could also mean there is a mis-matched authentication type or PSK, if it does not proceed to the next step)
- MM_KEY_AUTH* – ISAKMP SA’s have been authenticated in main mode and will proceed to QM_IDLE immediately.
The following three modes are found in IKE aggressive mode
- AG_NO_STATE** – ISAKMP SA process has started but has not continued to form (typically do to a connectivity issue with the peer)
- AG_INIT_EXCH** – Peers have exchanged their first set of packets in aggressive mode, but have not authenticated yet.
- AG_AUTH** – ISAKMP SA’s have been authenticated in aggressive mode and will proceed to QM_IDLE immediately.
The following mode is found in IKE Quick Mode, phase 2
- QM_IDLE*** – The ISAKMP SA is idle and authenticated
- sh crypto ipsec sa – Now this output can really daunting at first just due to the amount of information that is displayed here but there are a few key things to watch out for. Such as the #pkts encaps/encrypt/decap/decrypt, these numbers tell us how many packets have actually traversed the IPSec tunnel and also verifies we are receiving traffic back from the remote end of the VPN tunnel. This will also tell us the local and remote SPI, transform-set, DH group, & the tunnel mode for IPSec SA.
- sh crypto session – This command will give you a quick list of all IKE and IPSec SA sessions.
Some of the common session statuses are as follows:
- Up-Active – IPSec SA is up/active and transferring data.
- Up-IDLE – IPSsc SA is up, but there is not data going over the tunnel
- Up-No-IKE – This occurs when one end of the VPN tunnel terminates the IPSec VPN and the remote end attempts to keep using the original SPI, this can be avoided by issuing crypto isakmp invalid-spi-recovery
- Down-Negotiating – The tunnel is down but still negotiating parameters to complete the tunnel.
- Down – The VPN tunnel is down.
So using the commands mentioned above you can easily verify whether or not an IPSec tunnel is active, down, or still negotiating. Next up we will look at debugging and troubleshooting IPSec VPNs
* – Found in IKE phase I main mode
** – Found in IKE phase I aggressive mode
*** – Found in IKE phase II quick mode
Encrypted GRE Tunnels.
One thing to keep in mind about IPSec tunnels, is the fact they do not scale very. After all a simple IPSec tunnel will not pass multicast traffic so routing updates will not traverse the tunnel requiring you to either rely on RRI (Reverse route injection) or static routes. So how do we get over this little obstacle, we run a GRE tunnel. (I covered GRE tunnels a few posts back)
Now there are a few ways we can do this, the first is to run the GRE tunnel over the IPSec tunnel, in this case the tunnel destination is at the other end of the IPSec tunnel and is matched by the ACL of the IPSec tunnel to ensure the traffic between the tunnel endpoints are encrypted. Another way is to apply an IPSec profile to the GRE tunnel. Let’s check out the configuration:
You will notice some of these configurations will look verify familiar such as the ISAKMP policy and the transform-set. However there are a couple of differences you will notice, such as the absence of a crypto map a few new profiles and keyrings.
This configuration allows us to nest specific hosts and pre-shared keys to a specific keyring, that we will apply later on.
The ISAKMP profile is where we specify what end points should match this policy, as well as tie in the keyring we created earlier. Keep in mind we can have multiple PSK’s in a keyring and multiple match identity in the same ISAKMP profile. The ISAKMP profile will simply find the right PSK in the keyring for the specific match identity address in the ISAKMP profile.
Now we have the IPSec profile, this is pretty close to what the crypto map did. It ties in ISAKMP so it knows what peers to match with and also the transform-set for phase 2 negotiations. You will also see in here we can set our Perfect Forward Secrecy (PFS) level, if one is desired.
So now that we have everything we need all we need to do is apply our IPSec profile to the tunnel interface.
The 2 commands that make this happen are the tunnel mode ipsec ipv4 this tells the tunnel that it is going to be running in IPSec mode. The next command tunnel protection ipsec profile LabIPSecProfile is how tie in the IPSec profile we created early.
Now that we have a GRE with IPSec protection our GRE tunnel is secure from the eavesdropping eyes of the internet. This GRE tunnel also provides us a transport mechanism to carry multicast traffic so we can run a routing protocol over this connection providing us with a scalable solution for managing site-to-site VPNs and our routing infrastructure.
Lab page is up!
Well, I’ve been buying Cisco equipment for some time now and I figured I finally got enough that I can show it off. I started off with a 3745 from a friend and two 2960’s I got from a good deal and slowly added some more routers. My end goal for this lab is to be capable of configuring anything I need whether it’s for studying or work related and I need build a customer network.
I’ll be adding even more as time goes on, and soon enough I will have enough to start labbing for the CCIE!
IPSec on a Cisco IOS router.
In my previous post I covered some basics on IKE and the process on which IPSec VPN’s form and negotiate their secure connection. So now I figured I’d continue that trend and cover the configuration of an IPSec VPN between 2 Cisco IOS routers.
So let’s check out a large portion of the configuration right here:
IKE Phase 1 and Phase 2 configuration with PSK authentication.
This configuration snippet (the first 3 lines) includes the ISAKMP policy used in phase 1 negotiations, which specifies the encryption, hash, & authentication method. I also want to mention you can have multiple ISAKMP polices on the same router, the thing to remember is the ISAKMP policies will be negoatiated from the top down. So the first ISAKMP policy that matches the peer’s ISAKMP profile with the lowest sequence number is the policy that will be used. Which means it is best practice to place the more secure ISAKMP policies at the beginning of your policy, to ensure they get used over a weaker policy.
Pre-shared key IPSec authentication
Right after the ISAKMP policy we have our PSK used to authenticate the specific peer. You can specify the address 0.0.0.0 0.0.0.0 to use the same key for all IPSec negotiations. So you would not need to specify a PSK for every particular peer.
Transform Set
Next we have our transform-set which provides us with our encryption options for phase 2 negotiations. Within the transform-set is were we can specify the encapsulation mode (tunnel or transport). Similar to the ISAKMP policy we can configure multiple transform-sets with completely different parameters in each one.
Crypto Map
Now the Crypto Map is where we tie in a lot of these parameters and start linking it to the peer. The first thing we set is the peer’s address, and then we will specify the transform-set that will be used with this particular connection. I want to mention we can configure multiple transform-sets for a single peer and during the negotiations a matching transform-set will be used. The last thing in this crypto-map is the match address 100 this is where we specify what traffic gets encrypted, this is known as interesting traffic. This matches to an ACL.
So all traffic that goes between the 192.168.1.0/24 and the 192.168.2.0/24 network will get encrypted.
Now the last thing we need to do is apply that crypto map to physical interface.
Now we can only have a single crypto map applied to a physical interface, so the next question is how do we configure multiple VPNs to terminate to a single router? Well we configure multiple entries using the same crypto map, we do this by using a different sequence number for each peer.
So from the above screen shot the sequence number after the crypto map is different, these sequence numbers can go from 1 – 65355 so you have more then enough sequence numbers to terminate multiple IPSec VPNs to a router. Of course you will never want to terminate 65355’s VPNs to a single due to performance.
The next thing I want to mention is how to configure a single crypto map to form VPNs using main mode or aggressive mode. This might sounds tricky at first since you can only have a single crypto map assigned to a single interface but it’s really pretty simple, all you have to do is use the same name you used for the existing crypto map.
So to recap the pieces we need to create a policy based IPSec VPN
- The ISAKMP Policy
- The Transforms-Set
- The Pre-shared key
- The Crypto Map
- Access-list
IKE main mode, aggressive mode, & phase 2.
Just like GRE tunnels, IPSec is found in every single network, whether it’s in the form a Lan2Lan tunnel or a client side remote access VPN. We all know IPSec secures communication between two endpoints using ISAKMP, Diffie-Hellman, and various other encryption and hashing algorithms but how exactly do these protocols work together. We know IPSec will form its tunnel after IKE Phase 1 and Phase 2 so let’s take a look at what goes on during this process:
IKE Phase 1
IKE Phase 1 works in one of two modes, main mode or aggressive mode now of course both of these modes operate differently and we will cover both of these modes.
Main Mode:
IKE Phase 1 operating in main mode works with both parties exchanging a total of 6 packets, that’s right 6 packets is all it takes to complete phase 1.
- The first packet is sent from the initiator of the IPSec tunnel to its remote endpoint, this packet contains the ISAKMP policy
- The second packet is sent from the remote endpoint back to the initiator, this packet will be the exact same information matching the ISAKMP policy sent by the initiator.
- The third packet is sent from the initiator to the remote endpoint, this packet contains the Key Exchange payload and the Nonce payload, the purpose of this packet is generate the information for the DH secret key
- This fourth packet as you would expect comes from the remote endpoint back to initiator and contains the remote endpoints Key Exchange and Nonce payload.
- The fifth packet is from the initiator back to the remote endpoint with identity and hash payloads, the identity payload has the device’s IP Address in, and the hash payload is a combination of keys (including a PSK, if PSK authentication is used)
- The sixth packet from the remote endpoint to the initiator contains the corresponding hash payloads to verify the exchange.
First packet in the IKE Phase 1
Second packet of the IKE Phase 1 process
Third packet in IKE Phase 1
Fourth packet in the IKE Phase 1 process
Fifth packet in the IKE Phase 1 process
Sixth and final packet in IKE Phase 1
Aggressive Mode:
IKE Phase 1 operating in aggressive mode only exchanges 3 packets compared to the 6 packets used in main mode. One downside in aggressive is the fact it not as secure as main mode.
- The first packet from the initiator contains enough information for the remote endpoint to generate its DH secret, so this one packet is equivalent to the first four packets in main mode.
- The second packet from the remote endpoint back to the initiator contains its DH secret
- The third packet from the initiator includes identity and hash payloads. After the remote endpoint receives this packet it simply calculates its hash payload and verifies it matches, if it matches then phase one is established.
IKE Phase 2
Now let’s look at IKE Phase 2, IKE Phase 2 occurs after phase 1 and is also known as quick mode and this process is only 3 packets.
- Perfect Forward Secrecy PFS, if PFS is configured on both endpoints the will generate a new DH key for phase 2/quick mode.
- Contained in this first packet from the initiator to the remote device are some of the hashes/keys negotiated from phase 1, along with some IPSec parameters IE: Encapsulation (ESP or AH), HMAC, DH-group, and the mode (tunnel or transport)
- The second packet contains the remote endpoint’s response with matching IPSec parameters.
- The last packet is sent to the remote device to verify the other device is still there and is an active peer.
That last packet concludes the forming an IPSec tunnel and the phase 1/2 process.
- Note: These 3 quick mode packets are encrypted
Quick Mode packets with encrypted payload.
All 9 packets of the Phase 1 (Main Mode) and Phase 2 process.
CCIE or Null! 