Inter-VRF NAT in DMVPN Local Internet Exit Designs

DMVPN designs with front-door VRF (VRF use to transport DMVPN data across WAN network) are extremely common with Phase 2 and Phase 3 DMVPN or Cisco IWAN deployments.

In these designs, a transport (front) VRF is created, and the WAN interfaces are placed in the transport VRF. This VRF has an independent routing table and default route, allowing the DMVPN traffic to use a different default route than the user-generated traffic.

A typical configuration using transport VRF is shown in the following figure:

DMVPN remote site using Front VRF
For more information on DMVPN technology and DMVPN designs, watch the webinars from the DMVPN Trilogy.

If you want to combine the front VRF designs with local Internet exit (and associated Network Address Translation – NAT), you have to implement inter-VRF NAT. Packets received through the global routing table (user traffic) have to be translated using NAT rules associated with an interface belonging to the transport VRF.

NAT rules configured between global routing table and Front VRF

Configuring the NAT rules between the global routing table and transport VRF is not enough. There must be an entry in the global routing table (for example, a default route) that will send the incoming packet toward the Internet-facing interface.

The best default route should point to the local Internet uplink for the local Internet exit to work. The simplest design that achieves this requirement is a default-free internal network.

With a route pointing to the Internet interface, the incoming packet might get forwarded to the upstream DMVPN tunnel (if the hub router announces a default route) or dropped.

Packet for an Internet destination is received by the DMVPN spoke router

There are two mechanisms that could be used to create the default route in the global routing table pointing to the Internet-facing interface in the transport VRF:

Default route in the global routing table points to a VRF interface

Once the default static route pointing to the Internet interface is present in the global routing table, the incoming packet could be sent toward the Internet interface creating a NAT translation entry on the way.

Packet routed to VRF interface triggers source NAT translation

There’s no need to have a static route in the transport VRF to handle the return traffic.

The NAT translation entry created by the outgoing packet contains ingress and egress forwarding table information. When the return packet arrives, its (outside) destination IP address is in the transport VRF and thus routable to local interface which contains the NAT rules and associated NAT translation table.

When the destination IP address in the return packet is translated using the NAT translation entry that was created by the outgoing packet, the return packet is automatically forwarded using the correct forwarding table.

Static NAT entries are an obvious exception. Routes toward these destinations would have to be leaked from the global routing table to the transport VRF. While Cisco IOS doesn’t have a global-to-VRF route leaking functionality, PBR seems to be a good alternative.

Return packet is routed to global routing table based on NAT translation entry
For more information on VRFs and inter-VRF NAT in Cisco IOS, watch the Enterprise MPLS/VPN webinar.

You can't leave comments on this web site, but you can add them to this blog post.

Comments from the blog post

stuart dale on 18 August 2016:

Ivan - guess this depends on the private network being default-free though - sorry haven't watched the webinar yet so maybe covered elsewhere!

Ivan Pepelnjak on 18 August 2016:

Yes, the private network has to be default-free. Will add to the article. Thank you!

Pavel Skovajsa on 19 August 2016:

If the global is default free, what would be the use case for having front vrf. Seems to me that in this case we are splitting the network in separate vrfs just to join those vrfs later with NAT.

Still this is definitely very useful if you have multiple VRFs on customer side - you can provide direct internet connectivity to all of them.

Ivan Pepelnjak on 19 August 2016:

Hi Pavel, really nice to hear from you after a long while.

One of the scenarios would be two DMVPN tunnels on two Internet uplinks. If you want to make sure traffic from each tunnel uses its own uplink, two front VRFs are the only solution that work(ed?).

Also, it seems IWAN uses the same approach (makes things consistent regardless of what you're doing on top of DMVPN).

Nikos on 19 August 2016:

"While Cisco IOS doesn’t have a global-to-VRF route leaking functionality, PBR seems to be a good alternative."

Sure it has, Cisco just makes you jump through hoops in order to make it work.

Darren has an excellent post about this functionality.