HOWTO: ASR IOS-XE to Fortigate IKEv2 route-based VPN with VTI ( cisco )

In this blog we will look at a static VTI route-based vpn between a cisco ASR and fortigate appliance. This configuration is  the same as the earlier posting on the fortigate side.

The cisco device  has been reconfigured for a Static Virtual Tunnel Interface ( aka cisco routed-based  vpn )

1st the topology

Let's refresh our knowledge of the route-based vpn concept by looking at my earlier post.
http://socpuppet.blogspot.com/2014/05/howto-asr-ios-xe-to-fortigate-ikev2.html

The ASR has been configured with the correct IKEv2  policy, keyring, ipsec-profile and proposals for this vpn to be established. The configuration shown within this post, uses the  concept of a VTI interface and  makes use of a  static route ( aka route-based vpn  )

IKEv2 has been supported within the cisco IOS routers for some time, and actually earlier than the cisco ASA.

NOTE: IKE version2 has been well supported within  Juniper, PaloAlto  and a few other firewall vendors


Here's  the configurations and a few tips



====================   ASR  configuration =====================


We first have to cleanup & remove a few configuration parameters;

•  remove the crypto map from interface
•  delete the crypto-map ( not used in a VTI  scenario )
  
•  delete the  ACL for encryption of the interesting traffic  ( not used in a VTI  scenario ) 

The new configuration encompass a few changes;

•  we define a tunnel interface ( the actual VTI )
•  we install a route to the destination network ( 192.168.254.0/24 ) using the tunnel interface ( the route-based function )
  
•  build a ipsec-protection profile that we apply on the newly crafted tunnel

Okay let's get started. This will be quick and fun !

====================   ASR  configuration =====================
IKEv2

Crypto tranform-set

  ( no changes from earlier post )

Tunnel-creation

  A VTI must have a tunnel  will duh!

ipsec-profile

Static route ( aka route-based )

 

 NOTE:  A routed-based vpn needs  a route to the destination via static or some type of routing protocol


====================   FGT  configuration =====================

NOTHING CHANGES FROM THE EARLIER POST. It's  the exact same cfg.



DIAGNOSTIC comands used

cisco

show crypto ikev2 sa detail
show crypto ipsec sa
ping
show ip route
show int tunnel xxx



Fortigate

diag vpn ike gateway
diag vpn tunnel list
diag debug flow


IKEv2 SA cisco & fortigate

IPSEC-SAs cisco and fortigate

 

NOTICE: how  the SPIs matches for the 2 uni-directional IPSEC-SA

tunnel interface statistics

====================  keyPoints/takeaways  =====================

• The VTI concept allows for more flexibility 
• tunnels are used in the same concept and fashion like a /30 wan link
• dynamic routing could be used across the tunnel interfaces
• due to the VTI  is a virtual interface, we can apply interface specific ACL
• due to the VTI  is a virtual interface, we can apply QoS Specific parameters
• due to the VTI  is a virtual interface, we can use the ifIndex for SNMP monitoring
• specific and unique ipsec profiles can be defined in a multiple VTI hub-spoke
• the need for crypto-map or acl are eliminated
• netflow could be exported for vpn tunnel specific traffic with much ease

Ken Felix
Consulting Engineer Network & Security  ( Cisco, Juniper, Fortinet )

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(   #   # )=

         o

      /     \