The Ultimate CCNA Security Study Guide

Chris Bryant, CCIE #12933 www.thebryantadvantage.com

Back To Index

Cryptography, VPNs And IPSec

Overview
What Is Cryptography?

Asymmetric and Symmetric Algorithms

Intro To RSA

Intro To Diffie-Hellman

What Is A VPN?

VPN Terminology

DES, TDES, And AES

PKI And The Certificate Authority

PKI Standards

IPsec

Internet Key Exchange

Site-To-Site VPNs

Creating An IKE Policy

Configuring Transform Sets

Crypto ACLs

Using SDM To Configure Site-to-Site VPNs

Intro To GRE

Configuring GRE Over IPsec Via SDM

Easy VPN Server And Client Configuration

"Hot Spots And Gotchas"

So What Is Cryptography, Anyway?

From your earliest Cisco studies, you're told of the importance of

cryptography and of not using any clear-text passwords - but you're not
really told how this cryptography takes place! Before we get into a
specific discussion of building VPNs, we're going to take a brief look at
some basic cryptography techniques.

If you want to read more about these techniques once you're done with
your CCNA Security exam, there are quite a few good non-Cisco-centric
books available today, and Wikipedia has some great entries on these
techniques as well.

Basically - very basically - the cryptography process takes data as you

and I and network intruders understand it and "translates" it into a data
pattern that you and I and network intruders do not understand. At some
point, generally after the data has been transmitted, the data is
"translated" back into a form that we're all able to read.

Here's a link to the Wikipedia page on the Enigma Machine, used in World
War II to create "unbreakable" ciphers:
http://en.wikipedia.org/wiki/Enigma_machine

You don't have to read the page for the CCNA Security exam, but take a
few minutes to check out the pictures!

It's not possible to list every cipher available today, but let's take a quick
look at just a few, starting with the substitution cipher. Basic substitution
ciphers are rather easy to break, since the pattern is simple and easy to
detect - a given letter is represented in the cipher by the same character
every time.

