Categories

CUC (6) CUCM (26) Jabber (6) Python (2) Routing (3) Solarwinds Orion NPM (4) switching (1) Video (6) voice (2)

Monday, 19 March 2018

IPSEC Site to site VPN 101


Little post on IPSEC, also a good recap for myself. I will outline the components used in IPSEC when setting up a site  to site VPN for instance. I dont really want to drill down too much into the details of each protocol. This post is more around the components needed and steps/tips to trouble shoot.

IPSEC VPN is described in RFC 4301.

IPSEC is not a protocol, its is more similar to an architecture, that contains a number of protocols (mainly isakmp, AH and ESP)

IPSEC comprises of the following main elements:
  • IKE/IKEv2: which is used to negotiate tunnel parameters. These parameters are: (H.A.G.L.E)
    • Hashing for data integrity (md5/sha)
    • Authentication (certs or preshared key (PSK))
    • Group (Diffie-Hellman group)
    • Lifetime (how long will the tunnel be up for (seconds)
    • Encryption for data confidentiality (AES, 3DES, AES-256)
  • AH which is more or less become obsolete because of it inability to deal with NAT
  • ESP Encapsulation for encryption and authentication.

In order to have a fully functional site to site VPN, there are 2 types of SA's (Security Association) that need to be established:

  1. ISAKMP SA's (Phase 1), bidirectional SA, used as a management channel, to exchange keys between the peers for instance (similar to the B-channel on a BRI)
  2. IPSEC SA's (Phase 2), these are unidirectional, so you will need 2 IPSEC SA's. This happens once Phase 1 is successful. These IPSEC SA's are used to define how the end user data is protected, using transform sets
So for a functional IPSEC tunnel, a total of 3 SA's are required. These two types of SA's are also referred to as Phase 1 and Phase 2. Here is a visualization of this:






ESP (encapsulating Security Payload) and SPI

Once the SA's have been established, ESP does the hard work of protecting the traffic across the tunnel. ESP uses IP as its Layer 3 protocol and puts itself at layer 4. So if you were to Wireshark capture Tunneled traffic, you would not see a TCP port, but an ESP header containing an SPI (security Perimeter Index), a sequence number, followed by an encrypted payload.  

SPI are a 32bit random number that is associated with an IPSEC sa. As soon as a VPN endpoint receives an ESP encapsulated packet with a certain SPI, it knows exactly what transform set to apply to decrypt and integrity check the payload. If your firewall/router has multiple site to site IPSEC VPNs, you will have a multitude of SPI.

If you issue a sh crypto ipsec sa on a firewall or router, this will show you the associated SPI's. for example:



fw01/pri/act# sh cry ipsec sa
    <output omitted>
    inbound esp sas:
      spi: 0xE11468F9 (3776211193)
         SA State: active
         transform: esp-3des esp-md5-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
         slot: 0, conn_id: 223428608, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (4373768/1686)
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap:
          0xFFFFFFFF 0xFFFFFFFF
    outbound esp sas:
      spi: 0x859B5920 (2241550624)
         SA State: active
         transform: esp-3des esp-md5-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
         slot: 0, conn_id: 223428608, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (4373506/1686)
         IV size: 8 bytes
As you can see there are 2 IPSEC SA's one for inbound, one for outbound, each with their own SPI, on the remote end these values will be opposite of course.

You can also clearly see the applied transform sets of each SA, using ESP with Triple DES encryption and HMAC-MD5 for message authentication and integrity.

Remember every SA can have a different transform set, although this is not recommended.


Diagnostics on Cisco devices

Of course, when will you be most likely to set up a site to site VPN? Correct, when talking into some 3rd party systems, or when some 3rd party needs to talk into some of your systems.  What sort of Forewall/VPN concentrator does this party have? Really could be anything, Juniper, Palo alto, Sonic. I have had my fair share of pain getting VPN's set up inter vendor. And before you blame the other guy for not sending you the right transform set, make damn sure that you are right. So I think a few hints and tips could make a lot of difference.

There are really two commands available that should be your best friend when diagnosis IPSEC VPN issues:

  • sh crypto isakmp sa
  • sh crypto ipsec sa


fw01/pri/act# show crypto isakmp sa  detail
IKEv1 SAs:
   Active SA: 5
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 5
1   IKE Peer: 214.20.7.16
    Type    : L2L             Role    : responder
    Rekey   : no              State   : MM_ACTIVE
    Encrypt : 3des            Hash    : MD5
    Auth    : preshared       Lifetime: 28800
    Lifetime Remaining: 16894

As you can see above, there is your 'HAGLE' (hash, authentication,Group (well sort of), Lifetime, Encryption). What is important above is that the ISAKMP SA is established  (MM_ACTIVE). If you do not see your ISAKMP SA established, go no further, trouble shoot Phase1 first. Other states are:

MM_NO_STATE (typically cause by connectivity issue with the peer), MM_KEY_EXCH (could mean PSK mismatch), MM_SA_SETUP (peers agree on isakmp sa and will continue the process of negotiation).


If your Phase1 SA is not established, you will need to run debug commands to see what transform set are being attempted and what the remote end is sending you. for this you can use:

  • debug crypto isakmp
  • debug crypto isakmp error
  • debug crypto isakmp ha
Before you do this, you might want to consider, using conditional debugging, i.e. only capture debug information related to the failing VPN tunnel/peer. This because you might be running a large number of tunnels which would result in large amount of debug information.  To enable conditional crypto debugging:

debug crypto condition <cond-type> <cond-value>

as a condition value, you could choose the peer IP address for instance. To reset the condition use: debug crypto condition reset

Now the next test phase 2, if phase 1 is established, use the show cypto ipsec sa command. You would get something similar to the output below:

fw01/pri/act# sh crypto ipsec sa peer 214.20.187.17
peer address: 214.20.187.17
    Crypto map tag: outside_map, seq num: 2, local addr: 229.198.80.10
      access-list Internet_cryptomap_1 extended permit ip 192.168.71.0                   255.255.255.0 192.168.171.0 255.255.255.0
      local ident (addr/mask/prot/port): (192.168.71.0255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (192.168.171.0/255.255.255.0/0/0)
      current_peer: 214.20.187.17
      #pkts encaps: 359869, #pkts encrypt: 358126, #pkts digest: 358126
      #pkts decaps: 280949, #pkts decrypt: 279563, #pkts verify: 279563
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 359869, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #TFC rcvd: 0, #TFC sent: 0
      #Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
      #send errors: 0, #recv errors: 0
     local crypto endpt.: 229.198.80.10/0, remote crypto endpt.: 214.20.187.17/0
      path mtu 1500, ipsec overhead 58(36), media mtu 1500
      PMTU time remaining (sec): 0, DF policy: copy-df
      ICMP error validation: disabled, TFC packets: disabled
      current outbound spi: 67EA5A7C
      current inbound spi : 08278FA3
    inbound esp sas:
      spi: 0x08278FA3 (136810403)
         SA State: active
         transform: esp-3des esp-md5-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
         slot: 0, conn_id: 223428608, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (4373709/1407)
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap:
          0xFFFFFFFF 0xFFFFFFFF
    outbound esp sas:
      spi: 0x67EA5A7C (1743411836)
         SA State: active
         transform: esp-3des esp-md5-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
         slot: 0, conn_id: 223428608, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (4373391/1407)
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001

The SA will show you H.A.G.L.E for both inbound and outbound SA's. It will also show you what traffic is protected by the VPN Tunnel. 

Good luck and namaste!!







No comments:

Post a Comment