Earlier I discussed how to use a VTI rather than a standard crypto map for tunneling traffic. The VTI also has the advantages of using a smaller header than a GRE tunnel (which has its advantages and disadvantages). In my previous example, I used a static route in order to send the traffic through the tunnel. Static routes, while quick and easy, are not very scalable. Various routing protocols can be used in order to get traffic to go through a VTI, such as RIP, OSPF, EIGRP, etc. More importantly, these protocols can make use of MD5 authentication to prevent man-in-the-middle style attacks.
First, a diagram of our VTI tunnel:
We are using RIP v2 as a protocol to pass the fa0/0 networks and the loopback0 networks. R1 is able to ping loopback0 on R2 with the R1 loopback0 as the source. The loopback1 networks are not being forwarded through RIP. EIGRP is going to be used with a VTI to send traffic for those two endpoints.
First things first: The VTI needs to be configured on both sides. Here are the basic configurations:
R1:
crypto isakmp policy 10 encr aes authentication pre-share group 2 crypto isakmp key cisco address 10.10.20.2 ! ! crypto ipsec transform-set STRONG esp-aes esp-sha-hmac ! crypto ipsec profile VPN set transform-set STRONG ! interface Tunnel0 ip address 172.16.0.1 255.255.255.252 tunnel source FastEthernet0/0 tunnel destination 10.10.20.2 tunnel mode ipsec ipv4 tunnel protection ipsec profile VPN
R2:
crypto isakmp policy 10 encr aes authentication pre-share group 2 crypto isakmp key cisco address 10.10.10.1 ! ! crypto ipsec transform-set STRONG esp-aes esp-sha-hmac ! crypto ipsec profile VPN set transform-set STRONG ! interface Tunnel0 ip address 172.16.0.1 255.255.255.252 ip authentication mode eigrp 90 md5 ip authentication key-chain eigrp 90 RIP tunnel source FastEthernet0/0 tunnel destination 10.10.20.2 tunnel mode ipsec ipv4 tunnel protection ipsec profile VPN
While the tunnels have been built, no traffic is going through. Without either a dynamic routing protocol or a static route, this is just a pretty tunnel. Now traffic needs to go through the tunnel. EIGRP will be used:
R1:
router eigrp 90 passive-interface default no passive-interface Tunnel0 network 172.16.0.0 0.0.0.3 network 192.168.11.0 no auto-summary
R2:
router eigrp 90 passive-interface default no passive-interface Tunnel0 network 172.16.0.0 0.0.0.3 network 192.168.21.0 no auto-summary
A couple of notes here. The passive-interface default makes ALL interfaces on EIGRP 90 passive. A passive interface does not send out updates. By using the default and then adding the Tunnel0 interface, EIGRP traffic is now limited to being advertised only over the Tunnel0 interface. The no auto-summary is needed to prevent summarization of the networks.
Our VTI, however, it not going to come up without a couple of changes to the firewall. ACLs need to be added to the firewall to allow UDP 500 (isakmp) and ESP in order for everything to connect. Add the following to the ASA:
access-list outside extended permit icmp any any access-list outside extended permit esp any any access-list outside extended permit udp any any eq isakmp access-group outside in interface outside
The tunnel should be up, and the routes should be added. On R1, the following output is seen:
R1#sh 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 172.16.0.0/30 is subnetted, 1 subnets C 172.16.0.0 is directly connected, Tunnel0 192.168.11.0/32 is subnetted, 1 subnets C 192.168.11.1 is directly connected, Loopback1 D 192.168.21.0/24 [90/297372416] via 172.16.0.2, 01:05:50, Tunnel0 10.0.0.0/24 is subnetted, 2 subnets C 10.10.10.0 is directly connected, FastEthernet0/0 R 10.10.20.0 [120/1] via 10.10.10.254, 00:00:03, FastEthernet0/0 192.168.1.0/32 is subnetted, 1 subnets C 192.168.1.1 is directly connected, Loopback0 R 192.168.2.0/24 [120/2] via 10.10.10.254, 00:00:03, FastEthernet0/0
Cool! The routes are going through for both RIP and EIGRP. The R shows RIP routes, and the D shows EIGRP routes. With this up, the ISAKMP and IPSec SAs should show up as well:
R1#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
10.10.10.1 10.10.20.2 QM_IDLE 1004 0 ACTIVE
R1#sh crypto ipsec sa
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 10.10.10.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.10.20.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 934, #pkts encrypt: 934, #pkts digest: 934
#pkts decaps: 943, #pkts decrypt: 943, #pkts verify: 943
#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
local crypto endpt.: 10.10.10.1, remote crypto endpt.: 10.10.20.2
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0x8CD9D885(2363086981)
inbound esp sas:
spi: 0xB49A225C(3030000220)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 17, flow_id: SW:17, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4434634/2753)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x8CD9D885(2363086981)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 18, flow_id: SW:18, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4434634/2753)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
The VTI is working, phase I and phase II are complete, and the routes show up in the routing table. Now that the VTI is working, MD5 authentication can be added to EIGRP. Authentication can be done in plain text, but given that this is the CCIE:Security exam, MD5 would be a better choice. The following steps are needed to add authentication to EIGRP:
- Create a key chain with a key string.
- Add authentication to the interface.
- Use MD5 as the mode of authentication on the interface.
First, the creation of the key chain. RIP is already using a key chain, so that key chain will also be used for EIGRP:
R1:
key chain RIP key 1 key-string cisco
R2:
key chain RIP key 1 key-string cisco
The same key number should be used on both sides. For RIP, authentication was added to the fa0/0 interface. Because EIGRP is using the Tunnel0 interface, the EIGRP authentication lines should be added to that interface instead:
R1:
interface Tunnel0
ip address 172.16.0.1 255.255.255.252
ip authentication mode eigrp 90 md5
ip authentication key-chain eigrp 90 RIP
tunnel source FastEthernet0/0
tunnel destination 10.10.20.2
tunnel mode ipsec ipv4
tunnel protection ipsec profile VPN
R2:
interface Tunnel0
ip address 172.16.0.2 255.255.255.252
ip authentication mode eigrp 90 md5
ip authentication key-chain eigrp 90 RIP
tunnel source FastEthernet0/0
tunnel destination 10.10.10.1
tunnel mode ipsec ipv4
tunnel protection ipsec profile VPN
Note the highlighted lines. These lines were added to allow EIGRP to use MD5 authentication. To verify that MD5 is indeed being used for authentication, the interface detail should reveal this:
R1#sh ip eigrp 90 interface detail
IP-EIGRP interfaces for process 90
Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
Tu0 1 0/0 229 71/2702 3654 0
Hello interval is 5 sec
Next xmit serial <none>
Un/reliable mcasts: 0/0 Un/reliable ucasts: 1/26
Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 9
Retransmissions sent: 13 Out-of-sequence rcvd: 1
Authentication mode is md5, key-chain is "RIP"
Use unicast
Indeed, the authentication mode is MD5, and the key-chain is RIP.
A final note: The VTI tunnel is sending the traffic for EIGRP. Because this traffic is going through a tunnel, there is no need to change the ASA to allow EIGRP traffic through it. If this was not a tunnel, then the ASA would need the following line added to the ACL:
access-list outside permit eigrp any any
Remember, EIGRP is its own protocol. This is not using TCP or UDP to pass traffic.
Good luck!
