Tuesday, August 21, 2012

LAN-to-LAN IPsec Tunnel Between Two Routers

I followed the instructions on this link to build the lab in figure 1. I will include some additional commands not in this article and try to clarify some things.

Figure 1


Tunnel currently down: When the tunnel is up, you should see details within the inbound and outbound ESP sections or AH depending on which protocol your using. You also would see the pkts encaps: and pkts decaps incrementing as you are sending data. local  ident and remote ident confirm which networks are part of your encryption domain. This means which networks would bring up the tunnel. local crypto endpt is the local peer address of your device and the remote crypto endpt is the other side vpn peer.

Encapsulated Security Payload ESP), protects the IP packet data from third party interference, by encrypting the contents using symmetric cryptography algorithms (like Blowfish, 3DES).

Authentication Header (AH), protects the IP packet header from third party interference and spoofing, by computing a cryptographic checksum and hashing the IP packet header fields with a secure hashing function. This is then followed by an additional header that contains the hash, to allow the information in the packet to be authenticated.


R1#show crypto ipsec sa

interface: FastEthernet0/0
    Crypto map tag: mymap, local addr 192.168.1.2

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (1.1.1.1/255.255.255.255/0/0)
   remote ident (addr/mask/prot/port): (3.3.3.3/255.255.255.255/0/0)
   current_peer 192.168.2.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #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.: 192.168.1.2, remote crypto endpt.: 192.168.2.2
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0x0(0)

     inbound esp sas:

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:

     outbound ah sas:

     outbound pcp sas:

Bring up the tunnel:

Lets bring up the tunnel and compare the results. Currently 1.1.1.1 and 3.3.3.3 are part of my encryption domain meaning that only traffic for these networks will traverse the tunnel.

R1#ping 3.3.3.3 source 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 40/53/72 ms

We drop one packet as the tunnel is coming up. Now you can see the ESP sections have information and the ENCAPS/DECAPS section have incremented. If you were to only see one of the sections #pkts encaps or #pkts decaps increment, then you have a routing issue.

R1#show crypto ipsec sa

interface: FastEthernet0/0
    Crypto map tag: mymap, local addr 192.168.1.2

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (1.1.1.1/255.255.255.255/0/0)
   remote ident (addr/mask/prot/port): (3.3.3.3/255.255.255.255/0/0)
   current_peer 192.168.2.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 1, #recv errors 0

     local crypto endpt.: 192.168.1.2, remote crypto endpt.: 192.168.2.2
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0x87F468E7(2280941799)

     inbound esp sas:
      spi: 0x6B548BDA(1800702938)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        conn id: 2001, flow_id: SW:1, crypto map: mymap
        sa timing: remaining key lifetime (k/sec): (4578317/3524)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x87F468E7(2280941799)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        conn id: 2002, flow_id: SW:2, crypto map: mymap
        sa timing: remaining key lifetime (k/sec): (4578317/3522)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:
R1#

Clearing Crypto Sessions:
clear crypto session remote 192.168.2.2

Debug from R3(debug crypto isakmp & debug crypto ipsec)

R3#
*Mar  1 01:08:42.863: ISAKMP (0:134217729): received packet from 192.168.1.2 dport 500 sport 500 Global (R) QM_IDLE
*Mar  1 01:08:42.867: ISAKMP: set new node 131317528 to QM_IDLE
*Mar  1 01:08:42.875: ISAKMP:(0:1:SW:1): processing HASH payload. message ID = 131317528
*Mar  1 01:08:42.879: ISAKMP:(0:1:SW:1): processing DELETE payload. message ID = 131317528
*Mar  1 01:08:42.879: ISAKMP:(0:1:SW:1):peer does not do paranoid keepalives.

*Mar  1 01:08:42.883: ISAKMP:(0:1:SW:1):deleting node 131317528 error FALSE reason "Informational (in) state 1"
*Mar  1 01:08:42.891: IPSEC(key_engine): got a queue event with 1 kei messages
*Mar  1 01:08:42.895: IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP
*Mar  1 01:08:42.895: IPSEC(key_engine_delete_sas): delete SA with spi 0x7CF89E55 proto 50 for 192.168.1.2
*Mar  1 01:08:42.903: IPSEC(delete_sa): deleting SA,

Further Reading:

VPNs and VPN Technologies

IPsec Troubleshooting: Understanding and Using debug Commands

New IPsec Troubleshooting Features





No comments:

Post a Comment