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