Crypto map based IPsec VPN fundamentals negotiation and configuration

this document will outline basic negotiation and configuration for crypto-map-based IPsec VPN configuration.

This document is intended as an introduction to certain aspects of IKE and IPsec, it WILL contain certain
simplifications and colloquialisms.

What is IPsec
IPsec is a standard based security architecture for IP hence IP-sec.
IKE (Internet Key Exchange) is one of the ways to negotiate IPsec Security Associations (SAs), in particular
case ISAKMP (implementation of IKE) is what Cisco uses.
Currently two versions of IKE exist:
1. IKE version 1 (IKEv1) - the more common and older, widely deployed. This is what typically is used to
around the world when IPsec is implemented.
2. IKE version 2 (IKEv2) - as the name suggests it a newer, more robust protocol. It's less widely deployed,
however offers more and is quickly gaining traction.
This document focuses mostly on IKEv1 and crypto map configuration, however most aspects are true for other
types of frameworks.

IKE negotiation at a glance

To establish IKE Security Association (IKE SA or Phase 1) in a secure way peers will need to exchange certain
information, those include:

How to protect negotiation - hashing algorithm to use, encryption algorithm to use, Diffie-Hellman
group (key length), desired IKE SA lifetime.

Diffie-Hellman exchange will need to be performed - establish a shared secret over insecure medium.

Authentication - Peers exchange identities and authentication material (pre shared key or certificates, in
a typical environment).

It is important to note that pre shared key is not actually exchanged, it is intended factored into the key protecting identity. Thus if the
peer doesn't have the correct pre-shared key it will not be able to authenticate and finish phase 1 negotiation.
IKE SA can be established via aggressive mode or main mode negotiation, this document covers Main Mode exchange which is the
one typically deployed.
Aggressive mode is the less secure of modes and is typically used in EZVPN with pre-shared key, where additional layer of security is
provided by performing user authentication.

Once IKE SA is established, the peers are ready to establish information about what traffic to protect and how to protect it. This will
form an IPsec Security Association (SA) or phase 2, in an exchange called Quick Mode.
Once quick mode is performed and IPsec SA exists and traffic is able to flow in a secured way.
A visual aide to remember this by:

At this stage it is important to remember, during normal operation, one IKE SA exists between peers.
During rekey or re-negotiation multiple IKE SA can exist.
However between two peers multiple IPsec SAs can exist.

This concept is visualized here.

As the above diagram shows there are two IPsec SAs, identified by Security Parameter Index (SPI), present on a
device for each direction, one for inbound traffic one for outbound traffic.
It is also crucial to remember that inbound IPsec SA on left hand side device, if the outbound IPsec SA on right
hand side device, and vice versa.
At this stage it is also worth to mention that "local" and "remote" networks are reversed on each end. This
concept will come up again when performing configuration of "interesting traffic" later on.

Tunnel mode and transport mode.

When IPsec protects traffic, it has a couple of services and modes to choose from.

Authentication Service - protect and verify integrity of data - make sure data is not changed during transport. Using AH
(Authentication Header) and IP protocol 50.

Encryption Services - data encryption - make sure nobody can eavesdrop on the data in transport. Using ESP (Encapsulating
Security Payload) and IP protocol of 51.

Second service is much more widely deployed.

While it is possible to mix the two services, it is an very rare scenario, with limitated-or-no support on certain
platforms.
More is another concept which come up quite often with IPsec. Two modes exist:

Transport mode - preserving original IP header. Typically used in combination with GRE or other encapsulating protocols.

Tunnel mode - encapsulating entire IP datagram within a new header, essentially tunneling the packet.

A mode which is the most common for most crypto map deployments is Encryption Services and tunnel mode. However let's have a
look at an overview how each of those will work.

First let's have a look at AH and ESP and how they tread original IP datagram, in this case some TCP data will
be sent over.

And now about how those IP protocols fit in the two modes.

