- What is IPsec
- IKE negotiation at a glance
- Tunnel mode and transport mode.
- Configuration
- IKE
- IPsec
- Troubleshooting
- Show commands
- Debugging
- References
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.
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:
- 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.
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.
- 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
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 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
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
