Cisco - DMVPN Explained + GNS3 Lab

DMVPN (dynamic multipoint virtual private network) is a design approach that allows full mesh connectivity with the use of multipoint GRE tunnels. DMVPN itself is not a protocol but rather it is a design approach that consists of the following technologies:

1. NHRP (next-hop resolution protocol)
2. mGRE(multipoint GRE)
3. Routing protocol
4. IP sec encryption (optional)

Most of these technologies are familiar to networking professionals, except for the NHRP protocol. NHRP is a resolution protocol that behaves like ARP. In an NHRP environment, there are two roles, the NHS (next-hop server) and the NHC (next-hop client). The NHCs register themselves with the NHS and provide information, such as their logical VPN IP addresses and the physical NBMA mapping. The NHCs also request information from the NHS about how to reach the other NHCs by learning the logical IP to NBMA mapping information. NHRP was used before in the legacy overlay VPN environment particularly in building frame-relay SVCs (switched virtual circuits). Today the protocol is used in the DMVPN environment as well using the same behavior.

• CLICK HERE TO DOWNLOAD GNS3 0.8.x FILES FOR THIS LAB
• CLICK HERE TO DOWNLOAD GNS3 0.8.7

DMVPN is typically deployed using MPLS and Internet services because DMVPN has the capability to build dynamic tunnels to other spokes or branches without going through the hub site. This makes efficient use of the full mesh topologies mentioned above. If DMVPN is deployed using the Internet, the hub router requires a static public IP address as this will be configured in the NHC routers as the NHS IP address. The spokes don’t require a static public IP address as a tunnel source because they will report their physical IP to logical mappings to the NHS or the hub. In an MPLS environment, using the IP address of the Loopback is an acceptable design. DMVPN provides zero-touch configuration on the hub router if a new spoke is added.

DMVPN has so far three phases of evolution: Phase 1 had only hub-and-spoke, in Phase 2 direct spoke-to-spoke capability for DMVPN was added, and Phase 3 has features that help a hierarchical DMVPN design scale better through the use of NHRP Shortcut and other enhancements. Our lab will focus on more on Phase 2.

In this GNS3 Lab, we will have the following tasks below. Verification will be done for each of the steps.

1. Configure DMVPN on the hub router R1.
2. Configure spokes R2, R3 and R4.
3. Configure EIGRP as the routing protocol and enable spoke-to-spoke tunnels. Add Loopback10 to each of the routers and announce it in EIGRP.
4. Configure encryption.

Below are the physical and logical diagrams.

Figure 1. Network Topology

Figure 2. DMVPN Topology

 

Task 1: Configure DMVPN on the Hub Router R1

The MPLS router in the GNS3 topology has already been pre-configured to peer with all the routers using BGP. The routers in this topology are already announcing their Loopback0s through BGP. Before proceeding with the configuration, let’s check if we can see the loopback IP addresses of all the routers from R1.

R1#sh ip bgp
BGP table version is 5, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
*> 2.2.2.2/32 15.15.15.5 0 65000 65002 i
*> 3.3.3.3/32 15.15.15.5 0 65000 65003 i
*> 4.4.4.4/32 15.15.15.5 0 65000 65004 i

Then we configure Tunnel100 with the DMVPN configuration for hub routers.

R1(config)#int tun100
R1(config-if)#ip add 10.1.1.1 255.255.255.0
R1(config-if)#ip nhrp map multicast dynamic
R1(config-if)#ip nhrp authentication cisco
R1(config-if)#ip nhrp network-id 100
R1(config-if)#tunnel source Loopback0
R1(config-if)#tunnel mode gre multipoint
R1(config-if)#tunnel key 100

Let’s break down the commands one by one.

• ip nhrp map multicast dynamic: Normally this is configured in the hub routers to allow NHRP to automatically add routers to the multicast NHRP mappings so a static mapping is not required any more for each of the spokes. This command also enables routing protocols to work over the mGRE.
• ip nhrp authentication <string>: This is an optional command. All the routers with NHRP within the same DMVPN network must have the same string or password.
• ip nhrp network-id <number>: This is a required command to start NHRP. All routers in the same NHRP network should have the same network-id. This can also be used along with the “tunnel key” command to segregate different DMVPN networks using the same interface/ IP address as the tunnel source.
• tunnel source Loopback0: This is the “physical” or real IP address which the tunnel should be sourced from. In the typical GRE configuration, a tunnel destination is required, but in DMVPN the tunnel destination is resolved through NHRP.
• tunnel mode gre multipoint: Sets the GRE tunnel to behave as a multipoint tunnel.
• tunnel key <number>” Like “ip nhrp network-id,” this allows separation of DMVPN networks using the same interface/ IP address as the source of the tunnel. This was mandatory in the previous IOS versions but, for the most recent ones, the DMVPN tunnel can come up without this command.

 

Task 2: Configure Spokes R2, R3 and R4

Let’s proceed to configure DMVPN on the spokes and explain each command later. The spokes will have a different command set than that of the hub.

