One thing to note when going through DMVPN / Legacy or VTY Site-to-Site IPSec VPN profiles, is the IPSec configuration is basically always the same, though it has many variables that can be fine tuned whether its building an IPSec Profile to apply to a Tunnel Interface or building a Crypto Map both require basically identical Phase 1 and Phase 2 information to allow for Authentication and Encryption.
What Virtual Tunnel Interface Site-to-Site VPN has going for it, is that it uses an IPSec Profile configuration that is applied to a Logical Tunnel Interface (like DMVPN), and if you are familiar with GRE Tunnel Configuration from TSHOOT and check out my quick breakdown of creating an “IPSec Profile Recipe” template post for DMVPN that exact template can be used for our IPSec Profiles.
Some quick theory to cover and benefits of VTI to cover first
VTI is just a logical tunnel interface configured for IPSec mode, with an IPSec profile added for Authentication / Encryption, its almost like DMVPN in the way that we are simply creating Tunnel Interfaces and IPSec Profiles to configure VTI VPN.
Some benefits over Legacy site-to-site VPN:
- Simplified Configuration
- Extremely and EASILY Scalable to accommodate VPN Peers
- Supports Multicast traffic – No GRE encapsulation necessary!
- Interface features – It has about the same capability to be configured as a Physical Routed interface, including participating in IGPs, ETC
- No Crypto Maps to define traffic – All traffic is encrypted between End Points
To get around #5 if you require traffic not take a site to site VPN, is using static routing to send that traffic out to your ISP Gateway, this takes care of having to go around to several sites and rebuild Crypto Maps / NATs that go with them – And that itself is huge.
Lets walk through the configuration full on the R3 side of the VPN Tunnel
I will create the IPSec profile here first, and I honestly just recycled the IPSec Profile config from my IPSec Profile for DMVPN post here, so feel free to check that out for additional info on configuration or how to secure a DMVPN Tunnel.
This is literally just a copy / paste from a notepad template with an adjusted IP:
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#crypto isakmp policy 1
R3(config)#crypto isakmp key LoopedBack!!! address 10.1.1.1
R3(config)#crypto ipsec transform-set CCIE esp-aes esp-sha-hmac
R3(config)#crypto ipsec profile ProtectTheTunnel
R3(ipsec-profile)#set transform-set CCIE
I leave a lot of stuff as default values when labbing, if your ever curious of crypto policy details, a good command to know is shown here:
“sh crypto isakmp profile”
If there were multiple policies, you could see them all here, as well as in the “sh run | b crypto” however this will show defaults whereas the running config will not.
So good command to keep in mind for troubleshooting!
Next up is Tunnel Interface Configuration for the VTI Interface
*Dec 7 09:27:13.991: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R3(config-if)#ip unnumbered ?
ACR Virtual ACR interface
ATM-ACR ATM interface with ACR
Analysis-Module cisco network analysis service module
Async Async interface
Auto-Template Auto-Template interface
BVI Bridge-Group Virtual Interface
CDMA-Ix CDMA Ix interface
CEM-ACR Circuit Emulation interface with ACR
CTunnel CTunnel interface
Container Container interface
Dialer Dialer interface
EsconPhy ESCON interface
FastEthernet FastEthernet IEEE 802.3
Fcpa Fiber Channel
Filter Filter interface
Filtergroup Filter Group interface
GMPLS MPLS interface
IMA-ACR IMA interface with ACR
LISP Locator/ID Separation Protocol Virtual Interface
LongReachEthernet Long-Reach Ethernet interface
Loopback Loopback interface
Lspvif LSP virtual interface
R3(config-if)#ip unnumbered fa1/0
R3(config-if)#tunnel source fa1/0
R3(config-if)#tunnel dest 10.1.1.1
*Dec 7 09:28:20.935: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
If you are anything like me, you saw this configuration during Tunnel config and said what in the world is THAT:
R3(config-if)#ip unnumbered fa1/0
^^^ Make sure the selected interface is your WAN / VPN endpoint interface!
It MUST be your WAN connection as it will “borrow” the IP Address of the WAN to use on its Logical Tunnel interface without disrupting the WAN Interfaces operation (having a duplicate IP), as the Router does not detect this Duplicate IP because it is not manually assigned on the Tunnel!
“ip unnumbered” is NOT REQUIRED for Static 1:1 VPN Tunnels, it is a very good idea, but it IS REQUIRED for Dynamic VTI Tunnel Creation which will be discussed towards the bottom of this post in conclusion of this subject.
I have added the IPSec Profile / Tunnel config to R1, time to apply the IPSec Profiles!
I’ll skip the output of R1 configuration, and get right to where the rubber meets the road, of getting this VPN Tunnel up and passing IPSec encrypted traffic:
There are actually two commands needed on the tunnel
R3(config-if)#tunnel mode ipsec ipv4
*Dec 7 09:40:03.923: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
*Dec 7 09:40:03.955: %OSPF-5-ADJCHG: Process 1, Nbr 126.96.36.199 on Tunnel0 from FULL to DOWN, Neighbor Down: Interface down or detached
R3(config-if)#tunnel protection ipsec profile ProtectTheTunnel
*Dec 7 09:40:09.959: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
First we need to change this from the default GRE Tunnel Interface type to an IPv4 IPSec Tunnel BEFORE applying the IPSec Profile, then apply the IPSec Profile to the Tunnel.
Back over on R1 finishing the config
R1(config-if)#tunnel mode ipsec ipv4
R1(config-if)#tunnel protection ipsec profile ProtectTheTunnel
*Dec 7 09:40:51.207: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
*Dec 7 09:40:52.563: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
*Dec 7 09:40:52.975: %OSPF-5-ADJCHG: Process 1, Nbr 188.8.131.52 on Tunnel0 from LOADING to FULL, Loading Done
The Tunnel appears to come up Successfully on this side, and its time for testing!
R1#sh cry isa sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
10.2.2.3 10.1.1.1 QM_IDLE 1001 ACTIVE
IPv6 Crypto ISAKMP SA
Note the “ip unnumbered fa0/0” command is at work here borring the same IP Address assigned to the WAN interfaces, we would use these IP Interfaces ANYWAYS for a Legacy Tunnel to send IPSec traffic to, this just does it dynamically for Point-to-Point links to save space (for example if you only have a /30 ISP subnet and can’t spare another IP).
R1#sh cry ipsec sa
Crypto map tag: Tunnel0-head-0, local addr 10.1.1.1
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 10.2.2.3 port 500
#pkts encaps: 23, #pkts encrypt: 23, #pkts digest: 23
#pkts decaps: 22, #pkts decrypt: 22, #pkts verify: 22
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
As can be seen here the local / remote ident is 0.0.0.0 because ANY traffic is being identified as allowed to traverse this tunnel, encap and decaps look good!
Describing what Dynamic VTI Site-to-SIte VPN Tunnels are, and how they work
This type of configuration would be for a Hub and Spoke Topology, it really reminds me of DMPVN-lite, where a Hub Dynamically creates Tunnel interfaces to static spokes.
When one of these Static Neighbors hits the Hub, it “Dynamically” createa a tunnel interface use a virtual-template as shown in the graphic, where it will pull the information listed (ip unnumbered int) / (tunnel mode) / (protection profile) from the existing configuration, and dynamically build a new Tunnel using that template for the new VTI Participant.
Of course for this to work, these Spoke Routers, must of course have a matching IPSec configuration already configured, as the Hub definitely isn’t going to send these templates down to potential Peers (strangers) with all our IPSec configurations.
I honestly have never seen this before in real world networks, its either a few static Legacy Site-to-Site VPN Tunnels or its DMVPN, as though this seems to maybe be a one up on “Legacy” Site-to-Site IPSec VPN its still not as efficient as DMVPN for Dynamic VPNs.
This wraps up Layer 3 VPN for right now all together that I am aware of!
Time to jump back into MPLS to finish off Layer 2 topics such as VPLS, AToM, Etc.