Skip to main content

DMVPN - phase four (IKEv2/FlexVPN)

When Cisco introduced the new IKE (IKEv2) and the new unified configuration for all types of VPN (excluding GET VPN), they also updated the DMVPN. The new version (phase 4 - but I’m not sure if it is official name) spoke-to-spoke has changed many things. There is no more point-to-multipoint tunnels. For spoke-to-hub connection you have to configure a tunnel interface (for each hub in case you have more than one) on your spoke routers. For spoke-to-spoke communication you need to create a virtual-template and every time the new connection will be built, based on this template, the new, dynamic interface will be created.




 


In my configuration I will use as much default settings as it is possible. Let’s start with the hub configuration.
I enable following ikev2 settings on all routers (hub and spoke):

default crypto ikev2 proposal
default crypto ikev2 policy
default crypto ipsec transform-set
default crypto ipsec profile

EIGRP:

router eigrp 100
 no auto-suma
 network 10.0.0.0 0.0.0.255
 network 100.0.0.0 0.255.255.255
 passive-interface default
 no passive-interface Virtual-Template1
 no passive-interface Tun0

Next I configure a keyring:
 
crypto ikev2 keyring KEYRING
 peer R1
  identity address 0.0.0.0
  address 0.0.0.0 0.0.0.0
  pre-shared-key local cisco123
  pre-shared-key remote cisco123

I need a virtual-template for spoke-to-hub connections:
 
interface Virtual-Template1 type tunnel
 ip unnumbered Loopback10
 ip nhrp network-id 100
 ip nhrp redirect
 tunnel source FastEthernet0/0
 tunnel protection ipsec profile default

Then I create a new ikev2 profile:
 
crypto ikev2 profile IKEV2-PROFILE
 match identity remote address 0.0.0.0
 authentication remote pre-share
 authentication local pre-share
 keyring local KEYRING
 virtual-template 1

I think the hub is ready. Let’s configure spokes.

I start to configure a keyring:
 
crypto ikev2 keyring KEYRING
 peer R2
  identity address 0.0.0.0
  address 0.0.0.0 0.0.0.0
  pre-shared-key local cisco123
  pre-shared-key remote cisco123

Next I need to create interfaces:

A loopback0 - only for source interface for a tunnel and 
 
interface Loopback10
 ip address 22.22.22.22 255.255.255.255

The tunnel for hub-to-spoke connection:
 
interface Tunnel0
 ip address negotiated
 ip nhrp network-id 100
 ip nhrp shortcut virtual-template 1
 tunnel source FastEthernet0/0
 tunnel destination 5.5.5.1
 tunnel protection ipsec profile default

and then the virtual-interface for spoke-to-spoke:
 
interface Virtual-Template1 type tunnel
 ip unnumbered Loopback10
 ip nhrp network-id 100
 ip nhrp shortcut virtual-template 1
 tunnel source FastEthernet0/0
 tunnel protection ipsec profile default

and last step - creating the new ikev2 profile:
 
crypto ikev2 profile IKEV2-PROFILE
 match identity remote address 0.0.0.0
 authentication remote pre-share
 authentication local pre-share
 keyring local KEYRING
 virtual-template 1

I repeat the same steps on my spoke ‘2’.

Working on GNS3 I found one problem with 'redirection’. The software I’m working with, for 7200, doesn’t support IKEv2 or 'nhrp redirect’:

SPOKE1:
 
r2(config-if)#ip nhrp shortcut virtual-template 1
r2(config-if)#
*Jan  5 02:37:36.263: NHRP:
*Jan  5 02:37:36.263:  Instructing NHRP to create Virtual-Access from Virtual template 1 for interface Tunnel0
r2(config-if)#

HUB (Version 15.2(4)S6):
 
r1(config-if)#ip nhrp redirect
% NHRP-WARNING: 'ip nhrp redirect' failed to initialise
r1(config-if)#
*Jan  5 02:56:44.495: NHRP: Redirect Feature Initialized - Attempting Platform Init
r1(config-if)#
I tested a version 15.2(3)T3 (on the physical device) and it worked fine:
r1(config-if)#
*Jan  5 02:45:42.255: NHRP: Redirect Feature Initialized - Attempting Platform Init
*Jan  5 02:45:42.255: NHRP: Enabled NHRP Redirect Feature in Feature-Path
r1(config-if)#

Once I will have an access to routers with the new IOS I will update the post with the 'redirection’ feature. The rest of functionality works fine. Spokes (via tun0) can set up connection with their hub (via Virtual-Access interface):

r1#sh ip int b
Interface              IP-Address      OK? Method Status                Protocol
FastEthernet0/0        5.5.5.1         YES NVRAM  up                    up
FastEthernet0/1        unassigned      YES NVRAM  administratively down down
FastEthernet1/0        unassigned      YES NVRAM  administratively down down
FastEthernet1/1        unassigned      YES NVRAM  administratively down down
Loopback0              100.11.11.11    YES NVRAM  up                    up
Loopback10             10.0.0.1        YES NVRAM  up                    up
Virtual-Access1        10.0.0.1        YES unset  up                    up
Virtual-Access2        10.0.0.1        YES unset  up                    up
Virtual-Template1      10.0.0.1        YES unset  up                    down
r1#

The first virtual interface - Virtual-Access1 - has been created for the spoke1 (6.6.6.1):
 
