Cisco IOS - IPsec Solutions
A series of articles will cover solutions using the following major implementation options with Cisco IOS routers:
Static and Dynamic Crypto Maps
Point-to-point GRE Tunnels over IPsec
Static and Dynamic Virtual Tunnel Interfaces (VTIs)
Dynamic Multipoint VPNs (DMVPNs)
Group Encrypted Transport VPN (GET VPN)
Multipoint GRE Tunnels over GET VPN
This article focuses on the third solution in the list.
Static and Dynamic Virtual Tunnel Interfaces (VTIs)
In the first two articles about ways to build site-to-site VPNs using IPsec, we examined the oldest method, using crypto maps, and the same method augmented by GRE tunnels in order to introduce logical interfaces that can be used to enable routing protocols across the tunnel (as an example of one benefit). Virtual tunnel interfaces (VTIs) are a relatively late addition in which there is no need for additional GRE overhead, while still gaining that logical interface that was often missing when deploying IPsec using crypto maps alone.
There are two flavors of VTIs:
Static VTI is very similar to point-to-point GRE implementation using tunnel interfaces.
Dynamic VTI is very similar to dial-in implementation using virtual templates, from which individual virtual-access interfaces are spawned.
Though this article focuses on implementation options for site-to-site VPNs, today we may resort to using what would normally be considered a remote-access method for implementing site-to-site VPNs. Dynamic VTIs are an example of a typical remote-access implementation tool, where IKE sessions are accepted dynamically and not initiated. In large S2S deployments, we may consider using this tool to simplify management and having remote sites ensure that the tunnels are always up, thus making this a site-to-site and not really a remote-access VPN.
When building a VPN, we first need to distinguish between a central site and remote sites, as they may use different implementation methods. The following table lists the supported combinations where at least one side is using VTIs:
| Central Site | Remote Site |
| Static VTI | Static VTI |
| Dynamic VTI | Static VTI |
| Dynamic VTI | Static crypto map |
| Dynamic VTI | Easy VPN remote (+ optional dynamic VTI) |
Using Static VTIs in the Central and Remote Sites
Let’s first take a look at the seemingly simplest option, in which we use static VTIs on both ends of the tunnel. This implementation is practically identical to that of point-to-point GRE tunnels over IPsec with the use of protection profiles. The only difference is in the tunnel mode configuration.
Listing 1
Example: Static VTIs at both ends
!
crypto isakmp key mtt3rvLBO3jCoV50zoE address 192.168.1.2
!
crypto isakmp policy 10
encr 3des
authentication pre-share
hash sha
!
crypto ipsec transform-set TS esp-des esp-sha-hmac
!
crypto ipsec profile IPsecP
set transform-set TS
!
interface Serial0
ip address 192.168.1.1 255.255.255.252
!
interface Tunnel0
ip address 10.1.1.1 255.255.255.252
ip mtu 1300
tunnel source Serial0
tunnel destination 192.168.2.1
tunnel protection ipsec profile IP
tunnel mode ipsec ipv4
!
ip route 0.0.0.0 0.0.0.0 Serial0
ip route 10.0.0.0 255.0.0.0 Tunnel0
!
From a technical perspective, this solution has the same benefits and drawbacks as the implementation using GRE. The main difference is that VTIs only support IP (unicast and multicast), while GRE also supports other protocols. VTIs also were not available on all platforms when they were first introduced.
Using Static and Dynamic VTIs in the Central and Remote Sites
Static configuration of tunnels requires a large number of tunnel interfaces to be statically defined at the head-end, along with other static parameters such as IKE pre-shared keys (if used). Replacing individual static VTIs with a dynamic VTI simplifies the configuration in the central site. The downside is that the central site cannot initiate the tunnel, so it must be ensured that the remote site doesn’t just initiate the tunnel but also makes sure that it is constantly up.
By combining static VTIs and dynamic VTIs, we automatically get the required functionality – static VTIs automatically establish an IPsec tunnel and reestablish it if it drops, for whatever reason.
Listing 2
Example: Dynamic VTIs
!
crypto keyring WPSK
pre-shared-key address 0.0.0.0 0.0.0.0 key rvH0cnVLUGe8naVY
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
!
crypto isakmp profile DVTI
keyring WPSK
match identity address 0.0.0.0
virtual-template 1
!
crypto ipsec transform-set TS esp-3des esp-sha-hmac
!
crypto ipsec profile VTI
set transform-set TS
!
interface Virtual-Template1 type tunnel
ip unnumbered Loopback0
tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI
!
Remote sites are configured using static VTIs. Unnumbered addressing should be configured to match the unnumbered configuration on the central site. A routing protocol can be configured to exchange the routing information across the tunnel.
Listing 3
Example: Static VTIs for central dynamic VTIs
!
crypto keyring WPSK
pre-shared-key address 0.0.0.0 0.0.0.0 key rvH0cnVLUGe8naVY
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
!
crypto ipsec transform-set TS esp-3des esp-sha-hmac
!
crypto ipsec profile VTI
set transform-set TS
!
interface Tunnel0
ip unnumbered Loopback0
tunnel source FastEthernet0/0
tunnel destination 192.168.1.1
tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI
!
Each established remote tunnel will get its own virtual-access interface spawned from the virtual template on the central site.
Listing 4
Example: Monitoring Dynamic VTIs for remote static VTIs
!
R1# show ip interface brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 192.168.1.1 YES NVRAM up up
FastEthernet0/1 unassigned YES NVRAM administratively down down
SSLVPN-VIF0 unassigned NO unset up up
Virtual-Access1 unassigned YES unset down down
Virtual-Template1 10.1.1.1 YES TFTP down down
Virtual-Access2 10.1.1.1 YES TFTP up up
Virtual-Access3 10.1.1.1 YES TFTP up up
Loopback0 10.1.1.1 YES NVRAM up up
Loopback1 10.100.1.1 YES manual up up
R1# show crypto ipsec sa
interface: Virtual-Access3
Crypto map tag: Virtual-Access3-head-0, local addr 192.168.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 192.168.1.3 port 500
PERMIT, flags={origin_is_acl,}
…
The ability to use a routing protocol (i.e., multicast) is the major advantage, compared to a combination of static and dynamic crypto maps, where the traffic that needs encryption is identified using an access list on the remote router.
On the other hand, special care must be taken (just like with P2P GRE tunnels) not to create a routing-lookup failure situation in which the tunnel endpoint addresses would be propagated through the VPN link (see the previous article about S2S VPNs for proper addressing and routing).
Using Static Crypto Maps in Combination with Dynamic VTIs
Dynamic VTIs can also mimic the functionality of dynamic crypto maps. A central site can be reconfigured to use dynamic VTIs while retaining existing IPsec tunnels from remote sites using static crypto maps. Functionality like that of reverse route injection (RRI) is automatic with dynamic VTIs, whereby a static route is created automatically for each remote network negotiated via IKE.
Listing 5
Example: Monitoring Dynamic VTIs for remote static crypto maps
!
R1# show crypto ipsec sa
interface: Virtual-Access2
Crypto map tag: Virtual-Access2-head-0, local addr 192.168.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): (10.100.2.0/255.255.255.0/0/0)
current_peer 192.168.1.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
…
R1# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0 255.0.0.0 is variably subnetted, 6 subnets, 3 masks
C 10.1.1.0 255.255.255.0 is directly connected, Loopback0
S 10.0.0.0 255.0.0.0 [1/0] via 10.1.1.2
S 10.100.2.0 255.255.255.0 [1/0] via 192.168.1.2, Virtual-Access2
C 10.100.1.0 255.255.255.0 is directly connected, Loopback1
C 192.168.1.0 255.255.255.0 is directly connected, FastEthernet0/0
R1#
Using Easy VPN Remote and Dynamic VTIs
To go even deeper into the remote-access technology, we can employ the Easy VPN remote and server functionality to implement a site-to-site VPN.
The Easy VPN feature has the following main characteristics:
Centralized configuration of many remote parameters.
Simplified configuration of the remote site.
In essence, the term “Easy VPN” is used for the functionality of the Cisco VPN client that was ported into Cisco IOS and required minimum configuration:
Peer address
Credentials (group name and key)
Mode of operation (client, network, network plus)
Inside interface (network)
All other parameters are either available by default (e.g., a set of IKE policies, a set of IPsec transforms) or are dynamically pushed down or negotiated from the Easy VPN server during the IKE mode config phase (e.g., IP address, domain name, DNS servers).
Listing 6
Example: Easy VPN Remote
!
crypto ipsec client ezvpn GRP1
peer 192.168.1.1
group GRP1 key ZRaAJvQj6P845dsw
mode network
!
interface FastEthernet0/0
description Internet link
crypto ipsec client ezvpn GRP1
!
interface FastEthernet1/0
description LAN
crypto ipsec client ezvpn GRP1 inside
!
The example above illustrates the usage of network-extension–mode Easy VPN, which ensures that the tunnel is always up and that the network behind the remote router is also accessible through the tunnel from the central site, thus implementing a basic site-to-site VPN.
Note The example above uses group pre-shared keys, which are vulnerable to man-in-the-middle attacks. It is recommended that you use digital-signature authentication instead.
Listing 7
Example: Easy VPN Server
!
crypto isakmp client configuration group GRP1
key ZRaAJvQj6P845dsw
dns 10.1.1.10 10.1.1.20
domain nil.com
pool POOL
!
ip local pool dynpool 10.200.1.1 10.200.1.100
!
The partial configuration above illustrates the central configuration of IP parameters for remote sites. This configuration can also be stored on a AAA server such as Cisco Secure ACS, in case a number of central servers are required to share the load and provide high availability.
Because Easy VPN suffers from the same deficiency as crypto maps, namely the lack of a routable interface, dynamic VTIs can be used on the remote site in combination with Easy VPN to support routing and quality of service.
Listing 8
Example: Easy VPN Remote with dynamic VTIs
!
crypto ipsec client ezvpn GRP1
peer 192.168.1.1
group GRP1 key ZRaAJvQj6P845dsw
mode network
virtual-interface 1
!
interface Virtual-Template1 type tunnel
no ip address
tunnel mode ipsec ipv4
service-policy output SLA
!
interface FastEthernet0/0
description Internet link
crypto ipsec client ezvpn GRP1
!
interface FastEthernet1/0
description LAN
crypto ipsec client ezvpn GRP1 inside
!
Summary
The main advantages of using static and/or dynamic VTIs include the following:
Support for IP multicast
Support for routing protocols to simplify dynamic routing and high availability
Improved manageability through the use of a single virtual-template interface for a number of remote sites
Ability to use per-site QoS (e.g., marking, rate limiting)
Flexibility of allowing dynamic VTIs to be combined with static crypto maps, static VTIs, and Easy VPN, with the option to use dynamic VTIs on the remote end as well
The main challenges of using VTIs include the following:
Slightly more difficult troubleshooting (e.g., dynamic virtual-access interfaces without descriptions or the ability to encode site ID into the interface’s number, inability to ping VPN links due to the use of unnumbered interfaces)
Subsequent articles will address these issues by using other IPsec implementation methods.
Nessun commento:
Posta un commento