THE FASCINATING WORLD OF NETWORKING
OPTIMIZED FOR GOOGLE CHROME
DVTI with EIGRP and NAT, using GNS3
Date: 9-8-2016
Table of Contents
Introduction
A Dynamic Virtual Tunnel Interface (DVTI) was originally used for creating remote-access VPNs using the EasyVPN feature. However, in newer router IOS versions, this VPN Type is suitable for creating scalable Hub-and-Spoke topologies which can accommodate a large number of remote branch offices. Using the traditional VPN technology, we would have to configure static VTIs on the hub for the tunnels between the hub and every spoke.
In topologies where the number of spokes is big, do the following:
-
Branches/spokes with static VTI.
-
Central branch/Hub with dynamic VTI plus: ISAKMP Profile, Key Ring with PSKs and Virtual Template.
A DVTI requires minimal configuration on the HUB router; A single “Virtual-Template” interface is configured on the Hub and an IPSEC security profile can be attached on this interface for protection. The remote Spoke branch sites can use Static VTI interfaces (Tunnel Interfaces) and create dynamic IPSEC VTI tunnels with the HUB. Each Spoke-to-Hub tunnel creates a dynamic “virtual-access” tunnel interface on the HUB which is cloned from the Virtual-Tunnel interface.
The template can include normal interface features like ACLs, Netflow accounting, IOS firewall settings and QoS which are then applied to the dynamically created access interface.
The configuration of the central HUB site does not need to change when new Spoke sites are added in the topology; The “Virtual-Template” concept was originally used in legacy dial-up networks were multiple remote dial-up clients could connect to a central dial-up router.
Dynamic routing protocols (such as OSPF and EIGRP) can be configured on both HUB and Spoke sites thus making the whole topology very scalable and easy to deploy. Through the dynamic routing protocol, all Spoke sites will learn the networks of the other branch Spokes, and therefore the spokes can communicate between each other through the central Hub router (this scenario applies in all Route-Based VPNs).
In order to have direct Spoke-to-Spoke communication you need to go with the DMVPN technology.
Topology
NOTE In some IOS versions you can see the following messages from the hub:
%CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=10.10.10.2, prot=50, spi=0x97C81478(2546472056), srcaddr=10.10.10.6
In these cases, the hub won’t be able to derive the virtual access interface for this spoke, and no EIGRP neighbors won’t be possible between hub and this spoke. For example, this happens using IOS: c3640-jk9s-mz.124-16.bin on GNS3.
So, I will use: c2691-adventerprisek9_ivs-mz.124-9.T7.bin
-
PC IP address: 192.168.1.2/24;
-
Huawei Router (ISP Router) IP address: 192.168.1.1/24
Recommendations
In the real world, the s0/0 interface of every router will have a public IP address. In this case, I will assign RFC addresses since I can’t configure static routers on my ISP router pointing to public networks. This is necessary to link this GNS3 topology to the Internet.
Besides, in a real environment you should use private RFC or public IP addresses for loopback interfaces. Don’t use special IP addresses like: 1.1.1.1, 2.2.2.2, …
DVTI Configuration
Initial Configuration:
R1
interface S0/0
ip address 172.16.1.2 255.255.255.252
no shut
!
int loopback 0
ip address 1.1.1.1 255.255.255.255
!
int loopback 1
ip address 192.168.100.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 172.16.1.1
!
R2
interface S0/0
ip address 172.16.2.2 255.255.255.252
no shut
!
int loopback 0
ip address 2.2.2.2 255.255.255.255
!
int loopback 1
ip address 192.168.200.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 172.16.2.1
!
R3
interface S0/0
ip address 172.16.3.2 255.255.255.252
no shut
!
int loopback 0
ip address 3.3.3.3 255.255.255.255
!
int loopback 1
ip address 192.168.3.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 172.16.3.1
!
R4
int S0/2
ip address 172.16.3.1 255.255.255.252
no shut
!
int S0/1
ip address 172.16.2.1 255.255.255.252
no shut
!
int S0/0
ip address 172.16.1.1 255.255.255.252
no shut
!
int fa0/0
description connected to my computer
ip add 192.168.1.150 255.255.255.0
no shut
NOTE Before adding IKE phase 1 and 2 commands, test connectivity between R1, R2 and R3.
Final Configuration:
R1
interface Virtual-Template1 type tunnel
ip unnumbered Loopback0
tunnel mode ipsec ipv4
!
crypto keyring remotebranchkeys
pre-shared-key address 0.0.0.0 0.0.0.0 key strongkey123
!
crypto isakmp policy 5
hash sha
authentication pre-share
group 5
lifetime 86400
encryption aes 256
!
crypto isakmp profile DVTI
keyring remotebranchkeys
match identity address 0.0.0.0
Virtual-template 1
!
crypto ipsec transform-set P2P-SET esp-aes 256 esp-sha-hmac
mode tunnel
!
crypto ipsec profile P2P-PROFILE
set transform-set P2P-SET
!
interface Virtual-Template1 type tunnel
tunnel protection ipsec profile P2P-PROFILE
!
router eigrp 100
no auto-summary
network 192.168.100.0 0.0.0.255
network 1.1.1.1 0.0.0.0
R2
interface Tunnel 0
ip unnumbered loopback0
tunnel source s0/0
tunnel destination 172.16.1.2
tunnel mode ipsec ipv4
!
crypto isakmp policy 5
hash sha
authentication pre-share
group 5
lifetime 86400
encryption aes 256
!
crypto isakmp key strongkey123 address 172.16.1.2
!
crypto ipsec transform-set P2P-SET esp-aes 256 esp-sha-hmac
mode tunnel
!
crypto ipsec profile P2P-PROFILE
set transform-set P2P-SET
!
int tunnel 0
tunnel protection ipsec profile P2P-PROFILE
!
router eigrp 100
network 192.168.200.0 0.0.0.255
network 2.2.2.2 0.0.0.0
no auto-summary
R3
interface Tunnel 0
ip unnumbered loopback0
tunnel source S0/0
tunnel destination 172.16.1.2
tunnel mode ipsec ipv4
!
crypto isakmp policy 5
hash sha
authentication pre-share
group 5
lifetime 86400
encryption aes 256
!
crypto isakmp key strongkey123 address 172.16.1.2
!
crypto ipsec transform-set P2P-SET esp-aes 256 esp-sha-hmac
mode tunnel
!
crypto ipsec profile P2P-PROFILE
set transform-set P2P-SET
!
int tunnel 0
tunnel protection ipsec profile P2P-PROFILE
!
router eigrp 100
network 192.168.3.0 0.0.0.255
network 3.3.3.3 0.0.0.0
no auto-summary
Testing VPN on Hub
Internet Connection
Now, let’s connect this topology to the Internet. I will test the Internet connection only from R1.
From CLI (XP Windows):
route add 172.16.1.0 mask 255.255.255.252 192.168.1.150
route add 192.168.100.0 mask 255.255.255.0 192.168.1.150
…
On R4:
ip route 0.0.0.0 0.0.0.0 192.168.1.1
ip route 192.168.100.0 255.255.255.0 172.16.1.2
ip route 192.168.200.0 255.255.255.0 172.16.1.2
ip route 192.168.3.0 255.255.255.0 172.16.1.2
On R1, R2 and R3:
ip name-server 192.168.1.1
Don’t disable Host to IP Address Translation to Prevent "Translating..... domain server (255.255.255.255)" Messages. Use:
ip domain lookup (default setting; or ip domain-lookup)
NOTE This command enables the router to translate names into addresses.
From my Huawei Router (ISP Router):
NOTE These two routes are only for R1.
Let’s test the Internet connection from R1:
I don’t know why this happens, you only have to add ping ip … :
Troubleshooting VPN Connection
R1: int virtual-template 1 --> shut/no shut
R2, R3: int tu0 --> shut/no shut
clear crypto isakmp sa
clear crypto sa
NOTE After executing this last command, some minutes later the tunnel will be up again.
NAT Configuration
In a real environment, there will be many hosts requiring Internet access, so:
R1
int lo1
ip nat inside
!
NOTE To correct this error, increase the RAM on all your routers. An easy way to do this is by modifying the topology.net file. Include the line: ram = …
R1
int s0/0
ip nat outside
!
ip nat inside source list NAT-ACL interface s0/0 overload
!
ip access-list extended NAT-ACL
permit ip 192.168.100.0 0.0.0.255 any
NOTE Similar configuration for R2 and R3.
Testing NAT
NAT between VPN neighbors
Finally, because packets between VPN neighbors go through virtual tunnels, no entries will be shown in the output of show ip nat translations:
NOTE: Your e-mail will not be shown in the output. You can use an invalid e-mail, if you want.
Thank you for your co-operation in helping me to improve.