Friday, October 11, 2013

IPsec notes

I love me some packetlife.net..

To sum it up in my own words..

Step 1 is the IKE (Internet Key Exchange) configuration.


IKE relies on ISAKMP (Internet Security and Key Management Protocol) in order to create a secure channel for which IPSEC to negotiate.  An IKE policy determines the attributes that will be used in the ISAKMP session.

To create a policy, the syntax is as follows:

R1(config)# crypto isakmp policy 10
R1(config-isakmp)# authentication pre-share
R1(config-isakmp)# ^Z
R1# sh crypto isakmp policy

Global IKE policy
Protection suite of priority 10
    encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
    hash algorithm:         Secure Hash Standard
    authentication method:  Pre-Shared Key
    Diffie-Hellman group:   #1 (768 bit)
    lifetime:               86400 seconds, no volume limit
...

Note:

  • Encryption algorithm is used to scramble/unscramble data.
  • Hash algorithm is used for data integrity.  Once data is transferred, the hash is compared to verify data consistency. 
It is possible to create up to a maximum of 20 policies.  The lower the priority number, the higher priority it has.  When initiating a connection with another device, the two will compare policies (higher priority/lower numbers) first until they find one that matches.

In this example we are using a pre-shared key.  This means that the vendor/partner on the distant end must have the same key, hash algorithm, encryption algorithm, and Diffie-Hellman group to create a secure channel.  The lifetime does not have to match.  In the event of a lifetime difference, it will defer to that which has the shortest lifetime.  The default is 86400 seconds..or 24 hours.  Shared-keys for authentication are not best practice as it is considered to be the least secure method.  The alternative is to RSA (Rivest-Shamir-Adleman) for authentication.  Here is a link to this implementation! 

Moving on!

Now that we have identified the authentication method, we need to actually identify this key.

R1(config)# crypto isakmp key 0 FooB4r address 172.16.0.6

With this example, we are using option 0 versus option 1.  Since we indicated 0, if you perform a show crypto isakmp key it would show you the following: "FooB4r"

Step 2 is the IPsec configuration

While the IKE policy provides a default for all attributes, we now must explicitly state the encryption and hash algorithm we want to use with transform-set.  The transform set defines the parameters of the IPsec security associations which will carry the actual data.  If you are interested in seeing the existing transform-sets, perform a show crypto ipsec transform-set.  This will show you if it is configured for tunnel or transport mode, as well as the encryption/hash algorithm.  We will indicate this later on, but the transform-set tag is what you indicate in the individual crypto-map to indicate the preferred algorithms.  

Here is an example of the configuration and resulting show command:


R1(config)# crypto ipsec transform-set MyTransformSet esp-3des esp-sha-hmac
R1(cfg-crypto-trans)# ^Z
R1# show crypto ipsec transform-set
Transform set MyTransformSet: { esp-3des esp-sha-hmac  }
   will negotiate = { Tunnel,  },

As you can see in this example, it is using 3DES for encryption and HMAC_SHA for authentication in tunnel mode.  

Now to reference this transform-set...

crypto map <tag> <sequence number> ipsec-isakmp
 description <I like to use a point of contact for the distant end>
 set peer <IP address of the distant end>
 set transform-set <Previously configured transform-set>
 match address <access-list to identify interesting traffic>

Some basic troubleshooting commands to verify status:

show crypto isakmp sa
This command shows the Internet Security Association Management Protocol (ISAKMP) security associations (SAs) built between peers.

show crypto ipsec sa
This command shows IPsec SAs built between peers.  This command gives quite a bit of information.  This will show how many packets have been encapsulated (egress), de-encapsulated (ingress), as well as the encryption and authentication algorithms of the different peers.  

show crypto engine connections active
This command shows each phase 2 SA built and the amount of traffic sent. Since phase 2 (security associations) SAs are unidirectional, each SA shows traffic in only one direction (encryptions are outbound, decryptions are inbound).

debug crypto ipsec
This debug command will show traffic from the source and destination.  Two "SA created" messages will appear with one in each direction.

Note:
We had an issue today configuring this, so I figured I'd share.  I configured IPsec between a Cisco 7206VXR and a Cisco ASA 5520.  The reason the tunnel did not come up was due to mismatched crypto map ACLs.  The IPs need to match!

Also, for some reason the access rule on the outside interface was blocking ISAKMP.  We were allowing UDP port 4500 and 500 and the ESP service.  Not until we allowed IP did the tunnel come up.  When monitoring, we were seeing hits that it was blocking it because of 'Spoofing.'  This is on the vendor site restricting OUR access to their network...so...I honestly don't care and we left the IP service on. :)

No comments:

Post a Comment