Archives for posts with tag: Loopback

Dynamic Virtual Tunnel Interface.

It’s a similar concept to DMVPN but with a few differences

  • dVTI requires a smaller packet header only 4 bytes compared to DMVPN which is an additional 28 bytes
  • dVTI does not  use NHRP
  • dVTI has backwards compatibility with IPsec direct encapsulation
  • dVTI requires IP unumbered
  • dVTI requires the use of a dynamic routing protocol instead of keepalives
  • dVTI must be initiated by the remote branch to the head-end

I personally like the fact that the interface is unnumbered as it reduces the amount of IP address space that you need to manage. Each virtual template can be configured with different characteristics on the head-end device so that common branch offices share the same settings. This type of solution is ideal for a hub and spoke design.

I’m not saying dVTI is better or worse than DMVPN it’s just different.

The spoke forms an EIGRP neighbor with the HUB, you can then advertise a default route to the spoke. If you want to apply policies like QoS you can do this directly on the template interface.  The spoke will advertise the LAN network to the Hub and you can then summarise at the Hub into the data centre for multiple spokes.

Here is the configuration with a front VRF, this was tested in the lab on live equipment.

Hub Configuration

vrf definition internet
 rd 1:1
 address-family ipv4
 
 crypto keyring KEYRING vrf internet 
  pre-shared-key address [IP ADDRESS of SPOKE or match all] key cisco
 
 crypto isakmp policy 10
  encr aes
  hash sha256
  authentication pre-share
  group 14

crypto isakmp profile ISAKMPPROFILE
  keyring KEYRING
  match identity address [IP ADDRESS of SPOKE or match all] internet
  virtual-template 1

crypto ipsec transform-set TSET_SECURE esp-aes esp-sha256-hmac

interface Loopback0
  ip address 172.16.255.1 255.255.255.255
 
 interface gig0/0
  vrf forwarding internet
  description outside_interface
  ip address [WAN Interface IP and Subnet Mask] 
  no ip redirects
  no ip unreachables
  no ip proxy-arp

interface gig0/1
  description inside_interface
  ip address 192.168.255.50 255.255.255.0
  

interface Virtual-Template1 type tunnel
  ip unnumbered Loopback0
  ip mtu 1408
  ip summary-address eigrp 1 0.0.0.0 0.0.0.0
  tunnel mode ipsec ipv4
  tunnel vrf internet
  tunnel protection ipsec profile IPSECPROFILE_SECURE

router eigrp 1
  network 172.16.255.1 0.0.0.0

ip route vrf internet 0.0.0.0 0.0.0.0 [next-hop to internet]

Spoke Configuration

vrf definition internet
 rd 1:1
  address-family ipv4

crypto keyring 1 vrf internet 
  pre-shared-key address [IP address of HUB] cisco

crypto isakmp policy 10
  encr aes
  hash sha256
  authentication pre-share
  group 14

crypto ipsec transform-set TSET_SECURE esp-aes esp-sha256-hmac

crypto ipsec profile IPSECPROFILE_SECURE
  set transform-set TSET_SECURE

interface Loopback0
 ip address 172.16.255.2 255.255.255.255
 
 interface Tunnel0
  ip unnumbered Loopback0
  ip mtu 1408
  tunnel source gig0/1
  tunnel mode ipsec ipv4
  tunnel destination [IP address of HUB]
  tunnel vrf internet
  tunnel protection ipsec profile IPSECPROFILE_SECURE

interface gig0/1
  description outside_interface
  vrf forwarding internet
  ip address [WAN Interface IP and Subnet Mask or DHCP]

interface vlan 1 
  description inside_interface
  ip address 172.16.1.1 255.255.255.252
  no shut

router eigrp 1
  network 172.168.255.2 0.0.0.0
  network 172.16.1.1 0.0.0.0
  eigrp stub connected summary

To verify you can use commands like below.

“show ip int brief”
“show ip interface virtual-access1”
“show ip eigrp neighbors”
“show crypto isakmp sa”
“show crypto engine connections active”

