evilrouters.net

As I mentioned at the end of the Basic Frame Relay Lab for Dynamips, the next lab will cover how to set up an IPSec site-to-site VPN between R2 and R3 to encrypt our data in transit.

I adhere to the KISS principle so to avoid adding more virtual routers to the topology to act as hosts, we’re going to use the loopback 0 interfaces on R2 and R3 that we configured last time as our end IP addresses for testing. If you missed the last lab, go ahead and get it set up and verify full connectivity between the routers and then continue on.

Okay, so we have R1, R2, and R3 up and running, EIGRP adjacencies established, and full routing between all interfaces. Let’s jump right in to setting up our IPSec VPN!

Our first step is to configure the ISAKMP policies on each router. In this lab, we’ll use a pre-shared key for authentication, 128-bit AES for our encryption algorithm, Diffie-Helman group 2 (1024-bit modulus) and SHA hashing:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#crypto isakmp policy 10
R2(config-isakmp)#authentication pre-share
R2(config-isakmp)#encryption aes 128
R2(config-isakmp)#group 2
R2(config-isakmp)#hash sha

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#crypto isakmp policy 10
R3(config-isakmp)#authentication pre-share
R3(config-isakmp)#encryption aes 128
R3(config-isakmp)#group 2
R3(config-isakmp)#hash sha

Our next step is to configure the pre-shared key that we wish to use. Note that we must use the same key (”SECRET_KEY”) on both ends of the VPN:

R2(config-isakmp)#crypto isakmp key 0 SECRET_KEY address 172.16.123.3 no-xauth

R3(config-isakmp)#crypto isakmp key 0 SECRET_KEY address 172.16.123.2 no-xauth

With our ISAKMP policy and pre-shared key configured, we can now define our transform set:

R2(config)#crypto ipsec transform-set R2_R3_TRANSFORM esp-aes 128 esp-sha-hmac

R3(config)#crypto ipsec transform-set R3_R2_TRANSFORM esp-aes 128 esp-sha-hmac

Our next step will be to tell the routers what traffic should be encrypted. We do this with an access list. For this lab, we’ll tell R2 that any traffic from 172.16.2.2 destined for 172.16.3.3 should be encrypted. On R3, we’ll do just the opposite: any traffic from 172.16.3.3 destined for 172.16.2.2 should be encrypted. Note that the access lists on each end must be a “mirror image” of each other for the VPN to properly function:

R2(cfg-crypto-trans)#ip access-list extended ENCRYPTED_TRAFFIC
R2(config-ext-nacl)#permit ip host 172.16.2.2 host 172.16.3.3

R3(cfg-crypto-trans)#ip access-list extended ENCRYPTED_TRAFFIC
R3(config-ext-nacl)#permit ip host 172.16.3.3 host 172.16.2.2

Awesome, almost done! We have two steps left. We still need to configure our crypto maps and then apply them to the appropriate interfaces. Once that’s done, we should have connectivity. Let’s set up the crypto maps:

R2(config-ext-nacl)#crypto map R2_R3_MAP 10 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
        and a valid access list have been configured.
R2(config-crypto-map)#set peer 172.16.123.3
R2(config-crypto-map)#match address ENCRYPTED_TRAFFIC
R2(config-crypto-map)#set transform-set R2_R3_TRANSFORM

R3(config-ext-nacl)#crypto map R3_R2_MAP 10 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
        and a valid access list have been configured.
R3(config-crypto-map)#set peer 172.16.123.2
R3(config-crypto-map)#match address ENCRYPTED_TRAFFIC
R3(config-crypto-map)#set transform-set R3_R2_TRANSFORM

Now we just apply the crypto maps to the appropriate interfaces (serial 0/0, in both cases here) and we should be good to go:

R2(config-crypto-map)#interface serial 0/0
R2(config-if)#crypto map R2_R3_MAP
R2(config-if)#
*Mar  1 00:13:02.011: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

R3(config-crypto-map)#interface serial 0/0
R3(config-if)#crypto map R3_R2_MAP
R3(config-if)#
*Mar  1 00:14:31.447: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

With everything now in place, we should be able to send a ping from 172.16.2.2 (R2’s loopback0 interface) to 172.16.3.3 (R3’s loopback0 interface) and get a response. Note that, because of our access list, we must specify 172.16.2.2 as the source IP address of the pings:

R2#ping 172.16.3.3 source 172.16.2.2

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

We can verify that the VPN is up and running with the use of “show crypto isakmp sa” and “show crypto ipsec sa”:

R2#show crypto isakmp sa
dst             src             state          conn-id slot status
172.16.123.3    172.16.123.2    QM_IDLE              1    0 ACTIVE

R2#show crypto ipsec sa

interface: Serial0/0
    Crypto map tag: R2_R3_MAP, local addr 172.16.123.2

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (172.16.2.2/255.255.255.255/0/0)
   remote ident (addr/mask/prot/port): (172.16.3.3/255.255.255.255/0/0)
   current_peer 172.16.123.3 port 500
     PERMIT, flags={origin_is_acl,ipsec_sa_request_sent}
    #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.: 172.16.123.2, remote crypto endpt.: 172.16.123.3
     path mtu 1500, ip mtu 1500
     current outbound spi: 0x995FE2D0(2573198032)

     inbound esp sas:
      spi: 0x18DD060C(417138188)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2002, flow_id: SW:2, crypto map: R2_R3_MAP
        sa timing: remaining key lifetime (k/sec): (4439841/3591)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x995FE2D0(2573198032)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2001, flow_id: SW:1, crypto map: R2_R3_MAP
        sa timing: remaining key lifetime (k/sec): (4439841/3544)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:

Prior to running that ping, we could’ve done the following in Dynagen to start a packet capture:

=> capture R1 s0/0 ipsec.cap FR

We would then have ended up with a packet capture file we could load up into Wireshark. If you had done that, you would see something like this (click for larger image):

From the packet capture, we can see the ISAKMP negotiation, the IPSec negotation, as well as the ESP (encrypted) traffic between R2 and R3. Because we did the capturing on R1’s serial 0/0 interface, we actually see each packet listed twice in the capture. If we had captured at R2 or R3’s serial 0/0 interface, we would only see them once.

I hope you enjoyed the lab and learned something from it. Let me know if there’s something specific you’d like to see in future labs or video demos!