Tuesday, August 27, 2013

Site-to-Site IPSEC VPN

Implement basic VPN 


Using this small LAB I will try to demonstrate and elaborate an site to site VPN that focuses on Cisco IOS routers. The emulated hardware is of Cisco 7200 series that allows us every IPSEC mechanism that we need for this demonstration. For network engineers this could be useful on a multi site level, depending on the type of encryption they need. So let us start with a diagram.


For the initial LAB setup we need to configure IP addresses for the WAN links and the Loopback interfaces on each router. After that we should add static routes to communicate between the loopbacks.

R1
interface GigabitEthernet1/0
 ip address 10.1.12.1 255.255.255.0
 negotiation auto
end
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
end
!
ip route 2.2.2.2 255.255.255.255 10.1.12.2

R2
interface GigabitEthernet1/0
 ip address 10.1.12.2 255.255.255.0
 negotiation auto
end
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
end
!
ip route 1.1.1.1 255.255.255.255 10.1.12.1

Simple enough ! Now we have a connection between the loopbacks of the routers. First off all, as we get on the actual IPSEC configs we must clarify which technologies we are using.

ISAKMP (Internet Security Association and Key Management Protocol) is a protocol defined by RFC 2408 for establishing Security Associations (SA) and cryptographic keys in an Internet environment. ISAKMP only provides a framework for authentication and key exchange and is designed to be key exchange independent; protocols such as Internet Key Exchange and Kerberized Internet Negotiation of Keys provide authenticated keying material for use with ISAKMP. This framework does not specify any details on key managament or key exchange. 

Internet Key Exchange (IKE or IKEv2) is the protocol used to set up a security association (SA) in the IPsec protocol suite. IKE builds upon the Oakley protocol and ISAKMP.[1] IKE uses X.509 certificates for authentication which are either pre-shared or distributed using DNS (preferably with DNSSEC) and a Diffie–Hellman key exchange to set up a shared session secret from which cryptographic keys are derived. In addition, a security policy for every peer which will connect must be manually maintained.
IKE has two phases that we will be involved later. IKE Phase 1 happens when two peers establish a secure security policy and authentification keys if needed. In IKE Phase 2 Security Associations are negotiated on behalf of services such as IPSEC that needs keying material.

First, we have to configure an ISAKMP policy on R1:

R1
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 2
crypto isakmp key cisco address 10.1.12.2

After this we go on to the second phase IKE phase 2 and configure the transform set, similar to ISAKMP policies are the seeting suites to choose from. Also wee need to mark the interesting traffic and we should do this with an ACL. To bind everything together we should create a MAP and apply that map to an egress interface.

R1
crypto ipsec transform-set FIRST esp-3des esp-md5-hmac
!
crypto map MAP 10 ipsec-isakmp
 set peer 10.1.12.2
 set transform-set FIRST
 match address 120
!
access-list 120 permit ip host 1.1.1.1 host 2.2.2.2

Finally to be done with the R1 we will apply this map to an interface.

R1
interface GigabitEthernet1/0
 crypto map MAP

*Aug 27 10:36:52.151: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON


We should repeat the same config on the second router, chaning only the peer IP of the key in the ISAKMP policy and the ACL.

R2
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 2
crypto isakmp key cisco address 10.1.12.1
!
crypto ipsec transform-set FIRST esp-3des esp-md5-hmac
!
crypto map MAP 10 ipsec-isakmp
 set peer 10.1.12.1
 set transform-set FIRST
 match address 120
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface GigabitEthernet1/0
 ip address 10.1.12.2 255.255.255.0
 negotiation auto
 crypto map MAP
!
ip route 1.1.1.1 255.255.255.255 10.1.12.1
!
access-list 120 permit ip host 2.2.2.2 host 1.1.1.1

We can now test the traffic data plane with a simple ping.

R1#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/28/56 ms

We have a succesfull ping traffic from boot loopack addresses. To finally verify the IPSEC SA and policies we can use the following show output.

R1#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst                 src               state              connid       status
10.1.12.2      10.1.12.1     QM_IDLE     1005        ACTIVE

This is a normal state of IKE. QM_IDLE means that the Quick Mode Phase 2 has been finished.

This is all for now. More to come. 

Feel free to comment.

No comments:

Post a Comment