R2(config)#interface Tunnel100
R2(config-if)# ip address 10.1.1.2 255.255.255.0
R2(config-if)# ip nhrp map multicast 1.1.1.1
R2(config-if)# ip nhrp map 10.1.1.1 1.1.1.1
R2(config-if)# ip nhrp nhs 10.1.1.1
R2(config-if)# ip nhrp network-id 100
R2(config-if)# ip nhrp registration timeout 60
R2(config-if)# ip nhrp holdtime 120
R2(config-if)# ip nhrp authentication cisco
R2(config-if)# tunnel source Loopback0
R2(config-if)# tunnel mode gre multipoint
R2(config-if)# tunnel key 100

R3(config)#interface Tunnel100
R3(config-if)# ip address 10.1.1.3 255.255.255.0
R3(config-if)# ip nhrp map multicast 1.1.1.1
R3(config-if)# ip nhrp map 10.1.1.1 1.1.1.1
R3(config-if)# ip nhrp nhs 10.1.1.1
R3(config-if)# ip nhrp network-id 100
R3(config-if)# ip nhrp registration timeout 60
R3(config-if)# ip nhrp holdtime 120
R3(config-if)# ip nhrp authentication cisco
R3(config-if)# tunnel source Loopback0
R3(config-if)# tunnel mode gre multipoint
R3(config-if)# tunnel key 100

R4(config)#interface Tunnel100
R4(config-if)# ip address 10.1.1.4 255.255.255.0
R4(config-if)# ip nhrp map multicast 1.1.1.1
R4(config-if)# ip nhrp map 10.1.1.1 1.1.1.1
R4(config-if)# ip nhrp nhs 10.1.1.1
R4(config-if)# ip nhrp network-id 100
R4(config-if)# ip nhrp registration timeout 60
R4(config-if)# ip nhrp holdtime 120
R4(config-if)# ip nhrp authentication cisco
R4(config-if)# tunnel source Loopback0
R4(config-if)# tunnel mode gre multipoint
R4(config-if)# tunnel key 100

Let’s break down and discuss each of the commands.

• ip nhrp map multicast <1.1.1.1>: To put it simply, this command adds the NBMA address, in our case the loopback address of R1, to be a recipient of multicast/broadcast traffic coming from this spoke. The source IP address of the hub router’s DMVPN tunnel is configured as well as the other hub IP address if the design should go for multiple hubs.
• ip nhrp map <10.1.1.1> <1.1.1.1>: To put it simply, this command states that 1.1.1.1 is the NBMA or real IP address of R1’s tunnel IP address of 10.1.1.1.
• ip nhrp nhs <10.1.1.1>: This basically tells the router that the NHS is 10.1.1.1. This is the tunnel IP address of the hub router R1 in our example. The router will know who to consult to if it wishes to form a spoke-to-spoke tunnel. Multiple NHS configurations can be made if there are multiple hubs in the DMVPN network.

The rest of the NHRP commands are self-explanatory. The network-id and tunnel key in the spokes should match what is configured in the hub router.

 

Task 3: Configure EIGRP as the routing protocol and enable spoke-to-spoke tunnels. Add Loopback10 to each of the routers and announce it in EIGRP.

Let’s enable EIGRP and announce the DMVPN network. Any routing protocol can be used, but EIGRP or OSPF are favorable in most designs. One thing to look out for is that for DMVPN spoke-to-spoke to work and bypass the hub, the next-hop IP address of the route should be unchanged, meaning it should not be the IP address of the hub’s tunnel but should be the corresponding spoke tunnel IP address. In OSPF, changing the interface network type to “broadcast” is the solution. EIGRP requires split-horizon to be disabled and next-hop-self on the hub router.

R1(config-if)#interface Loopback10
R1(config-if)#ip address 11.11.11.11 255.255.255.255
!
R1(config)#router eigrp 100
R1(config-router)#no auto-summary
R1(config-router)#network 10.1.1.0 0.0.0.255
R1(config-router)#network 11.11.11.11 0.0.0.0.
!
R1(config-if)#int tun100
R1(config-if)#no ip split-horizon eigrp 100
R1(config-if)#no ip next-hop-self eigrp 100

R2(config)#int lo10
R2(config-if)#ip address 22.22.22.22 255.255.255.255
!
R2(config-if)#router eigrp 100
R2(config-router)#network 10.1.1.0 0.0.0.255
R2(config-router)#network 22.22.22.22 0.0.0.0

R3(config-if)#int l10
R3(config-router)#network 10.1.1.0 0.0.0.255
R3(config-if)#ip address 33.33.33.33 255.255.255.255
!
R3(config-if)#router eigrp 100
R3(config-router)#network 33.33.33.33 0.0.0.0

R4(config-if)#int l10
R4(config-router)#network 10.1.1.0 0.0.0.255
R4(config-if)#ip address 44.44.44.44 255.255.255.255
!
R4(config-if)#router eigrp 100
R4(config-router)#network 44.44.44.44 0.0.0.0

 

Let’s check and verify EIGRP neighbor adjacencies and routes:

R1#sh ip eigrp ne
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 10.1.1.4 Tu100 14 00:03:18 79 474 0 7
1 10.1.1.3 Tu100 12 00:04:42 76 456 0 6
0 10.1.1.2 Tu100 14 00:04:42 66 396 0 5