As pointed out the last mode is what is typically used with crypto map based IPsec VPNs.
In this mode, RFC1918 addresses (or in fact any other IP address) can be sent over the Internet encapsulated in
new IP header which will use addresses routable on the Internet.

Configuration
Now that basic theoretical concepts are introduced, this document will show how to map those into the actual
crypto map based configuration.

IKE

IKE negotiation protection:

crypto isakmp policy 10

encr aes 256
authentication pre-share
group 2
lifetime 28800
ISAKMP policy defines, what will be the means to authenticate, and how to protect negotiation , as well as how long and IKE SA will
be alive before re-negotiation (by default it's one day).
Those parametrs need to agree on both ends of the tunnel.

IKE authentication

In previous section the means to authenticate was specified, here the configuration creates notion of the actual
pre-shared key to be used to authenticate the peer. In this case it has value of "test".
crypto keyring MY_KEYRING
local-address Loopback2
pre-shared-key address 0.0.0.0 0.0.0.0 key test

ISAKMP profile

This profile binds together features used by IKE and IPSec, it will be later on referenced in IPsec section, in
crypto map configuration.
crypto isakmp profile MY_PROFILE
[vrf MY_IVRF]
keyring MY_KEYRING
match identity address 0.0.0.0
self-identity address

local-address Loopback2

In this case the profile sprecifies that any (wildcard 0.0.0.0) identity of type "address" should fall under this
profile.
It is important to mention that we're discussing about peer IDENTITY, in this case peer of type address with
value of "any" is matched.
Self-identity statement tells this router to use it's own identity of type address when performing authentication.
Optionally, in case of VRF-ware IPsec, this is where IVRF (in this case MY_IVRF) is referenced.
It is also important to note that our identity (self-identity) is what the remote peer will have to match in their
ISAKMP profile.
In a classic exampe if we send our identity as address, the remote peer will have to match identity of type
"address".
We've covered:
1. How to protect IKE negotiation
2. How to authenticate ourselves and peer.
The Diffie-Hellman keys (and other parameters, or VIDs) are exchanged automatically and rarely require much
configuration.

IPsec
As in case of IKE certain parameters need to be exchanged for IPsec SAs to be established. Also as in case of
ISAKMP profile we will introduce a central component of crypto map.

IPsec transform set.

As discussed previously a device needs to know how to protect traffic, this is where transform set comes into
play. It defines what hashing and encryption algorithm is to be used to protect traffic.
crypto ipsec transform-set MY_SET esp-3des esp-sha-hmac

In this case 3DES and SHA were chosen.

For guidance and recommendations on current best practices about chosing the right algorithms refer to:
http://www.cisco.com/web/about/security/intelligence/nextgen_crypto.html

Traffic selection

Crypto maps use traffic selection mechanism in form of access-list.

The access-list is always defined from local perspective, i.e. Cisco devices will use an access-list which will
select (using permit statement) traffic from X to Y and on it's peer the access-list will be mirrored selecting
traffic from Y to X.
It is important to note that this is one of the things checked/enforced during negotiation.
access-list 100 permit ip 172.16.1.0 0.0.0.255 any

In this case router will be interested to encrypt all traffic from 172.16.1.0/24 subnet. The remote end will used
access-list specifying the reverse "any to 172.16.1.0/24" (or use dynamic crypto map!).

Crypto map

Crypto map is a feature binding all the information we discussed before in this section and previous together.
A few facts about crypto map.
1. One crypto map can be applied to an interface
2. Same crypto map can be applied to multiple interfaces
3. To accommodate multiple tunnels crypto map entries are used. One crypto map can have
multiple entries, identified by a number.
4. Static crypto map can reference a dynamic crypto map.
The two crypto map types discussed and their usage:

o Static crypto map - identifies peer and traffic to be encrypted explicitly. Typically used to
accommodate a few tunnels with different profiles and characteristics (different partners, sites,
location)
o Dynamic crypto map - is one of the ways to accomodate peers sharing same characteristics (for
example multiple branches offices sharing same configuration) or peers having dynamic IP
addressing (DHCP, etc.)
crypto map MY_CRYPTO_MAP 100 ipsec-isakmp
set peer 10.0.0.1
set transform-set MY_SET
set isakmp-profile MY_PROFILE
match address 100

Looking at this example,

Crypto map names MY_CRYPTO_MAP has entry 100 using ISAKMP to negotiate IPsec.
This crypto map entry should match traffic specified by access-list 100 and perform parameters defined in
ISAKMP profile called MY_PROFILE.

The way to protect traffic is defined in transform set MY_SET.

When performing IKE negotiation, packets should be sent to peer 10.0.0.1.
A crypto map (by name) is then applied to an interface.
r2#sh run int e1/0
Building configuration...
Current configuration : 80 bytes
!
interface Ethernet1/0
ip address 10.0.0.1 255.255.255.0
crypto map MY_CRYPTO_MAP
end

Troubleshooting
When troubleshooting both show and debug commands should be used.

Show commands

show crypto isakmp sa - shows status of IKE session on this device.

r2#sh crypto isa sa

IPv4 Crypto ISAKMP SA
dst

src

state

172.16.1.1

10.0.0.1

QM_IDLE

conn-id status
1004 ACTIVE

In this case there's only one session and it's in state "ACTIVE".

show crypto ipsec sa - shows status of IPsec SAs. Crucial information to look for, what traffic is being protected, from what
IVRF (protected VRF) and if IPsec SAs (or SPIs) are in active state.

r2#sh crypto ipsec sa

interface: Ethernet1/0
Crypto map tag: MAP, local addr 10.0.0.1
protected vrf: (none)
local

ident (addr/mask/prot/port): (192.168.0.0/255.255.255.0/256/0)

remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/256/0)