For example, the letter "E" could be represented by the pound sign (#) in
a simple substitution cipher. Since the letter "E" is one of the most
commonly used letters in any transmission, it would be relatively easy to
figure out what the pound sign indicates - and you just go from there! A
good cryptologist or decryption software program can break a substitution
cipher in a matter of minutes.

Even simpler is the transposition cipher, where the extent of the

cryptography is simply rearranging the plaintext characters.

More complex ciphers are based on the Caesar Cipher, a simple but
effective encryption technique. All letters in the clear-text data are
substituted with a letter "X" positions down from the original letter. For
example, a shift of 4 would result in "A" being substituted with the letter
"E", and so forth.

By itself, that is simple to crack, but more effective ciphers such as the
Vigenere cipher use multiple Caesar ciphers to encrypt data. Since the
Vigenere ciphers uses multiple substitution alphabets, it is said to be a
polyalphabetic cipher.
Some people find ciphers interesting, while others.... do not. For those of
you who'd like to learn more about these ciphers, I've included some
Wikipedia links at the end of this section. They're not required reading for
the CCNA Security exam, but I do recommend you take just a few
minutes to check out the illustrations and see how these ciphers operate!

Encryption Algorithms And Operation

We have two major classes of encryption algorithms - asymmetric and

symmetric. The key to keeping them straight is remembering how many
keys each uses:

Symmetric algorithms use one single key for both encryption and
decryption.

Asymmetric algorithms use one key to encrypt data and a separate
key to decrypt the same data. The actual key exchange is built into
the operation of asymmetric algorithms.

You might think that two keys are always better than one, but that's not
quite the case. One of the strongest algorithms in operation today, the
Advanced Encryption Standard (AES), is a symmetric algorithm.

Here's a list of asymmetric and symmetric algorithms:

Symmetric: DES, TDES (Triple DES, sometimes expressed as 3DES),

AES, IDEA (International Data Encryption Algorithm), RC4, and Blowfish.

Asymmetric: Diffie-Hellman, DSS (Digital Signature Standard), RSA,

Elliptical Curve and Cramer-Shoup.

These two algorithm types are not mutually exclusive; for example, the
Diffie-Hellman asymmetric algorithm can be used as a key exchange
protocol for symmetric algorithms.

Another major difference between the two algorithm types is

speed. Symmetric algorithms can run 500 - 1000 times faster than an
asymmetric algorithm. Why? Because the mathematical operation used
by asymmetric algorithms are much more complex than those used by
symmetric algorithms.

That speed difference makes symmetric algorithms (RC4 in particular) a

better choice for bulk encryption.

Asymmetric algorithms certainly have their place, though! In this section,

we'll see RSA and Diffie-Hellman mentioned often in IOS Help. Before we
go into our discussion of VPNs, let's take a quick look at both of these
important algorithms.

RSA

The letters RSA stand for the originators of this algorithm (Ron Rivest, Adi
Shamir, and Len Adelman). Regarding this asymmetric encryption
algorithm, Wikipedia notes:

"RSA is widely used in electronic commerce protocols, and is believed to

be secure given sufficiently long keys and the use of up-to-date
implementations."

Other RSA facts of note:

RSA is the first algorithm to be considered suitable for both

encryption and digital signatures

Attacks designed to thwart RSA include the branch prediction

analysis (BPA) attack, timing attacks, and the adaptive chosen
ciphertext attack

RSA uses two keys, one public and the other private

Lack of speed can be an issue, especially when compared to

symmetric algorithms

Has been in use since 1977, and in the encryption business,

that's an eternity

To read much more about RSA, visit the RSA Wikipedia page:

http://en.wikipedia.org/wiki/RSA

The Diffie-Hellman(-Merkle) Algorithm

The phrase "secure key exchange over a non-secure channel" would

seem to be the ultimate in Catch-22s, but the DH algorithm makes that
possible.

A few DH notes:

The two endpoints must agree on a non-secure, non-secret numeric

value before DH can go to work. Note that these are non-secret
numbers, not keys.

On occasion, you'll see DH referred to as Diffie-Hellman-Merkle. The

new name recognizes the contribution of Ralph Merkle. Cisco
documentation refers to this algorithm as Diffie-Hellman, and that's
the way I expect you to see it on the exam; I do want you to know
about that name change, however.

DH isn't perfect; it is susceptible to a man-in-the-middle attack, since

the actual DH process does not include authentication

For CCNA Security exam purposes and the VPN discussions in this
section, that first point is of particular interest.

A Word Or Two About SHA

You'll see quite a few references to SHA in this section, so let's take a few
minutes to cover some SHA basics.

There are two different versions of the Secure Hash Algorithm. The first,
SHA-1, creates a 160-bit message digest. SHA-1 is the more commonly
used of the two variations, but in 2005 some security issues were
detected in SHA-1. That's when SHA-2 came along.

SHA-2 is actually a term used to encompass four different algorithms:

SHA-224, -256, -384, and -512. The number in each variation indicates
the length of the message digest produced by that variation (in bits).

What's A VPN?

VPNs are often referred to as tunnels. We can apply security rules and
policies to this tunnel without applying them to other WAN
communications. In the following exhibit, a VPN has been created
between two routers. Security policies can be enforced on the VPN
between those two routers without affecting any WAN communications
involving the bottom router.

VPNs offer three vital functions, all of which are important in today's
networks. Note that two of these occur at the receiver, and one at the
sender. Data origin authentication allows the receiver to guarantee the
source of the packet.
Encryption is just that - the sender encrypts the packets before sending
them. If an intruder picks them off the wire, they will have no meaning.

Integrity is the receiver's ability to ensure that the data was not affected or
altered in any fashion as it traveled across the VPN.

There are three different protocols we can use to create this tunnel.
Originally defined in RFC 1701, Generic Routing Encapsulation enables a
Cisco router to encapsulate a packet in an IP header. When the packet
reaches the remote router, the header is stripped off. GRE's drawback is
that there's no encryption scheme, and that's a pretty big drawback.

Defined in RFC 2661, The Layer 2 Tunneling Protocol (L2TP) is actually a

hybrid of Microsoft's Point-to-Point Tunneling Protocol (PPTP) and Cisco's
own Layer 2 Forwarding (L2F). Again, the major drawback is that L2TP
doesn't have an encryption scheme either.

This giant flaw is corrected by IP Security, generally referred to as IPsec.

IPsec does offer encryption along with authentication, and that's why
you'll see more IPsec in today's networks than L2TP or GRE. That's also
why we're going to spend the majority of this section working with IPsec.

VPN Terminology

Before we get to a more specific discussion of VPNs, there are some

general terms you should know. We'll review the terms from the
beginning of this section as well.
Data Confidentiality means that only the devices that should see the data
in an unencrypted form will see the data that way. Generally, this is
achieved by one endpoint encrypting the data and sending it across the
link in that fashion, with the second endpoint decrypting the data.

Data Integrity means that the recipient of the data can guarantee that the
received data is the same as the transmitted data - in short, that the data
was not altered during transport.

Data Origin Authentication guarantees that the data originated from a

specific endpoint.

Anti-replay protection (sometimes just called "replay protection") protects

against replay attacks, a malicious repeat and/or delay of a valid
transmission.

Replay attacks can begin innocently enough. In this example, Router

C requests proof of identity from Router A. Router A responds with proof
of identity.

The problem is, an Intruder is listening to the conversation and copies

Router A's proof of identity.

After A and C are done with their conversation, the Intruder starts a
conversation with C, pretending to be A. When C asks for proof of
identity, the Intruder submits A's ID, and C will accept it.
Anti-replay protection can use several different methods of defeating such
an attack, including the one-time use of tokens for the proof of identity or
by using sequence numbers; a repeated sequence number will be
rejected.

We have two different VPN types, remote access and site-to-site.

Remote access VPNs require both endpoints to have VPN software
installed, where site-to-site VPNs do not require that software. In this
section, we'll concentrate on configuring site-to-site VPNs.

Data Encryption Standard (DES)

The Data Encryption Standard (DES) was developed in 1976, and a few
problems have developed with DES since then.

The main issue is that the key used by DES to encrypt data is only 56 bits
in size. (A key is a random string of binary digits.) Thirty years ago, that
was fine, but then again floppy disks used to be the largest storage unit
any of us needed! Depending on which documentation you read, DES
keys can be broken in any time frame from 24 hours to ten minutes.

DES can uses both block and stream ciphers. The block ciphers used by
DES are Electronic Code Book (ECB) and Cipher Block Chaining (CBC).

ECB is not particularly secure. Its basic operation doesn't do much to

hide data patterns, as this illustration of the encryption process shows
(illustration courtesy of Wikipedia)

The real issue is that each 64-bit plaintext block will be encrypted by the
same 56-bit key. That issue does not exist with CBC, since every
plaintext block has an XOR (Exclusive OR) operation run against it with
the previous ciphertext lock before it's encrypted. Here's how the CBC
works (illustration courtesy of Wikipedia)
Triple DES (TDES) is just what it sounds like - the DES encryption
procedure is run three times, with three different 56-bit DES keys. That's a
total of 168 bits, but the effective security provided is considered to be
only 112 bits.

TDES is sometimes referred to as 3DES, and you may see it expressed

that way on your exam; however, to avoid confusion with TDES variations
2TDES and 3TDES, the "3DES" abbreviation is discouraged. You do see
TDES expressed as "3DES" in Cisco documentation, and if you see it on
the CCNA Security exam, I expect you to see it expressed in that fashion.

The Advanced Encryption Standard (AES) is being rapidly adopted by

governments and organizations around the world. AES can run on any
Cisco router that has IPSec DES/3DES capability. The actual function of
AES is far beyond the scope of this exam, but it really is quite fascinating.
Visit www.wikipedia.org and search on "advanced encryption standard"
to learn exactly how it works.

Public Key Infrastructure

Once your end users start using VPNs - especially when they can "VPN
in" from home, rather than coming to the office anytime they need access
to network resources - you're going to quickly realize you need a single,
scalable "gatekeeper", and one such solution is a Public Key
Infrastructure (PKI).

Configuring PKIs can become complex, and of course that level of

complexity will vary from one network to the next. The basics of PKI do
not vary, though, so let's take a look at these basics - starting with the
Certificate Authority (CA).

Basically, the CA is the big cheese of the PKI. The term often associated
with a CA is "trusted third party", and by that we mean that the CA is
trusted by all parties involved, and the CA is also considered an
independent, nonpartisan entity.

The CA's main purpose is "signing" and issuing certificates to users.

These certificates state that the user possessing the certificate is indeed
who he/she says he is. (The CA has a self-issued and self-signed
certificate as well, the root certificate.)
For example, if "Dan" has a public key, the CA will make sure Dan is who
he says he is, and the CA will then issue a digital certificate saying just
that. The digital certificate is a combination of Dan's public key and the
CA's private root key.

The CA may be global, such as www.verisign.com, or it may be a CA in

your very own organization. The key here (no pun intended) is that you
better trust your CA, because the entire public key encryption process is
built around the CA verifying users and their public keys.

Now that the CA has verified Dan and Bob, public key encryption can be
put into use. In this example, Dan will send an email to Bob using PKE.
Dan will actually use Bob's public key to encrypt the message. The email
is then sent to Bob, who will use his private key to de-encrypt the email.

E-commerce website also use CAs as a trusted third party to help prove
to potential customers that they are who they say they are. For example,
you'll find this SSL certificate on every e-commerce page on my website,
with the name of the site scrolling across the image:

Note the phrase "click to verify". When you do so, the following certificate
is displayed in another window:
Take it from me - you really have to prove to your CA that you are who you
are before they'll issue a certificate!

This information is more than enough for most, but if you want even more
information on the chain of CAs involved, you can click on Repository.

Here's just a portion of the Certificate Repository. Note the CA Root

Certificate at the very top, and the mention of SHA-1 throughout.

The Public Key Cryptography Standards

The RSA website describes PKCS nicely:

"The Public-Key Cryptography Standards are specifications produced by

RSA Laboratories in cooperation with secure systems developers
worldwide for the purpose of accelerating the deployment of public-key
cryptography....the PKCS documents have become widely referenced and
implemented. Contributions from the PKCS series have become part of
many formal and de facto standards....."

Here's a direct link to the PKCS webpage:

http://www.rsa.com/rsalabs/node.asp?id=2124

I wouldn't spend a lot of time memorizing all of the PKCS standard

numbers, and that website is optional reading for the CCNA Security
exam. Having said that, here are some commonly used PKCS standard
numbers and a summary of their content:

PKCS #1: RSA Cryptography Standard. Note that there's no longer a

PKCS #2 or #4 as they've been incorporated into #1.

PKCS #3: Diffie-Hellman Key Agreement Standard (self-explanatory)

PKCS #5: Password-Based Cryptography Standard

PKCS #7: Cryptographic Message Syntax Standard, which relates to this

section in that "this standard describes general syntax for data that may
have cryptography applied to it, such as digital signatures and digital
envelopes."

PKCS #10: Certification Request Syntax Standard, which "describes

syntax for a request for certification of a public key, a name, and possibly
a set of attributes".

IPsec (Or IPSec)

IP Security (IPsec) allows us to authenticate and/or encrypt every IP

packet in a particular data stream.

Some other basic IPsec facts:

IPsec runs at L3 of the OSI model. In comparison, SSL and SSH run
from L4 - L7.

Applications do not need to be specifically designed to utilize IPsec

IPSec uses checksums and hashing algorithms such as MD5 and

SHA1 to assure data integrity

The officially spelling is "IPsec", not "IPSec", but since you see it
both ways in most network documentation and possibly on your
CCNA exam, you'll see it spelled both ways in this section

The IPsec suite is an open-standard suite, and here are the members of
this suite:

Authentication Header (AH), which defines a method for

authentication and securing data

Encapsulating Security Payload (ESP), which defines a method for
authenticating, securing, and encrypting data

Internet Key Exchange (IKE), which negotiates the security
 parameters and authentication keys

The IPSec Packet Format

Defined in RFC 2402, Authentication Header (AH) offers solid security -- it

provides data origin authentication as well as offering optional anti-replay
protection. The drawback with AH is that the authentication it provides for
the IP Header is not complete. That's because some of the IP fields can't
be correctly predicted by the receiver - these are mutable fields which
may change during transmission. AH will successfully protect the IP
packet's payload, though, which is really what we're interested in.

To sum it up, AH does offer:

data origin authentication

data integrity

anti-replay protection (optional)

AH does not offer data confidentiality.

The Encapsulating Security Payload (ESP) does just that - as you can
see from the IPSec packet illustration, there is an ESP Header and ESP
Trailer surrounding, or encapsulating, the data. ESP offers all of the
following:

data origin authentication

anti-replay protection

data confidentiality

Comparing AH and ESP, you might be wondering why you'd ever choose
AH over ESP. Here are a few things to consider:

ESP is more processor-intensive than AH. If your data does not require
data confidentiality, AH may meet all your requirements.

ESP requires strong cryptography, which isn't available and/or allowed

everywhere. AH has no such requirement.

Both ESP and AH can be run in one of two modes - Tunnel Mode and
Transport Mode. In Tunnel mode, the entire IPSec process is
transparent to the end hosts; specialized IPSec gateway devices handle
the IPSec workload.

The tunnel mode process encrypts the entire IP packet, and then that
encrypted packet is placed into another IP packet. That encapsulating
packet will have the IP addresses configured on the tunnel endpoints, and
it's those tunnel IP addresses that will be used to route the packet.
Transport mode encrypts the IP payload, but the IPSec header is inserted
directly after the IP header in the packet. As a result:

There is no protection for the original IP address

The original IP address will be used for routing

Only data from the Transport layer up is protected by IPSec (easy
enough to remember!)

The Internet Key Exchange (IKE)

Basic IPSec operation is much like running PPP over ISDN. We're even
going to use some of the same terms! (If you haven't done that before,
don't worry, we'll go through the key exchange process step by step.)

Before we take a broad overview of how IPSec works, there's one more
term we need to discuss - the Internet Key Exchange, or IKE.

Defined in RFC 2409, IKE has a lot to do! IKE must negotiate the
parameters of the communication channel, authenticate both endpoints,
handle the exchange of public keys, and manage the keys afterwards.

Remember how we consider EIGRP to be a "hybrid" because it has

characteristics of both distance vector and link state protocols? IKE is a
hybrid as well, but for a much different reason - IKE is a combination of
three protocols.

SKEME, which enables public key encryption for authentication

ISAKMP, (Internet Security Association and Key Management
Protocol), which defines how messages will be exchanged

Oakley, which defines the mechanism for key exchanges

IKE is a two-phase process, and there are three phases we need to know
about. (Yeah, I know. Stick with me here!)

Phase 1 is where two IPSec-enabled devices come to an agreement on

what methods will be used to exchange data over a secure
communications channel. As you'll see later in this section, we have
multiple options for authentication in Phase 1, but typically you'll configure
a Pre-Shared Key (PSK) for that purpose.

This can be done in either Main or Aggressive modes - Aggressive is a

little faster, but none of the information exchanged in Aggressive mode is
encrypted. Both modes will be illustrated later in this section.

This phase will result in a Security Association being created for the
ISAKMP process itself - an IKE SA. A Security Association is simply
a contract between two hosts as to the IPSec parameters that will be used
for communications between the two.

In contrast to most SAs, an IKE SA is bidirectional. Only one IKE SA is

required for two IPSec peers to communicate, and that particular SA
negotiates the following:

The hash algorithm to use, whether that be MD5 or SHA


The authentication method

The encryption algorithm

The Diffie-Hellman group. (Four of these are predefined in IKE)

Phase 1.5 can use Extended Authentication (Xauth) for additional

security. This is an optional phase. It's also quite controversial in some
circles, and it's occasionally described with phrases not suitable for a
family study guide.

The SA previously mentioned will be used in Phase 2. In Phase 2, the

IPSec peers must agree on the attributes to be used to create the SAs for
AH and ESP. The SAs created in Phase II are unidirectional.

To review - Phases 1 and 2 are mandatory; phase 1.5 is optional.

Configuring Site-to-Site IPSec VPNs

Configuring a site-to-site VPN is basically a five-step process.

Process Initialization via "interesting traffic"

IKE Phase 1 (IKE SA negotiation)

IKE Phase 2 (IPSec SA negotiation)

Data Transfer

Tunnel Termination

IPSec doesn't just start working by itself - like ISDN, it requires interesting
traffic to be sent by a host. This interesting traffic initializes the IPSec
process. Just as we used access lists to define interesting traffic with
ISDN, a crypto access-list will define interesting traffic for our VPN. We'll
configure one later in this section.

The routers will now enter IKE Phase I. Assuming we're running Main
mode, there will be six messages overall. The initiator will first transmit
proposals for the encryption and authentication schemes to be used. At
this point, IKE's looking for an ISAKMP policy that's a match at both
endpoints.
In the second exchange of IKE Phase I, the devices will exchange Diffie-
Hellman public keys; from this point on, the rest of the negotiation is
encrypted.

The initiator and recipient authenticate each other in the third exchange of
Phase I, using an encrypted form of their IP addresses. The IKE SA is
then established and Phase II can begin. At this point, we have an
ISAKMP tunnel (or ISAKMP session) established, and an IPSec tunnel
can now be built in Phase 2.

If we had chosen to run IKE in Aggressive Mode, this would have been a
three-message process.
The initiator packets everything needed for the SA negotiation in the first
message, including its Diffie-Hellman public key.

The recipient responds with the acceptable parameters and authentication

information, and its Diffie-Hellman public key.

The initiator then sends a confirmation that it received that information,

and we're done!

IKE Phase 2 has one mode, Quick mode. This is also a three-message
process. The initiator proposes parameters for the IPSec SA, the
recipient responds with a list of acceptable parameters, and the initiator
then transmits a message that lets the responder know that message 2
was received and processed. This message is called proof of liveness.

With the IPSec SA in place, we have an IPSec tunnel, and the hosts can
now exchange data.
Once the data exchange is complete, the tunnel can be torn down. This
tunnel termination can be configured to occur after a certain number of
bytes have passed through the tunnel, or perhaps after the tunnel have
been up for a certain number of seconds. But what if traffic is flowing
through the tunnel at the same time the tunnel's supposed to be torn
down? No fear - a new Security Association can be agreed upon while
the existing one is still in place.

Creating An IKE Policy

Before configuring the IKE policy, make sure ISAKMP is enabled with the
crypto isakmp enable command. It's supposed to be on by default, but
we all know how that is!
R1(config)#crypto isakmp enable

To display the current IKE policies, run show crypto isakmp policy.
R1#show crypto isakmp policy

Global IKE policy

Default protection suite
encryption algorithm: DES - Data Encryption Standard (56 bit keys).
hash algorithm: Secure Hash Standard
authentication method: Rivest-Shamir-Adleman Signature
Diffie-Hellman group: #1 (768 bit)
lifetime: 86400 seconds, no volume limit

We're not going to use the default, however. We'll create a custom policy
with the crypto isakmp policy command. Policies can be assigned
priorities, as shown below by IOS Help. The lower the number, the higher
the priority, with 1 being the highest priority. There is no default.
R1(config)#crypto isakmp policy ?
<1-10000> Priority of protection suite

R1(config)#crypto isakmp policy 100

IOS Help shows the options for the IKE policy.

The options for authentication are preshared keys, RSA Signature, and
RSA Encryption. The default is RSA Signature. We'll configure the policy
to use preshared keys.
R1(config-isakmp)#authentication ?
pre-share Pre-Shared Key
rsa-encr Rivest-Shamir-Adleman Encryption
rsa-sig Rivest-Shamir-Adleman Signature

R1(config-isakmp)#authentication pre-share

The options for encryption are DES, AES, and 3DES (TDES). The default
is DES. We'll use 3DES.
R1(config-isakmp)#encryption ?
3des Three key triple DES
aes AES - Advanced Encryption Standard.
des DES - Data Encryption Standard (56 bit keys).

R1(config-isakmp)#encryption 3des

We do have options for the Diffie-Hellman group, so we'll use group 5.

The default is group 1.
R1(config-isakmp)#group ?
1 Diffie-Hellman group 1
2 Diffie-Hellman group 2
5 Diffie-Hellman group 5

R1(config-isakmp)#group

The hash algorithm will be either MD5 or SHA. The default is SHA, so
we'll set the policy to MD5.
R1(config-isakmp)#hash ?
md5 Message Digest 5
sha Secure Hash Standard

R1(config-isakmp)#hash md5

Finally, we need to set the SA lifetime. The default is the maximum

number of seconds, 86,400, which equals 24 hours. We'll set that to
42,400 seconds.
R1(config-isakmp)#lifetime ?
<60-86400> lifetime in seconds

R1(config-isakmp)#lifetime 42400

show crypto isakmp policy displays both policies on the router - the
default and the one we just wrote.
The exact same policy has been configured on R3. R1 and R3 are on the
same Serial segment, 172.12.12.0 /24, with their router number as the
last octet.
R3(config)#crypto isakmp policy 100
R3(config-isakmp)#hash md5
R3(config-isakmp)#lifetime 42400
R3(config-isakmp)#group 5
R3(config-isakmp)#authentication pre-share
R3(config-isakmp)#encryption 3des

When IKE Phase 1 negotiation begins, the initiator sends its policies to
the receiver. The receiver will then attempt to find a match for that policy
among its own policies, and the receiver starts this search with its lowest
numbered policy.

If that policy doesn't match, the receiver checks its next lowest numbered
policy. It's vital to remember that just because the first policy comparison
doesn't result in a match, the recipient will continue to search for a
match.

In the following example, R2 checks its own policies for a match with the
policy sent by the initiator, R1. R2 begins with its lowest-numbered policy,
100. That policy requires SHA and the incoming policy names MD5, so
there's no match.

R2 then checks its Policy 200, which requires DES, and that does not
match the incoming policy. Policy 300 matches all the
requirements, so the negotiation is successful.

You'd think that all five values would have to match for the negotiation to
be successful, but that's not quite true. Here's a list of the parameters
and what has to happen for successful negotiation.

Hash: exact match

Encryption: exact match

Authentication: exact match

DH Group number: exact match

Lifetime: Remote peer policy must have lifetime equal to or less
than initiator. If less, the lower value is used.

Since our policies referred to preshared keys, we better create them! The
crypto isakmp key command does this. Along with the key itself, the IP
address of the remote peer must be configured.

Watch the syntax with this command, as it differs between IOS

versions. Not all versions have the 0 / 6 option you'll see below on R1.
IOS Help shows that the options are slightly different between the IOS
versions we're using. As a CCNP and world-class Cisco engineer, this is
something you need to get used to. Trust me.

If Phase I is successful, an ISAKMP SA will be created. We can verify this

with show crypto isakmp sa.
R3#show crypto isakmp sa
dst src state conn-id slot

R3#

As always, if the output of a show command shows nothing, there's

nothing to show! The ISAKMP SA doesn't exist until the entire IPSec
configuration is in place and interesting traffic has started the process.
That's one frustrating thing about IPSec - there's a good deal of
configuration, but you really can't test it until the entire thing is done.
Configuring The IPSec Transform Sets

An IPSec Transform Set is simply a group of individual parameters that

will enforce a security policy. The endpoints must agree exactly on which
encryption and algorithms will be used to create the IPSec SA. If there's
an exact match, the IPSec process continues; if there's no match, the
process is terminated and the session torn down.

As with ISAKMP policies, multiple transform sets can be configured and

sent to a remote peer. The remote peer will compare each set received
against its own transform sets, and when a match is found, the IPSec SA
will be built.

A transform set is built with the crypto ipsec transform-set command, as

shown here on R3. Options are shown with IOS Help, and then the exact
same transform set is configured on R1.

IPSec SA Lifetimes

The default lifetime of an IPSec SA is 1 hour, but IOS Help reveals that the
command that changes this value on a global basis sets the IPSec SA
lifetime in seconds. Always use IOS Help to double-check the measuring
unit in use by any given command. The below command sets this value to
30 minutes (1800 seconds). The SA lifetime can also be based on
volume.

Crypto Access Lists

Remember way back when I mentioned that interesting traffic triggers the
IPSec process? We're finally getting to the part of IPSec that identifies
this interesting traffic - crypto access lists.

Crypto ACLs are used to define the traffic that is protected by IPSec.
While most of the Crypto ACLs you write will be configured to affect
outbound traffic, they can also be configured to affect inbound traffic.
Outbound crypto ACLs identify the traffic to be secured by IPSec, and
traffic not named by the crypto ACL will be sent in clear text.

Inbound crypto ACLs can identify traffic that should have been protected
by IPSec, but wasn't. Such traffic will be discarded.

Extended ACLs can serve as Crypto ACLs, but there's a major difference
in operation between the two.

With Extended ACLs, matched traffic is permitted and unmatched traffic

denied (by the implicit deny). With Crypto ACLs, matched traffic is
encrypted and unmatched traffic is unencrypted but still transmitted.

If inbound Crypto ACLs are configured, unprotected traffic that matches

the ACL is dropped - simply because it's unprotected.

From personal experience, I can tell you that the hardest part of writing
Crypto ACLs for IPSec peers is making sure they're symmetrical. Let's
use the following network to show you what I mean.
To have traffic on R1's ethernet segment protected by IPSec if it's
destined for the ethernet segment on R2, R1's ACL will look like this:
access-list 123 permit ip 172.10.1.0 0.0.0.255 172.10.5.0 0.0.0.255

For traffic on R2's ethernet segment to be protected by IPSec if it's

destined for the ethernet segment on R1, R2's ACL will look like this:
access-list 123 permit ip 172.10.5.0 0.0.0.255 172.10.1.0 0.0.0.255

When you're configuring IPSec and concentrating on the many details

we've discussed in this chapter, it's really easy to write the same ACL on
both routers. Whether it's on the exam or on a production network,
double-check your ACLs - if they're the same, there is a problem.

We don't want the two ACLs to be an exact copy of each other - rather,
we need them to be mirror images, exact reverses of each other.

Once the Crypto ACLs are written, it's time to apply them to the
appropriate interfaces. That's just one purpose of a Crypto Map. Let's
look at the basic command to write a Crypto Map along with some
options, courtesy of IOS Help.
R3(config)#crypto map CCNP ?
<1-65535> Sequence to insert into crypto map entry
client Specify client configuration settings
isakmp Specify isakmp configuration settings
isakmp-profile Specify isakmp profile to use
local-address Interface to use for local address for this crypto map

R3(config)#crypto map CCNP 100 ?

ipsec-isakmp IPSEC w/ISAKMP
ipsec-manual IPSEC w/manual keying
<cr>

R3(config)#crypto map CCNP 100 ipsec-isakmp ?

dynamic Enable dynamic crypto map support
profile Enable crypto map as a crypto-profile
<cr>

R3(config)#crypto map CCNP 100 ipsec-isakmp

R3(config-crypto-map)#

We've successfully created a crypto map named CCNP, sequence

number 100, that will use ISAKMP to establish the IPSec Security
Associations. We're now in crypto map configuration mode, where the
ACL, peers, transform sets, and security association lifetime for this
particular crypto map can be set. Any SA lifetime value configured here
overrides the globally configured value, but we'll leave that value alone for
now.
R1(config)#crypto map CCNP 100 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
R1(config-crypto-map)#match address 123
R1(config-crypto-map)#set peer 172.12.123.2
R1(config-crypto-map)#set transform-set R1_TRANSFORM_SET

R1(config-crypto-map)#interface serial 0/1

R1(config-if)#crypto map CCNP
R1(config-if)#
*Apr 1 17:27:04.807: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

R3(config)#crypto map CCNP 100 ipsec-isakmp

R3(config-crypto-map)#match address 123
R3(config-crypto-map)#set peer 172.12.12.1
R3(config-crypto-map)#set transform-set R3_TRANSFORM_SET
R3(config-crypto-map)#set security-association lifetime ?
kilobytes Volume-based key duration
seconds Time-based key duration

R3(config)#int s0/1
R3(config-if)#crypto map CCNP
R3(config-if)#
*Mar 1 04:10:12.260: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

Before sending interesting traffic to start the entire process, we'll enable
debug crypto ipsec on R3 to allow us to see the details of the SA
negotiations. Near the bottom of the debug output, you can see that two
separate unidirectional SAs have been built.
R3#debug crypto ipsec
Crypto IPSEC debugging is on
R3#ping 172.12.12.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.12.12.1, timeout is 2 seconds:

*Jun 6 23:51:14.999: IPSEC(sa_request): ,

(key eng. msg.) OUTBOUND local= 172.12.12.3, remote= 172.12.12.1,
protocol= AH, transform= ah-md5-hmac (Tunnel),
lifedur= 1800s and 4608000kb,
spi= 0x91791CF(152539599), conn_id= 0, keysize= 0, flags= 0x400A.
*Jun 6 23:51:17.579: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 172.12.12.3, remote= 172.12.12.1,
protocol= AH, transform= ah-md5-hmac (Tunnel),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x2
*Jun 6 23:51:17.583: Crypto mapdb : proxy_match
src addr : 172.12.12.3
dst addr : 172.12.12.1
protocol : 0
src port : 0
dst port : 0
*Jun 6 23:51:17.591: IPSEC(key_engine): got a queue event with 2 kei
messages
*Jun 6 23:51:17.591: IPSEC(initialize_sas): ,
(key eng. msg.) INBOUND local= 172.12.12.3, remote= 172.12.12.1,
protocol= AH, transform= ah-md5-hmac (Tunnel),
lifedur= 1800s and 4608000kb,
spi= 0x91791CF(152539599).!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 48/49/52 ms
R2#, conn_id= 0, keysize= 0, flags= 0x2
*Jun 6 23:51:17.591: IPSEC(initialize_sas): ,
(key eng. msg.) OUTBOUND local= 172.12.12.3, remote= 172.12.12.1,
protocol= AH, transform= ah-md5-hmac (Tunnel),
 lifedur= 1800s and 4608000kb,
spi= 0x945FCBB6(2489306038), conn_id= 0, keysize= 0, flags= 0xA
*Jun 6 23:51:17.595: Crypto mapdb : proxy_match
src addr : 172.12.12.3
dst addr : 172.12.12.1
protocol : 0
src port : 0
dst port : 0
*Jun 6 23:51:17.595: IPSEC(crypto_ipsec_sa_find_ident_head): reconnecting
with
the same proxies and 172.12.12.1
*Jun 6 23:51:17.595: IPSec: Flow_switching Allocated flow for sibling
80000002
*Jun 6 23:51:17.595: IPSEC(policy_db_add_ident): src 172.12.12.3, dest
172.12.
12.1, dest_port 0

*Jun 6 23:51:17.599: IPSEC(create_sa): sa created,

(sa) sa_dest= 172.12.12.3, sa_proto= 51,
sa_sp
i= 0x91791CF(152539599),
sa_trans= ah-md5-hmac , sa_conn_id= 2001
*Jun 6 23:51:17.599: IPSEC(create_sa): sa created,
(sa) sa_dest= 172.12.12.1, sa_proto= 51,
sa_spi= 0x945FCBB6(2489306038),
sa_trans= ah-md5-hmac , sa_conn_id= 2002

By running show crypto isakmp sa, we can see that the SA is in place and
is active.
R2#show crypto isakmp sa
dst src state conn-id slot status
172.12.123.1 172.12.123.2 QM_IDLE 1 0 ACTIVE

QM_IDLE is what we do want to see; here are a few other potential

messages we don't want to see, along with a quick explanation of each
courtesy of Cisco's website.

A common error message is MM_NO_STATE, and if you think that sounds

bad, you're right! This indicates a fundamental problem with Phase I, most
likely a mismatch of attributes between peers.

MM_KEY_EXCH can indicate a misconfiguration of the peer's IP address,

and this message can also be generated by a misconfigured pre-shared
key.

Two other excellent IPSec troubleshooting commands are show crypto

map and show crypto ipsec transform-set.
R2#show crypto map
Crypto Map "CCNP" 100 ipsec-isakmp
Peer = 172.12.123.1
Extended IP access list 123
access-list 123 permit ip host 172.12.123.2 host 172.12.123.1
Current peer: 172.12.123.1
Security association lifetime: 4608000 kilobytes/1800 seconds
PFS (Y/N): N
Transform sets={
R2_TRANSFORM_SET,
}
Interfaces using crypto map CCNP:
Serial0/1

R2#show crypto ipsec transform-set

Transform set R3_TRANSFORM_SET: { ah-md5-hmac }
 will negotiate = { Tunnel, },

Transform set R2_TRANSFORM_SET: { ah-md5-hmac }

will negotiate = { Tunnel, },

To let you see what the IPSec process looks like when the SA expires, I
left the debug running until the one we built in this chapter expired.

*Jun 7 00:48:18.270: IPSEC(lifetime_expiry): SA lifetime threshold

reached, exp
iring in 111 seconds

*Jun 7 00:50:10.074: IPSEC(key_engine): got a queue event with 1 kei

messages
*Jun 7 00:50:10.074: IPSEC(key_engine_delete_sas): rec'd delete notify
from ISA
KMP
*Jun 7 00:50:10.078: IPSEC(key_engine_delete_sas): delete SA with spi
0x877193D

*Jun 7 00:50:10.086: IPSEC(delete_sa): deleting SA,

sa_spi= 0xF8BA8F2(260810994),
sa_trans= ah-md5-hmac , sa_conn_id= 2003,
*Jun 7 00:50:10.086: IPSEC(delete_sa): deleting SA

sa_spi= 0x877193DD(2272367581),
sa_trans= ah-md5-hmac , sa_conn_id= 2004,
(identity) local= 172.12.123.2, remote= 172.12.123.1,
*Jun 7 00:50:10.090: IPSec: Flow_switching Deallocated flow for sibling
8000000

IPSec vs. Cisco Encryption Technology

CET is a Cisco-proprietary security feature that provides some data

encryption, but it does not offer AH, ESP, or anti-replay attacks. CET isn't
a bad choice for data that's being exchanged only between Cisco routers,
but otherwise the additional features of IPSec make it the better choice.

A Warning About ACLs And IPSec

As you work with more complex combinations of Cisco technologies,

you're going to have to be very careful with your access lists. You should
especially be careful with port ranges in ACLs, because you can always
block ports that are needed by network services or applications.

This is particularly true with IPSec, because three primary IPSec protocols
use ports that must not be blocked by ACLs:

ESP, protocol number 50

AH, protocol number 51

IKE, UDP port 500

Make sure your network's ACLs are not inadvertently blocking these ports
and protocol numbers anywhere you have IPSec running.

To review, here's the process we used to create this site-to-site IPSec

VPN:

Created the ISAKMP policy

Created the IPSec transform set

Defined interesting traffic with the crypto access-list

Created the crypto map - AND applied it to the proper interface

Made sure our ACLs allowed the appropriate port numbers

Configuring A Site-To-Site VPN With SDM

I know there's a lot of information in this section, so allow me to remind

you that site-to-site VPNs do not require VPN software to be configured on
the endpoints.

We do have two different VPN termination device types to be aware of,

though. A headend VPN device is found at the central HQ of the network,
where a VPN access device is also a VPN term device; however, these
are found at remote office locations.

When it comes to configuring a site-to-site VPN, life is made much easier

with SDM. Just click on Configure and then VPN in the row of buttons on
the left-hand side.

From the Create VPN Window that will appear by default, select Create
Site-To-Site VPN and then Launch the selected task. Always take a few
minutes to read SDM's great descriptions, especially when you're studying
for a certification exam.
The next window gives you the option of Quick Setup or the Step-by-Step
Wizard. In this lab, we'll select the Step-by-Step Wizard.

If you're in a hurry - or have no real desire to configure your own IKE

policy or transform set - you can pick Quick Mode.

With Quick mode, you'll still be prompted for:

the local interface for the VPN connection

the type of peer for this VPN connection (typically "peer with static IP
address") and the IP address for that peer

the option to use a pre-shared key or digital certificates

the source interface "where traffic to be encrypted originates"

the IP address and subnet mask of the destination "where encrypted

traffic terminates"

With Quick mode, you will *not* be prompted for:

IKE policy details - there are default IKE policies to choose from, but
you can't configure or change the details of these policies

Transform set details - same deal as the IKE policies

Got it? Good! Let's get back to our site-to-site VPN!

The Connection Information window is next, and here we'll enter the local
interface to use for the VPN connection, the IP address of the peer, and
the pre-shared key. Take note of the other options.

In the next window, we're prompted for an IKE proposal. We could accept
the default proposal, but here I'll click Add to create a new IKE policy.
Here are the values we'll set in this proposal.

The new policy appears in the IKE Proposal window. Here's a real-world
tip for you - even though you just created that new policy, the default
policy will still be highlighted. Be sure to highlight the new policy before
clicking Next.

The next window is our Transform Set window. Again, we have a default
we can choose, and we'll do that in the next lab, but here I'll click Add to
add a new Transform Set.
Here's the Transform Set we'll use in this lab.

No extra charge for the reminder of the difference between Tunnel and
Transport mode! :)

After clicking OK and then Next, that Transform Set is selected. On the
next screen, we've got to decide what traffic will use this VPN. I've
entered it manually here, but you can also write an ACL to perform this
task.

As always, SDM presents a summary of the configuration before

delivering it, which happens when you click Finish.

Earlier in this section, I mentioned that each router in a VPN must have a
mirror image of the other's configuration, not an exact copy. This can be
a little tricky at the CLI, but in SDM we simply use the Generate Mirror
button at the very bottom of the Edit Site To Site VPN screen.
Since this is a lab, I'll defy SDM's warning and paste that config to the
peer. After doing so, we do need to do one more thing on the peer - apply
the crypto map to the interface!
Branch(config)#int fast 0/1
Branch(config-if)#crypto map SDM_CMAP_1
Branch(config-if)#
03:51:49: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

Very easy step to forget. So don't. :)

Back in SDM, I clicked Test Tunnel on the Edit Site To Site VPN window,
and the tunnel is up.

Here's the output of show crypto ipsec sa on the SDM router. When you
see packet encaps and decaps, you're in business.
HQ#show crypto ipsec sa

interface: FastEthernet0/1
Crypto map tag: SDM_CMAP_1, local addr 10.2.1.1
 protected vrf: (none)
local ident (addr/mask/prot/port): (172.31.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.10.10.0/255.255.255.0/0/0)
current_peer 10.2.1.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 29, #pkts encrypt: 29, #pkts digest: 29
#pkts decaps: 29, #pkts decrypt: 29, #pkts verify: 29

The Return Of GRE

The Generic Routing Encapsulation (GRE) tunneling has actually made a

comeback, since GRE can do things that IPSec can't do, and vice versa.

We used to love GRE's multiprotocol capabilities, but that's not as

important to us in today's networks as it once was. Combined with a lack
of strong security features, GRE was pretty much dead for quite a while.

IPSec is very secure, but it does have drawbacks. Originally, IPSec

couldn't carry multicast traffic, and you may still run into some trouble with
that in the field - the first IOS release that allowed IPSec to carry multicast
traffic was 12.2(4)T, and there are plenty of routers out there running an
earlier IOS.

The latest IOS versions can't handle all multicast traffic, however.
Multicast traffic generated by OSPF and EIGRP can't be carried by basic
IPSec - we've got to run a combination of IPSec and GRE, commonly
called GRE over IPSec.

By combining GRE and IPSec, each protocol helps to compensate for the
other's limitation:

IPSec adds data integrity and confidentiality that GRE does not offer

GRE offers the ability to carry routing protocol traffic, which IPSec
does not offer

Why call it "GRE over IPSec" rather than "IPSec over GRE"? Because
the GRE encapsulation happens first, and then that encapsulation is
encapsulated again, by IPSec. In effect, we have a GRE tunnel inside an
IPSec tunnel.

Our old friends tunnel mode and transport mode are still around as well.
Interestingly enough, Cisco's website recommends the use of transport
mode over tunnel mode with GRE over IPSec. Using transport mode
results in less total overhead, and we're all in favor of that!

To review -

Just as with a site-to-site VPN, the crypto ACL indicates the traffic to
be encrypted

GRE over IPSec allows the transmission of dynamic routing protocol
multicast traffic

Whether you use the CLI or SDM, always make sure to apply the
crypto map to the interface!
Hey, that's enough talking about GRE over IPSec. Let's configure it with
SDM!

Configuring A GRE Tunnel Over IPSec Via SDM (PDQ)

As always, we'll start by clicking the Configure button, and from there
choose VPN.

From the main VPN window, we'll select Site-to-Site VPN. The Site-to-
Site VPN window gives us two main choices:

When I choose the GRE over IPSec option, this illustration is shown.

After clicking Launch the selected task, we're given some reminders of
why we're using GRE - good review material for your exam, too!
The next screen asks us for some required GRE-over-IPSec information,
namely the tunnel source and destination and the address of the tunnel
itself. Note that for the source, we can specify either the interface or the
IP address, where the only option for destination is the IP address.

Did you notice the Details button in the previous screen? Clicking that
gives you quite a bit of information regarding that interface. We don't
have any of these features on this interface, but if we did, it's good
information to have in mind for the tunnel config.
Now back to the config! We're not going to create a backup tunnel, but
the next screen gives us the option to do so.

The next window prompts us for the pre-shared key or to indicate the use
of digital certificates.

The next window is the IKE Proposal selection area, and we'll accept the
default IKE policy.

The next window is the Transform Set selection area, and we'll accept the
default there as well.

We're then prompted to identify the routing protocol that will run over the
tunnel.

Earlier in this section, we had the opportunity to create a backup tunnel.

If you're running a routing protocol over the tunnels, you may need to alter
some metrics so that one tunnel is preferred over the other.

For EIGRP, for example, I'd suggest working with the delay option rather
than the other metrics as it's easier to get the result you want. With static
routing, you could alter the AD of the routes with the distance option.

We now have the option of tunneling all traffic, or using Split Tunneling to
send select traffic through the tunnel. We'll enable ST here and configure
traffic destined for 10.0.0.0 /8 to use the tunnel.

Real-world note: By default, using Split Tunneling with NAT and PAT on
the same router can cause problems. Cisco's website offers several
solutions to this issue, should you run into that problem in the real world.

As always, we're presented with a Summary of the configuration we've

chosen.

At this point, the VPN is down, since we haven't configured the other side
of it!
We need an exact reverse of this configuration - a mirror image - to place
on the downstream router. SDM has a great tool to create this mirror at
the verrrrrry bottom of the screen - the Generate Mirror button!

Real-world note: If you can't find something in SDM, always look at the
very bottom of the screen.

After clicking Generate Mirror, we get that mirror configuration, along with
warnings about how this config should be used only as a guide and
should not be pasted into the remote router.

Since we're in a lab environment, I'm going to do just what they told me
not to do, and save this config and then paste it into the downstream
router.

Here's the mirror configuration:

crypto isakmp policy 1
authentication pre-share
encr 3des
hash sha
group 2
lifetime 86400
exit
crypto isakmp key secretkey address 172.31.1.1
crypto ipsec transform-set ESP-3DES-SHA esp-sha-hmac esp-3des
mode tunnel
exit
ip access-list extended SDM_1
remark SDM_ACL Category=4
permit gre host 10.2.1.2 host 172.31.1.1
exit
crypto map SDM_CMAP_1 1 ipsec-isakmp
description Apply the crypto map on the peer router's interface having IP
address 10.2.1.2 that connects to this router.
set transform-set ESP-3DES-SHA
set peer 172.31.1.1
 match address SDM_1
set security-association lifetime seconds 3600
set security-association lifetime kilobytes 4608000
exit

After copying that config to the downstream router, I applied that crypto
map to the physical interface and created a tunnel interface manually:
interface Tunnel0
ip address 10.1.1.2 255.255.255.0
ip mtu 1420
tunnel source FastEthernet0/1
tunnel destination 10.2.1.1

Going back to the original router, the Edit Site-to-Site VPN screen shows
the VPN is now up.

The Following Easy VPN Client And Server Information Is Optional

Reading.

It's Not On Your CCNA Security Exam, But It's Everywhere In Real-
World Networks. Read, And Enjoy!

What's So "Easy" About Easy VPN?

Easy VPN consists of the following:

Easy VPN Server

Easy VPN Remote

Sounds easy enough! Seriously, the real benefit of Easy VPN is that
security policies written at the Server level can then be pushed out to
Clients. As a result, the Clients have the most up-to-date policies without
the network admins - that's you and me - having to visit them individually.

Quite a few different Cisco devices can act as Easy VPN Servers. I will not
list each here, but here are the more common ones:

VPN 3000 concentrators

Cisco 7500,7200,7100,3600,2600,1700 routers w/ 12.2(8)T IOS

Many Cisco 800 series routers running 12.2(8)T or later

The Easy VPN Remote device can be a Cisco router, PIX, or VPN
concentrator as well. "Easy VPN Remote" devices are often referred to
as "Easy VPN Clients", and that's how I'll refer to them for the rest of this
video. For your exam and when reading Cisco documentation, remember
that "Remote" and "Client" refer to the same device.

The basics of the VPN construction will look familiar at this point! First, the
Client will send ISAKMP proposals to the Server, and the Server responds
with the acceptance of a matching proposal. After the policy acceptance,
the ISAKMP SA is in place.

The next step is a little different from what we've seen in other VPNs. The
Server will now send a challenge to the Client, prompting the Client to
send a username and password to the Server.

We can use several methods to set up this authentication:

Local (using the username/password command)

RADIUS

TACACS

Xauth (Extended Authentication)

We'll take a closer look at RADIUS and TACACS in another section, but
keep in mind that we can use these security protocols in addition to local
authentication.

Once the Client has successfully authenticated, the process enters Mode
configuration. At this stage, the Client requests the necessary
configuration details from the Server.

This information can include:

IP address information (required)

internal DNS and WINS server addresses

split tunneling configuration information

Split tunneling allows the Client to have a secure tunnel to the Server and
simultaneous non-secure connections to other networks.

Once Mode configuration is completed, the Reverse Route Injection stage

begins. According to Cisco's website, "Reverse route injection (RRI) is the
ability for static routes to be automatically inserted into the routing process
for those networks and hosts protected by a remote tunnel endpoint".

After RRI, we're almost there! IPSec Quick Mode then negotiates the
IPSec SA, and we're all set.

Configuring Easy VPN Server In SDM

We'll start our Easy VPN server config by clicking the VPN button in the
Configure section of SDM.

You'll see a list of topics under "VPN", and we'll select Easy VPN Server.

The description screen shows the following. Note the prerequisite task.
There's a link to enable AAA on that screen, so I'll click that. Note that the
Enable Easy VPN button is grayed out since AAA is not yet enabled.

After clicking the enable AAA link, we're presented with this message:

We do want to enable AAA, so we'll click Yes and move on.

Once the AAA commands are delivered, we can enable Easy VPN
Server.

Welcome to the Easy VPN Server Wizard! Good exam review material on
this screen as well!

Here's the next window:

The interface facing the workstation is Fast 0/0, so I'll choose that in the
drop-down box. We'll use pre-shared keys as well, but you see that we
can use key, digital certificates, or both. After making those selections,
the next window asks us for the IKE proposal. We could create custom
policies by clicking Add, but here we'll use the default.

The Transform Set selection window is next, and we'll accept the default
there as well.
The next window prompts us for the group authorization method, and we'll
use local authentication only.

I like the summary description here. Actually, if you don't have a RADIUS
or TACACS server in your network, the local database is the only option
you have!

In the next window, we'll indicate local authentication for users.

In the next window, we'll click Add since a group has not yet been
created.

The Add Group Policy window opens to the following tab, and you can
see the information I entered for yourself. Note the pre-shared key
appears as a series of asterisks.
We'll enable Split Tunneling, which is disabled by default. When I clicked
that check box, the Enter the protected subnets selection window
enabled. I'll click Add and enter the 10.0.0.0 network with a wildcard
mask of 0.255.255.255.
The policy has been added.

At the bottom of this screen, note that you can specify an idle timer for the
tunnel.

Finally, we're presented with the Summary window.

After clicking Finish at the bottom of that screen, the commands are
delivered to the router, and the Easy VPN Server side of the configuration
is complete!

Configuring The Easy VPN Client

Now to the workstation! I'll launch the Cisco VPN Client and click New.

I'll enter the IP address of the Easy VPN Server, along with the group
name and password (which again appears only as a series of asterisks).

Group Authentication is selected by default. We're not going to configure

Mutual Group Authentication, but if we chose that option, we'd need to
import a valid root certificate.

Now the HQ connection appears under Connection Entry. I'll click

Connect, and we'll be prompted for a username / password combination
that I configured before the lab began.
The connection is then completed! Note that a lock now appears next to
the HQ connection, the message Connected to HQ appears in the bottom
left of the window, and the overall connection time appears in the bottom
right of the window.

You can also test the connection from the Server side. Go to the Edit
Easy VPN Server screen....

.. and at the very bottom of the screen, select Test Easy VPN Server.

Click Start in the Troubleshooting VPN screen, and you'll get check marks
when all is well. If something isn't well, you'll get some great information
on the issue here. This is the first place I check when a VPN
configuration isn't working correctly.
You'll also receive the following confirmation that all is well.

Let's look at an SDM screen we haven't visited yet - the Monitor screen.
Just click the Monitor button at the top of SDM, and you're there.

This screen has buttons on the left-hand side as well. Naturally, we'll
select VPN Status.
The IPSec Tunnels tab verifies that the tunnel is up.

The Easy VPN Server tab verifies it as well, along with the number of
encrypted and decrypted packets.

The IKE SA tab shows the SA is in QM_IDLE mode, which is just what we
want!
Hot Spots And Gotchas

VPNs provide the following:

Data Confidentiality

Data Integrity

Data Origin Authentication

Anti-Replay Attack Protection

Tunnel Mode:

Secures the entire IP packet

Has greater overhead than Transport Mode

The encrypted packet is placed into another IP packet, and that
outside IP address is used by the routing process

Transport Mode:

Secures some of the packet - the Transport layer and above.

The payload is secure, but the original IP address is used for the
routing process

Less overhead than Tunnel Mode

IKE handles the following:

negotiates IKE keys

negotiates IPSec Security Agreements (SAs)

negotiates authentication of IPSec peers

The SA lists the contents of the security policies on an IPSec endpoint.

For the SA state, we want to see QM_IDLE as we did in one of our labs.
Two common messages indicating a configuration problem:

MM_NO_STATE, Phase 1 attributes do not match

MM_KEY_EXCH, preshared key does not match

IKE Main Mode uses six packets, Aggressive Mode uses three.

In IKE Main Mode, the initiating party sends all of its policies to the remote
party. When the remote party receives those policies, it looks through its
own policies for a match to one of those it received.
The Diffie-Hellman protocol allows a set of peers to create and exchange
a shared secret key even though the connection between the two is
currently unsecured.

At the very beginning of the DH process, the two parties must agree on a
non-secret numeric value.

Certificate Authorities are trusted third-parties (such as VeriSign) that

allow non-partisan mutual authentication by the signing of public keys.

Split Tunneling allows some traffic to be protected via the tunnel and other
traffic to use an unencrypted connection. As we saw in SDM, Split
Tunneling is disabled by default.

To review, here's the process we used to create a site-to-site IPSec VPN:

Created the ISAKMP policy

Created the IPSec transform set

Defined interesting traffic with the crypto access-list

Created the crypto map - AND applied it to the proper interface

Made sure our ACLs allowed the appropriate port numbers

Encryption Algorithms And Other Stuff

Asymmetric Algorithms:

Used for key exchange and authentication.

Not suited for bulk encryption.

Includes Diffie-Hellman, DSS (Digital Signature Standard), Elliptic

Curve, and Cramer-Shoup

Use one key for encryption and another for decryption

Symmetric Algorithms:

Highly suited for bulk encryption.

Includes DES, TDES (Triple DES), AES, IDEA (International Data

Encryption Algorithm), RC4, and Blowfish.

SDM VPNs

Quick Mode vs. Step-by-Step Wizard: Quick Mode will use default IKE
policies and transform sets. You'll still be prompted for information
regarding the origination and termination points of the VPN, the IP
address of the remote peer, and other basic VPN information.

Copyright © 2008 The Bryant Advantage. All Rights Reserved.