R1#sh ip route eigrp
33.0.0.0/32 is subnetted, 1 subnets
D 33.33.33.33 [90/14208000] via 10.1.1.3, 00:01:24, Tunnel100
22.0.0.0/32 is subnetted, 1 subnets
D 22.22.22.22 [90/14208000] via 10.1.1.2, 00:02:58, Tunnel100
44.0.0.0/32 is subnetted, 1 subnets
D 44.44.44.44 [90/14208000] via 10.1.1.4, 00:00:44, Tunnel100

Let’s check how many NHRP entries before we ping 44.44.44.44 from R2, using 22.22.22.22 as source. We will only see one static mapping which is going to R1, the NHS.

R2#sh ip nhrp
10.1.1.1/32 via 10.1.1.1, Tunnel100 created 00:12:55, never expire
Type: static, Flags: authoritative used
NBMA address: 1.1.1.1

We will now test if spoke-to-spoke is possible. Let’s trace from R2 to R4. Take note that in some cases the trace will go to R1 for the initial traffic. The succeeding packets will go directly to R4. The reason for this is that. when the initial traffic is sent, R2 is still in the process of getting information about how to reach R4 directly through NHRP.

R2#traceroute 44.44.44.44 source 22.22.22.22
Type escape sequence to abort.
Tracing the route to 44.44.44.44

1 10.1.1.4 36 msec 36 msec 36 msec

R2#sh ip route 44.44.44.44
Routing entry for 44.44.44.44/32
Known via "eigrp 100", distance 90, metric 27008000, type internal
Redistributing via eigrp 100
Last update from 10.1.1.4 on Tunnel100, 00:02:20 ago
Routing Descriptor Blocks:
* 10.1.1.4, from 10.1.1.1, 00:02:20 ago, via Tunnel100
Route metric is 27008000, traffic share count is 1
Total delay is 1005000 microseconds, minimum bandwidth is 2000 Kbit
Reliability 255/255, minimum MTU 1200 bytes
Loading 1/255, Hops 2

R2#sh ip nhrp
10.1.1.1/32 via 10.1.1.1, Tunnel100 created 00:14:45, never expire
Type: static, Flags: authoritative used
NBMA address: 1.1.1.1
10.1.1.4/32 via 10.1.1.4, Tunnel100 created 00:00:04, expire 00:01:14
Type: dynamic, Flags: router used
NBMA address: 4.4.4.4

The traceroute above shows that the path taken was directly to the tunnel IP address of R4. The “show ip nhrp” command showed as well that the R2 built a direct spoke-to-spoke to R4 and traffic did not pass through R1.

 

Task 4: Configure Encryption

A good network design includes a way to secure traffic. This is a must, given that DMVPN is deployed into shared topologies like internet and MPLS. Let’s proceed to configure IP sec encryption. We will begin with configuration of the IP sec policy, SA, and profiles.

On All Routers:

crypto isakmp policy 5
encr aes 256
group 2
authentication pre-share
!
crypto isakmp key 0 cisco address 0.0.0.0 0.0.0.0
!
crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 10
!
crypto ipsec security-association lifetime kilobytes 536870912
crypto ipsec security-association replay disable
!
crypto ipsec transform-set DMVPN esp-aes 256 esp-sha-hmac comp-lzs
crypto ipsec df-bit clear
!
crypto ipsec profile DMVPN
set transform-set DMVPN

Then let’s apply the crypto IP sec profile as tunnel protection mode on the tunnels for each router.

R1(ipsec-profile)#int Tunnel100
R1(config-if)# tunnel protection ipsec profile DMVPN
R1(config-if)#end
R1#
*Mar 1 00:25:45.115: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
*Mar 1 00:25:45.191: %SYS-5-CONFIG_I: Configured from console by console
R1#
*Mar 1 00:25:45.731: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet.
(ip) vrf/dest_addr= /1.1.1.1, src_addr= 2.2.2.2, prot= 47

R2(ipsec-profile)#int Tunnel100
R2(config-if)# tunnel protection ipsec profile DMVPN

R3(ipsec-profile)#int Tunnel100
R3(config-if)# tunnel protection ipsec profile DMVPN

R4(config)#int Tunnel100
R4(config-if)# tunnel protection ipsec profile DMVPN

The network adjacencies will be lost and will only recover until the configurations are complete for each router. Now, let’s verify if traffic is encrypted and network connectivity is still up.

R1#ping 22.22.22.22 source 11.11.11.11
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 22.22.22.22, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/62/76 ms

R1#ping 33.33.33.33 source 11.11.11.11
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 33.33.33.33, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/52/64 ms

R1#ping 44.44.44.44 source 11.11.11.11
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 44.44.44.44, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/80/100 ms

R1#sh crypto isakmp sa
dst src state conn-id slot status
1.1.1.1 3.3.3.3 QM_IDLE 2 0 ACTIVE
1.1.1.1 2.2.2.2 QM_IDLE 1 0 ACTIVE
1.1.1.1 4.4.4.4 QM_IDLE 3 0 ACTIVE

The “QM_IDLE” means that IP sec is working properly. EIGRP adjacencies are restored. Now we have successfully created a secure and encrypted DMVPN network.

