0

I have a DMVPN spoke router setup almost identically to the spoke configuration listed here (Also quoted below): https://www.cisco.com/c/en/us/support/docs/security-vpn/dynamic-multi-point-vpn-dmvpn/119022-configure-dmvpn-00.html

In short, each ISP's WAN IP and default route are in its own VRF. The two tunnels each use a different VRF/ISP to go to their respective hub router. The global routing table contains only the LAN and other networks learned by EIGRP coming through the VPN tunnels.

This setup is working very well and failover times for the VPNs are great, though I was hoping to figure out the best way to have the LAN on this router get NAT/default route for internet access when each ISP in a VRF.

Normally I'd just do an IP SLA on one default route, but I don't really know where to begin with VRFs being involved.

version 15.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname SPOKE1
!
vrf definition ISP1
 rd 1:1
 !
 address-family ipv4
 exit-address-family
!
vrf definition ISP2
 rd 2:2
 !
 address-family ipv4
 exit-address-family
!
crypto keyring ISP2 vrf ISP2
  pre-shared-key address 0.0.0.0 0.0.0.0 key cisco123
crypto keyring ISP1 vrf ISP1
  pre-shared-key address 0.0.0.0 0.0.0.0 key cisco123
!
crypto isakmp policy 1
 encr aes 256
 hash sha256
 authentication pre-share
 group 24
crypto isakmp keepalive 10 periodic
!
crypto ipsec transform-set transform-dmvpn esp-aes 256 esp-sha256-hmac
 mode transport
!
!
crypto ipsec profile profile-dmvpn
 set transform-set transform-dmvpn
!
interface Loopback10
 ip address 192.168.1.1 255.255.255.0
!
interface Tunnel0
 description Primary mGRE interface source as Primary ISP
 bandwidth 1000
 ip address 10.0.0.10 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp network-id 100000
 ip nhrp holdtime 600
 ip nhrp nhs 10.0.0.1 nbma 172.16.0.1 multicast
 ip nhrp shortcut
 ip tcp adjust-mss 1360
 delay 1000
 tunnel source Ethernet0/0
 tunnel mode gre multipoint
 tunnel key 100000
 tunnel vrf ISP1
 tunnel protection ipsec profile profile-dmvpn
!
interface Tunnel1
 description Secondary mGRE interface source as Secondary ISP
 bandwidth 1000
 ip address 10.0.1.10 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp network-id 100001
 ip nhrp holdtime 360
 ip nhrp nhs 10.0.1.1 nbma 172.16.0.1 multicast
 ip nhrp shortcut
 ip tcp adjust-mss 1360
 delay 1500
 tunnel source Ethernet0/1
 tunnel mode gre multipoint
 tunnel key 100001
 tunnel vrf ISP2
 tunnel protection ipsec profile profile-dmvpn
!
interface Ethernet0/0
 description Primary ISP
 vrf forwarding ISP1
 ip address 198.51.100.1 255.255.255.0
!
interface Ethernet0/1
 description Seconday ISP
 vrf forwarding ISP2
 ip address 203.0.113.1 255.255.255.0
!
router eigrp 1
 network 10.0.0.0 0.0.0.255
 network 10.0.1.0 0.0.0.255
 network 192.168.0.0 0.0.255.255
!
ip route vrf ISP1 0.0.0.0 0.0.0.0 198.51.100.254
ip route vrf ISP2 0.0.0.0 0.0.0.0 203.0.113.254
!
logging dmvpn
!
end
7
  • 1
    Do you want one ISP as the primary and the other as the secondary for the Internet? You really do not want to NAT on your router because your ISP addresses are private addresses, and you only want to NAT from private to public, not private to private. The ISP must be using NAT for its private to public addresses, and double-NAT can really mess things up.
    – Ron Maupin
    Sep 22, 2020 at 1:36
  • @RonMaupin Yes, one ISP as primary and the other as secondary. Both WAN connections will have public IPs. The config listed is just an example from Cisco that's almost the same as my config, just with different IP addresses.
    – Ben
    Sep 22, 2020 at 1:39
  • 1
    Please do not use private addresses as examples of public addresses because it really confuses things. IANA has set aside three IPv4 prefixes and one IPv6 prefix to be used as example addresses: 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, and 2001:db8::/32. Network engineers know those are example addresses, not real public addresses, and not private addresses. In any case you can put in both default routes and use AD to set the secondary to less preferred, or you can use enhanced object tracking for things like line protocol, routing state, reachability, etc.
    – Ron Maupin
    Sep 22, 2020 at 1:46
  • Thanks, that would definitely clear things up. My issue is that that the two ISPs links are isolated in VRFs, while my LAN is not. I'm trying to find a way to use those default routes in the VRFs for my LAN in the global routing table
    – Ben
    Sep 22, 2020 at 2:03

1 Answer 1

0

So, you have a design conflict here.

You've used something called a Front Door VRF for your tunnels (or, two Front Door VRFs, in your case). The purpose of this design is to isolate the internal network from the external network. This isolation adds certain aspects of security to the topology, makes routing more straightforward, and also makes it slightly harder to accidentally mess stuff up; but it comes at the expense of making the config more complex. Overall, this is a great design, and it's recommended in some scenarios.

But you seem to be wanting to allow traffic to move between the inside and outside VRFs. This is philosophically opposite from the intent of using a Front Door VRF. If you want traffic to move between the VRFs, then put the interfaces into the same VRF as one another (abandoning the Front Door VRF design). You would create static routes for your VPN headends that point out their respective ISP. Then, you would add route tracking with IP SLA for internet failover. Lastly, you would add your typical NAT commands to get egress traffic working.

But, if you really want to keep your VRFs in place, yet still allow traffic to cross VRFs, you do it with something called Route Leaking. You can add export and import commands to the VRFs that allow prefixes to be injected to routing tables for oter VRFs. You would leak the internal network into the ISP VRF, and leak the default route into the internal VRF. (This is slightly dangerous if you're not careful.) Here's an example of how you can do it: https://www.cisco.com/c/en/us/support/docs/ip/ip-routing/216541-vrf-configuration-examples-on-ios-xe.html#anc17

Finally, once the routes are leaked between the VRFs, you would add the typical NAT commands to the configuration to get external access working.

1
  • Thanks! I will likely go with using static routes out each gateway to the VPN endpoints + IP SLA, that's pretty tidy. The alternative I'm also considering is keeping the Front Door VRFs, but instead do the NAT rules at a VPN hub router. The hubs are located in facilities with stable internet connections, versus the unstable remote sites. Having the NAT on the hub would mean in a failover situation, the src/dst NAT IPs won't change. In this application, higher performance local internet isn't a requirement.
    – Ben
    Jan 15, 2023 at 21:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.