Monday 1 December 2014

IPsec

Configuring IPsec


There are four key outcomes from using IPsec which will secure our data:
•    Confidentiality
•    Data integrity
•    Authentication
•    Antireplay

Let’s run through the process a device will go through to set up an IPsec connection to a peer:

1.    IKE Phase 1


The first step involved in a tunnel will be to negotiate the Internet Key Exchange phase 1 tunnel.  There are two modes for this, Main Mode which uses a six packet exchange and Aggressive mode which uses a three packet exchange.  Main mode is considered more secure and is the default mode.  This tunnel is only used for management of the tunnel and no user data is forwarded over it.  There are five items which must be in agreement between the two endpoints before a tunnel can be set up.
•    Hash algorithm
•    Encryption algorithm
•    Diffie-Hellman group
•    Authentication method
•    Lifetime
The lifetime is the only one which doesn’t have to match exactly, as the lower of the two (if they differ) will be used for the tunnel.

2.    Diffie-Hellman key exchange


Once the phase 1 policy is agreed, using the group that has been agreed to in phase 1, a symmetrical key is generated which both ends will use to encrypt the data.

3.    Authenticate the peer


This is the last piece of phase 1 and whichever method agreed to in the phase 1 policy will be used, the options are RSA signatures or pre-shared keys.  Once this is in place we now have a phase 1 tunnel.

Now that we have a management tunnel in place, the two devices must now create a second tunnel that will be used for the actual data.  The devices can use this phase 1 tunnel to negotiate and create the phase 2 tunnel.  This tunnel will use the hashing and encryption algorithms specified in the device configuration, which means that when we are configuring a VPN, we specify the hashing and encryption algorithms for phase 1 and phase 2.

Once we the phase 2 tunnel built then the devices will encrypt the traffic.  Any packet capture between the devices will just look like an encrypted stream of traffic between the two peers.

Let’s build our own VPN connection now to put in place what we have learnt.

I’m using a very simplified topology of two IOS routers directly connected to each other, that direct connection is simulating the Internet.  On each router I have a loopback interface which is simulating an internal network behind the router, and we will configure our VPN to encrypt all traffic between the two networks.




Remembering what we need to configure to get the connection working, this is what we will use for Phase 1:
•    Hash – SHA.  This is generally considered more secure than MD5
•    Authentication – Pre-shared key
•    Group – Diffie-Hellman group, we will use group 5
•    Lifetime – we will use 3600
•    Encryption – AES 256
For phase 2 we will use SHA and AES256 again.

Let’s put that in place on R1:

R1(config)#crypto isakmp policy 5
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#encryption aes 256
R1(config-isakmp)#hash sha
R1(config-isakmp)#group 5
R1(config-isakmp)#lifetime 3600
R1(config-isakmp)#exit
R1(config)#crypto isakmp key secretkey address 10.0.0.2
R1(config)#access-list 100 permit ip 172.16.31.0 0.0.0.255 192.168.0.0 0.0.0.255
R1(config)#crypto ipsec transform-set TESTSET esp-sha-hmac esp-aes 256
R1(cfg-crypto-trans)#mode tunnel
R1(config)#crypto map TESTCMAP 1 ipsec-isakmp
R1(config-crypto-map)#match address 100
R1(config-crypto-map)#set transform-set TESTSET
R1(config-crypto-map)#set peer 10.0.0.2
R1(config-crypto-map)#exit
R1(config)#int fa0/0
R1(config-if)#crypto map TESTCMAP



This looks like quite a bit of config, but let’s quickly run through it.  First we establish an ISAKMP polic (phase 1).  We can have multiple policies on each device, and as long as one of them matches then a tunnel can be formed.  We apply our chosen configuration within the phase 1 policy.  Second we define a pre-shared key to use with a remote router and assign it the address of the other end.  Now we create an access-list which will contain all of the traffic which we will want to be encrypted and sent across the tunnel.  Phase 2 is created next and we assign it the chosen configuration, similar to phase 1 except it’s all done in one line.  We set it to tunnel mode which means that the router will take any traffic matching the access-list and encrypt them inside an IPsec packet.  Transport mode is the other option but that is only for traffic between the devices.  Create a crypto map and then apply it to an interface, which causes the router to automatically capure traffic matching the ACL specified in the crypto map and apply the chosen configuration to it, in this cause use the VPN tunnel.
Now let’s apply the same but inverse configuration to R2 and bring up a tunnel.

R1#show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
       K - Keepalives, N - NAT-traversal
       T - cTCP encapsulation, X - IKE Extended Authentication
       psk - Preshared key, rsig - RSA signature
       renc - RSA encryption
IPv4 Crypto ISAKMP SA

C-id  Local           Remote          I-VRF    Status Encr Hash Auth DH Lifetime Cap.

1001  10.0.0.1        10.0.0.2                 ACTIVE aes  sha  psk  5  00:47:12
       Engine-id:Conn-id =  SW:1

IPv6 Crypto ISAKMP SA


R1#show crypto ipsec sa

interface: FastEthernet0/0
    Crypto map tag: TESTCMAP, local addr 10.0.0.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (172.16.31.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.0.0/255.255.255.0/0/0)
   current_peer 10.0.0.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 10, #recv errors 0

     local crypto endpt.: 10.0.0.1, remote crypto endpt.: 10.0.0.2
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0xA6EC9D4E(2800524622)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0xC7236551(3340985681)
        transform: esp-256-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 1, flow_id: SW:1, sibling_flags 80000046, crypto map: TESTCMAP
        sa timing: remaining key lifetime (k/sec): (4571197/3545)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xA6EC9D4E(2800524622)
        transform: esp-256-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2, flow_id: SW:2, sibling_flags 80000046, crypto map: TESTCMAP
        sa timing: remaining key lifetime (k/sec): (4571197/3545)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:


R1#show crypto engine connections active
Crypto Engine Connections

   ID  Type    Algorithm           Encrypt  Decrypt LastSeqN IP-Address
    1  IPsec   AES256+SHA                0        4        4 10.0.0.1
    2  IPsec   AES256+SHA                4        0        0 10.0.0.1
 1001  IKE     SHA+AES256                0        0        0 10.0.0.1

 
Note you'll see a few send errors in the phase 2, this is because I initally forgot to attach the transform set on R2 to the crypto map and the VPN failed to come up.

No comments:

Post a Comment