References

• http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/converged-vpn-solution-managed-services/prod_white_paper0900aecd8055c34e.html
• http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr/command/ipaddr-cr-book/ipaddr-i4.html#wp3934211390
• http://www.cisco.com/c/dam/en/us/products/collateral/security/dynamic-multipoint-vpn-dmvpn/DMVPN_Overview.pdf
• https://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a008075ea98.pdf

 

Based On:

• Original Post: http://resources.intenseschool.com/gns3-lab-introduction-to-dmvpn/
• I have underlined the changes to the config I made to correct to the original post by: Peterson Amar

Cisco IPsec Configuration

^{by Priscilla Oppenheimer}

This example annotates the configuration of two Cisco routers configured to send encrypted traffic across an IPsec tunnel. Following the annotations are some explanations of Cisco show commands that are useful when troubleshooting IPsec. The two routers are connected via Frame Relay. Each router also has a Fast Ethernet interface where end nodes reside, as shown in the following figure. The end nodes' traffic will be encrypted when traversing the IPsec tunnel.

R1 Annotated Configuration

R1's configuration is shown below. Annotations start with !---- and are in blue.
R1#show run
Building configuration...
Current configuration : 1907 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
no aaa new-model
!
ip cef
!

!---- The IPsec configuration starts with configuring the Internet Security Association and Key Management Protocol (ISAKMP). ISAKMP is a framework for authentication and key exchange. Cisco uses Internet Key Exchange (IKE) which is derived from ISAKMP. IKE establishes a shared security policy and authenticated keys for IPsec to use.
First we create Policy 1. Then we say that we'll use MD5 to hash the IKE exchange, though we could use SHA (the Cisco default). We'll use DES to encrypt IKE, though we could use AES. (Because DES is the default it doesn't show in the configuration.)
We could use a Certificate Authority (CA) for authentication, but for our example we will manually enter a pre-shared key into each router. We will use "MyKey" for the key.
We also provide the address of our peer, 10.102.0.2. ----!

crypto isakmp policy 1
hash md5
authentication pre-share
crypto isakmp key MyKey address 10.102.0.2
!
!---- Next, we create an IPsec transform set that we call MySet. We specify the authentication protocol for the IPsec Authentication Header (AH) and we specify the encryption protocol for the IPsec Encapsulating Security Payload (ESP). These don't have to be the same proocols that IKE uses. In fact, we'll use SHA for authentication and AES-256 for encryption.----!
crypto ipsec transform-set MySet ah-sha-hmac esp-aes 256
!
!---- You can't expect Cisco to make anything easy! So next we create a crypto map, called MyMap, with sequence number 1. (A crypto map can be a collection of entries, each with a different sequence number, though we'll just use one entry.) The ipsec-isakmp argument tells the router that this map is an IPsec map. We tell the router about its peer (10.102.0.2) yet again and we set the security-association (SA) lifetime.

We will use 190 seconds for the SA lifetime because Cisco examples use 190. It seems too short but there's a tradeoff. If you make it too long you risk attackers being more successful. If you make it too short, the routers have to do more work to renegotiate the SA more often. The default is based on a global command that affects all maps and is 3600 seconds (one hour).
Our crypto map points to our MySet transform set. It also references access-list 101, which is later in the configuration and specifies which traffic will be encrypted. ----!

