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:
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.
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.
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.
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:
- Static default route in the global routing table pointing to the interface in the transport table;
- IP prefix export from VRF table into global routing table (available in IOS XE release 3.7S)
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.
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.
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.
- Choose the optimal VPN service
- DMVPN: From Basics to Scalable Networks
- DMVPN Designs
- DMVPN New Features
- DMVPN trilogy
- Enterprise MPLS VPN Deployment
Products and Services
- Yearly subscription
- ExpertExpress and Consulting
- Live events and on-site workshops
- Webinars and recordings
- Customized webinars
About Ivan Pepelnjak
- Network Automation Use Cases
24 January 2017
- PowerShell for Networking Engineers
13 February 2017
- Open Networking for Large-Scale Networks
9 May 2017
- Building Network Automation Solutions (Online course)
15 September 2017
Related blog posts