current_peer 172.16.1.1 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
#pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 10.0.0.2, remote crypto endpt.: 172.16.1.1
path mtu 1500, ip mtu 1500, ip mtu idb Ethernet1/0
current outbound spi: 0xDFDE17CA(3755874250)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0x205F6BE9(543124457)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 13, flow_id: SW:13, sibling_flags 80000040, crypto map: MY_CRYPTO_MAP
sa timing: remaining key lifetime (k/sec): (4335214/3551)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xDFDE17CA(3755874250)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }

conn id: 14, flow_id: SW:14, sibling_flags 80000040, crypto map: MY_CRYPTO_MAP
sa timing: remaining key lifetime (k/sec): (4335214/3551)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound ah sas:
outbound pcp sas:

In the above case traffic between local 192.168.0.0/24 (in global VRF) to remote 192.168.1.0/24 is protected
and remote peer is 172.16.1.1.
There are two IPsec SAs active (one in each direction) and we processed total of 5 packets in each direction.

show crypto session - shows a at a glance view of different tunnels on this device.

r2#sh crypto session

Crypto session current status
Interface: Ethernet1/0
Session status: UP-ACTIVE
Peer: 172.16.1.1 port 500
IKEv1 SA: local 10.0.0.1/500 remote 172.16.1.1/500 Active
IPSEC FLOW: permit ip 192.168.0.0/255.255.255.0 192.168.1.0/255.255.255.0
Active SAs: 2, origin: crypto map

Show crypto session offers at-a-glance view of information gathered already with previous commands.
Peer IP address, what is the protected traffic and how many active SAs are present.
This situation is from a working tunnel.

Debugging
To narrow down debugging to one peer conditional debugging should be used.
On IOS this is done by performing:
debug crypto condition peer ipv4 ....

Two major component can be debugged

debug crypto isakmp - information specific to ISAKMP exchange. This will contain information about main mode and quick
mode negotiation.

debug crypto ipsec - some phase 2 specific information can be found here.

References

VRF-aware IPsec cheatsheet

https://supportforums.cisco.com/docs/DOC-13524

Understanding main mode debugs:

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a0080bce100.shtml
https://supportforums.cisco.com/docs/DOC-18522