crypto map MyMap 1 ipsec-isakmp
set peer 10.102.0.2
set security-association lifetime seconds 190
set transform-set MySet
match address 101
!
interface FastEthernet0/0
ip address 10.1.0.1 255.255.0.0
!
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
!
!---- Here we apply our crypto map to the interface that will be sending the encrypted traffic. The interface is a Frame Relay sub-interface with DLCI 102 that connects to our peer at the other end. Our address is 10.102.0.1. (Our peer is 10.102.0.2 as we've already seen.) ----!

interface Serial1/0.102 point-to-point
ip address 10.102.0.1 255.255.0.0
frame-relay interface-dlci 102  
crypto map MyMap
!
router ospf 100
log-adjacency-changes
network 10.0.0.0 0.255.255.255 area 0
!
no ip http server
no ip http secure-server
!

!---- Access list 101 specifies which traffic will use IPsec. Note that access-list 101 is referenced in the crypto map statement for MyMap above. ----!

access-list 101 permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
!
line con 0
logging synchronous
stopbits 1
line aux 0
stopbits 1
line vty 0 4
login
!
end
R1#   

R2 Annotated Configuration

R2's configuration is shown below. Annotations start with !---- and are in blue. Notice that R2 needs fewer annotations. It needs to match R1 so they will act like nice peers and not fight with each other.

R2#show run
Building configuration...
Current configuration : 1894 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R2
!
boot-start-marker
boot-end-marker
!
no aaa new-model
!
ip cef
!
!---- Here we configure ISAKMP (IKE) as we did on R1. Note that for R2, we use 10.102.0.1 (R1) for our peer. ----!

crypto isakmp policy 1
hash md5
authentication pre-share
crypto isakmp key MyKey address 10.102.0.1
!

!---- Next, we create an IPsec transform like we did on R1.  ----!

crypto ipsec transform-set MySet ah-sha-hmac esp-aes 256
!

!---- Here's our map that points to our peer (R1) and references access list 101.  ----!

crypto map MyMap 1 ipsec-isakmp
set peer 10.102.0.1
set security-association lifetime seconds 190
set transform-set MySet
match address 101
!
interface FastEthernet0/0
ip address 10.2.0.1 255.255.0.0
!
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
frame-relay lmi-type ansi
!
!---- Add the crypto map to the interface that connects back to R1.  ----!
interface Serial1/0.201 point-to-point
ip address 10.102.0.2 255.255.0.0
frame-relay interface-dlci 201  
crypto map MyMap
!
router ospf 100
log-adjacency-changes
network 10.0.0.0 0.255.255.255 area 0
!
no ip http server
no ip http secure-server
!

!---- As we did on R1, we define an access list to specify which traffic will use IPsec. The access-list is referenced in the crypto map statement for MyMap above. ----!

access-list 101 permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
!
line con 0
logging synchronous
stopbits 1
line aux 0
stopbits 1
line vty 0 4
login
!
!
end
R2# 

R2 Show Commands

Once you have configured the router peers, a variety of show commands will help you verify that the security associations are live and the traffic is being encrypted.

!---- The show crypto session command lets us verify that the IKE session is active. Notice that we're talking to our peer via UDP port 500, the port for IKE. ----!

R2#show crypto session
Crypto session current status
Interface: Serial1/0.201
Session status: UP-ACTIVE    
Peer: 10.102.0.1 port 500
  IKE SA: local 10.102.0.2/500 remote 10.102.0.1/500 Active
  IPSEC FLOW: permit ip 10.0.0.0/255.0.0.0 10.0.0.0/255.0.0.0
        Active SAs: 4, origin: crypto map

!---- The show crypto isakmp policy command tells us more than we ever wanted to know about our IKE session. ----!

R2#show crypto isakmp policy
Global IKE policy
Protection suite of priority 1
        encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
        hash algorithm:         Message Digest 5
        authentication method:  Pre-Shared Key
        Diffie-Hellman group:   #1 (768 bit)
        lifetime:               86400 seconds, no volume limit
Default protection suite
        encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
        hash algorithm:         Secure Hash Standard
        authentication method:  Rivest-Shamir-Adleman Signature
        Diffie-Hellman group:   #1 (768 bit)
        lifetime:               86400 seconds, no volume limit

!---- The show crypto map verifies our IPsec status. We aren't using Perfect Forward Secrecy (PFS) as we don't need that extra protection from evil-doers. ----!

R2#show crypto map
Crypto Map "MyMap" 1 ipsec-isakmp
        Peer = 10.102.0.1
        Extended IP access list 101
            access-list 101 permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
        Current peer: 10.102.0.1
        Security association lifetime: 4608000 kilobytes/190 seconds
        PFS (Y/N): N
        Transform sets={
                MySet,
        }
        Interfaces using crypto map MyMap:
                Serial1/0.201

!---- The show crypto ipsec transform-set verifies our IPsec status and shows that we're using tunnel mode (rather than transport mode). Tunnel mode is appropriate for a router-to-router configuration as opposed to an end node talking to another end node. ----!

R2#show crypto ipsec transform-set
Transform set MySet: { ah-sha-hmac  }
   will negotiate = { Tunnel,  },
   { esp-256-aes  }
   will negotiate = { Tunnel,  },

!---- The show crypto ipsec sa command shows identity information and packet counts and then displays information about all our security associations (SAs) . Notice that there's an inbound SA and an outbound SA for both authentication (AH) and encryption (ESP). The inbound and outbound Payload Compression Protocol (PCP) SAs aren't active, but the others are. They became active because a PC connected to R1's Fast Ethernet interface pinged a PC connected to R2's Fast Ethernet interface. Each SA is identified by a unique security parameter index (SPI). ----!

R2#show crypto ipsec sa               
interface: Serial1/0.201
    Crypto map tag: MyMap, local addr 10.102.0.2
   protected vrf: (none)
   local  ident (addr/mask/prot/port): (10.0.0.0/255.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (10.0.0.0/255.0.0.0/0/0)
   current_peer 10.102.0.1 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 13, #pkts encrypt: 13, #pkts digest: 13
    #pkts decaps: 13, #pkts decrypt: 13, #pkts verify: 13
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 2, #recv errors 0
     local crypto endpt.: 10.102.0.2, remote crypto endpt.: 10.102.0.1
     path mtu 1500, ip mtu 1500, ip mtu idb Serial1/0.201
     current outbound spi: 0x8590D11F(2240860447)
     inbound esp sas:
      spi: 0xFDC7B87B(4257724539)
        transform: esp-256-aes ,
        in use settings ={Tunnel, }
        conn id: 2004, flow_id: SW:4, crypto map: MyMap
        sa timing: remaining key lifetime (k/sec): (4565647/146)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE
     inbound ah sas:
      spi: 0x11B79D1C(297245980)
        transform: ah-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2004, flow_id: SW:4, crypto map: MyMap
        sa timing: remaining key lifetime (k/sec): (4565647/140)
        replay detection support: Y
        Status: ACTIVE
     inbound pcp sas:
     outbound esp sas:
      spi: 0x8590D11F(2240860447)
        transform: esp-256-aes ,
        in use settings ={Tunnel, }
        conn id: 2003, flow_id: SW:3, crypto map: MyMap
        sa timing: remaining key lifetime (k/sec): (4565647/134)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE
     outbound ah sas:
      spi: 0xECA2A6B8(3970082488)
        transform: ah-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2003, flow_id: SW:3, crypto map: MyMap
        sa timing: remaining key lifetime (k/sec): (4565647/132)
        replay detection support: Y
        Status: ACTIVE
     outbound pcp sas:

Taken From: http://www.priscilla.com/ipsecexample.htm

For more complex configurations check:
http://www.routeralley.com/ra/docs/ipsec_site2site_router.pdf

For more detail on IKE:
http://en.wikipedia.org/wiki/Internet_Key_Exchange

Creating VPNs - IPSEC and OpenVPN (SSL/TLS)

Creating VPNs with IPsec and SSL/TLS

VPN (Virtual Private Network) is a technology that provides secure communication through an insecure and untrusted network (like the Internet). Usually, it achieves this by authentication, encryption, compression and tunneling. Tunneling is a technique that encapsulates the packet header and data of one protocol inside the payload field of another protocol. This way, an encapsulated packet can traverse through networks it otherwise would not be capable of traversing.

Figure 1. A Basic VPN Tunnel

Currently, the two most common techniques for creating VPNs are IPsec and SSL/TLS. In this article, I describe the features and characteristics of these two techniques and present two short examples of how to create IPsec and SSL/TLS tunnels in Linux and verify that the tunnels started correctly. I also provide a short comparison of these two techniques.

IPsec and Openswan

IPsec (IP security) provides encryption, authentication and compression at the network level. IPsec is actually a suite of protocols, developed by the IETF (Internet Engineering Task Force), which have existed for a long time. The first IPsec protocols were defined in 1995 (RFCs 1825–1829). Later, in 1998, these RFCs were depreciated by RFCs 2401–2412. IPsec implementation in the 2.6 Linux kernel was written by Dave Miller and Alexey Kuznetsov. It handles both IPv4 and IPv6. IPsec operates at layer 3, the network layer, in the OSI seven-layer networking model. IPsec is mandatory in IPv6 and optional in IPv4. To implement IPsec, two new protocols were added: Authentication Header (AH) and Encapsulating Security Payload (ESP). Handshaking and exchanging session keys are done with the Internet Key Exchange (IKE) protocol.

The AH protocol (RFC 2404) has protocol number 51, and it authenticates both the header and payload. The AH protocol does not use encryption, so it is almost never used.

ESP has protocol number 50. It enables us to add a security policy to the packet and encrypt it, though encryption is not mandatory. Encryption is done by the kernel, using the kernel CryptoAPI. When two machines are connected using the ESP protocol, a unique number identifies this connection; this number is called SPI (Security Parameter Index). Each packet that flows between these machines has a Sequence Number (SN), starting with 0. This SN is increased by one for each sent packet. Each packet also has a checksum, which is called the ICV (integrity check value) of the packet. This checksum is calculated using a secret key, which is known only to these two machines.

IPsec has two modes: transport mode and tunnel mode. When creating a VPN, we use tunnel mode. This means each IP packet is fully encapsulated in a newly created IPsec packet. The payload of this newly created IPsec packet is the original IP packet.

Figure 2. An IPsec Tunnel ESP Packet

Figure 2 shows that a new IP header was added at the right, as a result of working with a tunnel, and that an ESP header also was added.

There is a problem when the endpoints (which are sometimes called peers) of the tunnel are behind a NAT (Network Address Translation) device. Using NAT is a method of connecting multiple machines that have an “internal address”, which are not accessible directly to the outside world. These machines access the outside world through a machine that does have an Internet address; the NAT is performed on this machine—usually a gateway.

When the endpoints of the tunnel are behind a NAT, the NAT modifies the contents of the IP packet. As a result, this packet will be rejected by the peer because the signature is wrong. Thus, the IETF issued some RFCs that try to find a solution for this problem. This solution commonly is known as NAT-T or NAT Traversal. NAT-T works by encapsulating IPsec packets in UDP packets, so that these packets will be able to pass through NAT routers without being dropped. RFC 3948, UDP Encapsulation of IPsec ESP Packets, deals with NAT-T (see Resources).

Openswan is an open-source project that provides an implementation of user tools for Linux IPsec. You can create a VPN using Openswan tools (shown in the short example below). The Openswan Project was started in 2003 by former FreeS/WAN developers. FreeS/WAN is the predecessor of Openswan. S/WAN stands for Secure Wide Area Network, which is actually a trademark of RSA. Openswan runs on many different platforms, including x86, x86_64, ia64, MIPS and ARM. It supports kernels 2.0, 2.2, 2.4 and 2.6.

Two IPsec kernel stacks are currently available: KLIPS and NETKEY. The Linux kernel NETKEY code is a rewrite from scratch of the KAME IPsec code. The KAME Project was a group effort of six companies in Japan to provide a free IPv6 and IPsec (for both IPv4 and IPv6) protocol stack implementation for variants of the BSD UNIX computer operating system.

KLIPS is not a part of the Linux kernel. When using KLIPS, you must apply a patch to the kernel to support NAT-T. When using NETKEY, NAT-T support is already inside the kernel, and there is no need to patch the kernel.

When you apply firewall (iptables) rules, KLIPS is the easier case, because with KLIPS, you can identify IPsec traffic, as this traffic goes through ipsecX interfaces. You apply iptables rules to these interfaces in the same way you apply rules to other network interfaces (such as eth0).

When using NETKEY, applying firewall (iptables) rules is much more complex, as the traffic does not flow through ipsecX interfaces; one solution can be marking the packets in the Linux kernel with iptables (with a setmark iptables rule). This mark is a member of the kernel socket buffer structure (struct sk_buff, from the Linux kernel networking code); decryption of the packet does not modify that mark.

Openswan supports Opportunistic Encryption (OE), which enables the creation of IPsec-based VPNs by advertising and fetching public keys from a DNS server.

OpenVPN

OpenVPN is an open-source project founded by James Yonan. It provides a VPN solution based on SSL/TLS. Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide secure communications data transfer on the Internet. SSL has been in existence since the early '90s.

The OpenVPN networking model is based on TUN/TAP virtual devices; TUN/TAP is part of the Linux kernel. The first TUN driver in Linux was developed by Maxim Krasnyansky.

OpenVPN installation and configuration is simpler in comparison with IPsec. OpenVPN supports RSA authentication, Diffie-Hellman key agreement, HMAC-SHA1 integrity checks and more. When running in server mode, it supports multiple clients (up tp 128) to connect to a VPN server over the same port. You can set up your own Certificate Authority (CA) and generate certificates and keys for an OpenVPN server and multiple clients.

OpenVPN operates in user-space mode; this makes it easy to port OpenVPN to other operating systems.

Example: Setting Up a VPN Tunnel with IPsec and Openswan

First, download and install the ipsec-tools package and the Openswan package (most distros have these packages).

The VPN tunnel has two participants on its ends, called left and right, and which participant is considered left or right is arbitrary. You have to configure various parameters for these two ends in /etc/ipsec.conf (see man 5 ipsec.conf). The /etc/ipsec.conf file is divided into sections. The conn section contains a connection specification, defining a network connection to be made using IPsec.

An example of a conn section in /etc/ipsec.conf, which defines a tunnel between two nodes on the same LAN, with the left one as 192.168.0.89 and the right one as 192.168.0.92, is as follows:

...
conn linux-to-linux
#
# Simply use raw RSA keys
# After starting openswan, run:
# ipsec showhostkey --left (or --right)
# and fill in the connection similarly
# to the example below.
left=192.168.0.89
leftrsasigkey=0sAQPP...
# The remote user.
#
right=192.168.0.92
rightrsasigkey=0sAQON...
type=tunnel
auto=start
...
You can generate the leftrsasigkey and rightrsasigkey on both participants by running:

ipsec rsasigkey --verbose 2048 > rsa.key
Then, copy and paste the contents of rsa.key into /etc/ipsec.secrets.

In some cases, IPsec clients are roaming clients (with a random IP address). This happens typically when the client is a laptop used from remote locations (such clients are called Roadwarriors). In this case, use the following in ipsec.conf:

right=%any
instead of:

right=ipAddress
The %any keyword is used to specify an unknown IP address.

The type parameter of the connection in this example is tunnel (which is the default). Other types can be transport, signifying host-to-host transport mode; passthrough, signifying that no IPsec processing should be done at all; drop, signifying that packets should be discarded; and reject, signifying that packets should be discarded and a diagnostic ICMP should be returned.

The auto parameter of the connection tells which operation should be done automatically at IPsec startup. For example, auto=start tells it to load and initiate the connection; whereas auto=ignore (which is the default) signifies no automatic startup operation. Other values for the auto parameter can be add, manual or route.

After configuring /etc/ipsec.conf, start the service with:

service ipsec start
You can perform a series of checks to get info about IPsec on your machine by typing ipsec verify. And, output of ipsec verify might look like this:

Checking your system to see if IPsec has installed and started correctly:
Version check and ipsec on-path [OK]
Linux Openswan U2.4.7/K2.6.21-rc7 (netkey)
Checking for IPsec support in kernel [OK]
NETKEY detected, testing for disabled ICMP send_redirects [OK]
NETKEY detected, testing for disabled ICMP accept_redirects [OK]
Checking for RSA private key (/etc/ipsec.d/hostkey.secrets) [OK]
Checking that pluto is running [OK]
Checking for 'ip' command [OK]
Checking for 'iptables' command [OK]
Opportunistic Encryption Support [DISABLED]
You can get information about the tunnel you created by running:

ipsec auto --status
You also can view various low-level IPSec messages in the kernel syslog.

You can test and verify that the packets flowing between the two participants are indeed esp frames by opening an FTP connection (for example), between the two participants and running:

tcpdump -f esp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
You should see something like this:

IP 192.168.0.92 > 192.168.0.89: ESP(spi=0xd514eed9,seq=0x7)
IP 192.168.0.89 > 192.168.0.92: ESP(spi=0x3a1563b9,seq=0x6)
IP 192.168.0.89 > 192.168.0.92: ESP(spi=0x3a1563b9,seq=0x7)
IP 192.168.0.92 > 192.168.0.89: ESP(spi=0xd514eed9,seq=0x8)
Note that the spi (Security Parameter Index) header is the same for all packets; this is an identifier of the connection.

If you need to support NAT traversal, add nat_traversal=yes in ipsec.conf; nat_traversal=no is the default.

The Linux IPsec stack can work with pluto from Openswan, racoon from the KAME Project (which is included in ipsec-tools) or isakmpd from OpenBSD.

Example: Setting Up a VPN Tunnel with OpenVPN

First, download and install the OpenVPN package (most distros have this package).

Then, create a shared key by doing the following:

openvpn --genkey --secret static.key

You can create this key on the server side or the client side, but you should copy this key to the other side in a secured channel (like SSH, for example). This key is exchanged between client and server when the tunnel is created.

This type of shared key is the simplest key; you also can use CA-based keys. The CA can be on a different machine from the OpenVPN server. The OpenVPN HOWTO provides more details on this (see Resources).

Then, create a server configuration file named server.conf:

dev tun
ifconfig 10.0.0.1 10.0.0.2
secret static.key
comp-lzo
On the client side, create the following configuration file named client.conf:

remote serverIpAddressOrHostName
dev tun
ifconfig 10.0.0.2 10.0.0.1
secret static.key
comp-lzo
Note that the order of IP addresses has changed in the client.conf configuration file.

The comp-lzo directive enables compression on the VPN link.

You can set the mtu of the tunnel by adding the tun-mtu directive. When using Ethernet bridging, you should use dev tap instead of dev tun.

The default port for the tunnel is UDP port 1194 (you can verify this by typing netstat -nl | grep 1194 after starting the tunnel).

Before you start the VPN, make sure that the TUN interface (or TAP interface, in case you use Ethernet bridging) is not firewalled.

Start the vpn on the server by running openvpn server.conf and running openvpn client.conf on the client.

You will get an output like this on the client:

OpenVPN 2.1_rc2 x86_64-redhat-linux-gnu [SSL] [LZO2] [EPOLL] built on
Mar 3 2007
IMPORTANT: OpenVPN's default port number is now 1194, based on an official
port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000
as
the default port.
LZO compression initialized
TUN/TAP device tun0 opened
/sbin/ip link set dev tun0 up mtu 1500
/sbin/ip addr add dev tun0 local 10.0.0.2 peer 10.0.0.1
UDPv4 link local (bound): [undef]:1194
UDPv4 link remote: 192.168.0.89:1194
Peer Connection Initiated with 192.168.0.89:1194
Initialization Sequence Completed
You can verify that the tunnel is up by pinging the server from the client (ping 10.0.0.1 from the client).

The TUN interface emulates a PPP (Point-to-Point) network device and the TAP emulates an Ethernet device. A user-space program can open a TUN device and can read or write to it. You can apply iptables rules to a TUN/TAP virtual device in the same way you would do it to an Ethernet device (such as eth0).

IPsec and OpenVPN—a Short Comparison
IPsec is considered the standard for VPN; many vendors (including Cisco, Nortel, CheckPoint and many more) manufacture devices with built-in IPsec functionalities, which enable them to connect to other IPsec clients.

However, we should be a bit cautious here: different manufacturers may implement IPsec in a noncompatible manner on their devices, which can pose a problem.

OpenVPN is not supported currently by most vendors.

IPsec is much more complex than OpenVPN and involves kernel code; this makes porting IPsec to other operating systems a much heavier task. It is much easier to port OpenVPN to other operating systems than IPsec, because OpenVPN runs entirely in user space and is not involved with kernel code.

Both IPsec and OpenVPN use HMAC (Hash Message Authentication Code) to authenticate packets.

OpenVPN is based on using the OpenSSL library; it can run over UDP (which is the default and preferred protocol) or TCP. As opposed to IPsec, which runs in kernel, it runs in user space, so it is heavier than IPsec in terms of performance.

Configuring and applying firewall (iptables) rules in OpenVPN is usually easier than configuring such rules with Openswan in an IPsec-based tunnel.

Acknowledgement
Thanks to Mr Ken Bantoft for his comments.

Resources

OpenVPN: openvpn.net

OpenVPN 2.0 HOWTO: openvpn.net/howto.html

RFC 3948, UDP Encapsulation of IPsec ESP Packets: tools.ietf.org/html/rfc3948

Openswan: www.openswan.org

The KAME Project: www.kame.net

Rami Rosen is a computer science graduate of Technion, the Israel Institute of Technology, located in Haifa. He works as a Linux and Open Solaris kernel programmer for a networking startup, and he can be reached at ramirose@gmail.com. In his spare time, he likes running, solving cryptic puzzles and helping everyone he knows move to this wonderful operating system, Linux.

Taken From: http://www.linuxjournal.com/article/9916