Update: You might notice I have used classic EIGRP instead of EIGRP named mode, the reason was due to the fact that under the af-interface virtua- template I wasn’t able to set the summary route, the command was accepted but wasn’t being sent to the neighbor. Perhaps this is a bug in the version I was running.

 

Advertisements

One question I’ve been asked is can you terminate a GRE tunnel on a Cisco firewall? and the answer is no! What you can do is use the ASA for encrypting the traffic and here’s how you do it.

Capture

This scenario below could be used for creating a backup link on your WAN routers in fact I’ve seen this done on many networks, used along with IPSLA this might just save your life when your WAN link takes a nosedive.

Create a simple GRE tunnel and source this from a loopback and make the destination the other ends loopback just like below.

Router 1

interface Loopback10
ip address 10.255.255.254 255.255.255.255

interface Tunnel10
description GRE —> to R2
bandwidth 4500
ip address 10.200.200.1 255.255.255.252
ip mtu 1400
ip tcp adjust-mss 1300
keepalive 10 3
tunnel source 10.255.255.254
tunnel destination 10.255.255.253

Router 2

interface Loopback10
ip address 10.255.255.253 255.255.255.255

interface Tunnel10
description GRE —> R1
bandwidth 4500
ip address 10.200.200.2 255.255.255.252
ip mtu 1400
ip tcp adjust-mss 1300
keepalive 10 3
tunnel source 10.255.255.253
tunnel destination 10.255.255.254

Once this is complete you have to make sure there are routes available to route to the loopback address’s from each router so if your WAN link routes one way its more likely you will want to route this towards your firewall and do the same for the other end if this doesn’t hit your firewall your tunnel wont come up.

for example “ip route 10.255.255.254 255.255.255.255 (ip address of your internal default gateway which leads to firewall encrypting the tunnel)
Next what you want to do is configure the firewall one thing i always do when setting up changes on my firewall is to plan, plan and plan again

Remember – Objects / Groups, Routing, NAT, ACL’s, Crypto / Tunnel groups, if you make sure you’ve made all the correct configurations in the list your tunnel will come up no problems.

As you can see from my GRE tunnel I am sourcing from a loopback and destination is a loopback there are 2 reasons behind this 1. A loopback is a virtual interface so can’t go down therefore keeping your tunnel up, 2. That’s the only address’ I need to include in my interesting traffic on my crypto-maps and ACL’s, any other traffic source or destination is encapsulated within the tunnel and the firewall doesn’t need to be configured to allow it.

Below is a sample config of encrypting the tunnel from the Router 2 side, it’s basically the same as creating a normal L2L tunnel and encrypting the traffic, and is the same on the other side just reverse the source and destination.

Objects
————-
name 10.255.255.253 R2_Loopback
name 10.255.255.254 R1_Loopback

Routing
————-
route Inside R2_Loopback 255.255.255.255 (send route towards Router loopback) 1

ACL’s
————-
access-list inside_access_in extended permit ip host R2_Loopback host R1_Loopback
access-list outside_access_in extended permit ip host R1_Loopback host R2_Loopback

NAT Exempt
————-
access-list inside_nat0_outbound extended permit ip host R2_Loopback host R1_Loopback

Crypto / Tunnel group
———————–
access-list outside_cryptomap_1 extended permit ip host R2_Loopback host R1_Loopback

crypto map outside_map 200 set peer (external IP of peer firewall)
crypto map outside_map 200 set transform-set AES-192-SHA

tunnel-group (external IP of peer Firewall) type ipsec-l2l
tunnel-group (external IP of peer Firewall) ipsec-attributes
pre-shared-key *****

Hope this helps all you people out there it certainly helped me when my WAN link went down………. the beauty of using a GRE tunnel means you can send any traffic you want through it the firewall doesn’t care, and yes even run routing protocols like EIGRP or OSPF.

This blog assumes you at least know your way around a router and firewall, I recommend you build a lab and test this on lab equipment before using in a live environment. I accept no responsibility if you decide to do this on live equipment and bring your data centre down 🙂

Remember always save your configuration
RH