r1#sh int Virtual-Access 1
Virtual-Access1 is up, line protocol is up
  Hardware is Virtual Access interface
  Interface is unnumbered. Using address of Loopback10 (10.0.0.1)
  MTU 17874 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL
  Tunnel vaccess, cloned from Virtual-Template1
  Vaccess status 0x0, loopback not set
  Keepalive not set
  Tunnel source 5.5.5.1 (FastEthernet0/0), destination 6.6.6.1
   Tunnel Subblocks:
      src-track:
         Virtual-Access1 source tracking subblock associated with FastEthernet0/0
          Set of tunnels with source FastEthernet0/0, 3 members (includes iterators), on interface <OK>
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled
  Tunnel TTL 255, Fast tunneling enabled
  Tunnel transport MTU 1434 bytes
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Tunnel protection via IPSec (profile "default")
  Last input 00:00:03, output never, output hang never
  Last clearing of "show interface" counters 00:00:49
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     17 packets input, 1534 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     18 packets output, 1578 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
r1#

the second (Virtual-Access2) for the spoke2:
 
r1#sh int Virtual-Access 2
Virtual-Access2 is up, line protocol is up
  Hardware is Virtual Access interface
  Interface is unnumbered. Using address of Loopback10 (10.0.0.1)
  MTU 17874 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL
  Tunnel vaccess, cloned from Virtual-Template1
  Vaccess status 0x0, loopback not set
  Keepalive not set
  Tunnel source 5.5.5.1 (FastEthernet0/0), destination 7.7.7.1
   Tunnel Subblocks:
      src-track:
         Virtual-Access2 source tracking subblock associated with FastEthernet0/0
          Set of tunnels with source FastEthernet0/0, 3 members (includes iterators), on interface <OK>
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled
  Tunnel TTL 255, Fast tunneling enabled
  Tunnel transport MTU 1434 bytes
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Tunnel protection via IPSec (profile "default")
  Last input 00:00:00, output never, output hang never
  Last clearing of "show interface" counters 00:02:42
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     40 packets input, 3506 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     41 packets output, 3550 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
r1#

Without the 'redirection’ the traffic is sent like with phase 1:
 
r2#traceroute 100.33.33.33 source 100.22.22.22
Type escape sequence to abort.
Tracing the route to 100.33.33.33
VRF info: (vrf in name/id, vrf out name/id)
  1 10.0.0.1 92 msec 76 msec 128 msec
  2 10.0.0.3 140 msec 128 msec 128 msec
r2#traceroute 100.33.33.33 source 100.22.22.22
Type escape sequence to abort.
Tracing the route to 100.33.33.33
VRF info: (vrf in name/id, vrf out name/id)
  1 10.0.0.1 92 msec 88 msec 104 msec
  2 10.0.0.3 128 msec 148 msec 124 msec
r2#
Labels:

Comments

Post a Comment

Popular posts from this blog

What should you know about HA 'override enabled' setting on Fortigate?

High availability is mandatory in most of today's network designs. Only very small companies or branches can run their business without redundancy. When you have Fortigate firewall in your network you have many options to increase network availability. You can use Fortigate Clustering Protocol ( FGCP ) or Virtual Router Redundancy Protocol ( VRRP ). FGCP has two modes: 'override' disabled (default) and 'override' enabled . I'm not going to explain how to set up HA as you can find many resources on Fortinet websites: https://cookbook.fortinet.com/high-availability-two-fortigates-56/ https://cookbook.fortinet.com/high-availability-with-fgcp-56/ Let's recap what is the main difference between them. The default HA setting is 'override' disabled and this is an order of selection an active unit: 1) number of monitored interfaces - when both units have the same number of working (up) interfaces check next parameter 2) HA uptime - an ...
8 comments
Read more

FortiGate and GRE tunnel

Recently I worked on one project where a client requested to re-route web traffic to the GRE tunnel to perform traffic inspection. I would like to share with you what is required if you configure it on FortiGate. We need a new GRE interface and policy base routing (PBR) to change the route for specific source IPs. Of course you need firewall policies to permit the traffic. Let's start with GRE interface. Unfortunately you can't configure it using the GUI, only CLI is the option: config system gre-tunnel edit "gre1" set interface "port1" set local-gw 55.55.55.55 set remote-gw 44.44.44.44 next end When the end peer is Cisco router, you need to set the IP for the GRE interface: config system interface edit gre1 set ip 192.168.10.10 255.255.255.255 set remote-ip192.168.10.20 end In next step we need to fix routing. We need the alternate path via GRE but to keep the route in the active routing table you need to set the same AD (adminis...
Post a Comment
Read more

Inpection of asymmetric sessions on FortiGate

There is one feature available on FortiGate, and I think you should know it, as it modifies a bit what we know about stateful firewalls. In past every packet was treated individually and you had to create policies in both directions. With stateful firewalls we can track connections, and by checking couple of attributes, we can treat them as part of the same session. For example when you initiate connection from a host1 to host2, the returning connection from host2 to host1 will be treated as part of the same connection (session). They have to have the same source/destination and destination/source IPs, port numbers and interfaces.There is an exception from this rule and FortiGate in some specific cases can accept connections on port which was not used in the initial connection. Let me explain how it works on the below example:      The host1 has a default gateway on R1 (10.0.1.2), but you may notice that it is not the optimal path to host2 subnet. When we analyze ...
1 comment
Read more