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:
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.
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 51.
Encryption Services - data encryption - make sure nobody can eavesdrop on the data in transport. Using ESP (Encapsulating Security Payload) and IP protocol of 50.
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.
Now that basic theoretical concepts are introduced, this document will show how to map those into the actual crypto map based configuration.
IKE negotiation protection:
crypto isakmp policy 10
encr aes 256
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.
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
pre-shared-key address 0.0.0.0 0.0.0.0 key test
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
match identity address 0.0.0.0
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".
How to protect IKE negotiation
How to authenticate ourselves and peer.
The Diffie-Hellman keys (and other parameters, or VIDs) are exchanged automatically and rarely require much configuration.
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 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 is a feature binding all the information we discussed before in this section and previous together.
A few facts about crypto map.
One crypto map can be applied to an interface
Same crypto map can be applied to multiple interfaces
To accommodate multiple tunnels crypto map entries are used. One crypto map can have multiple entries, identified by a number.
Static crypto map can reference a dynamic crypto map.
The two crypto map types discussed and their usage:
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)
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
Current configuration : 80 bytes
ip address 10.0.0.1 255.255.255.0
crypto map MY_CRYPTO_MAP
When troubleshooting both show and debug commands should be used.
show crypto isakmp sa - shows status of IKE session on this device.
r2#sh crypto isa sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
172.16.1.1 10.0.0.1 QM_IDLE 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
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)