## VRF-Aware NAT **VRF-Aware NAT** is used to allow traffic from a VRF (usually a customer or internal VRF) to be translated **before** it enters the global routing table. Why? Because: - Traffic leaving a VRF **must be NATed first**, or else the global routing table won’t know how to route it (since VRF routes are isolated). - When return traffic comes back, the NAT process reverses the translation **before** it re-enters the VRF — so it doesn’t get dropped in the global VRF due to a missing route. This creates a clean edge between the **VRF** and the **global routing table**, using NAT as a handoff between them. > This NAT method **requires** the configuration of a route that points to an IP address that is not locally on itself. For NATing between VRFs without this limitation, use VASI if on IOS-XE. ### Key Concepts - The **VRF has no direct routing knowledge** of global, and vice versa. - A static route using the `global` keyword allows VRF traffic to **exit** toward the global next-hop. - NAT ensures return traffic is **translated back into the originating VRF** before routing decisions are made globally (dropping the traffic). ### Configurations ```none interface GigabitEthernet0/0 description To-WAN ip address 10.0.0.2 255.255.255.252 ip nat outside interface GigabitEthernet0/1 description To-LAN ip address 192.168.1.1 255.255.255.0 vrf forwarding INSIDE ip nat inside ``` ```none vrf definition INSIDE rd 1:1 address-family ipv4 ``` ```none ip route 0.0.0.0 0.0.0.0 10.0.0.1 ip route vrf INSIDE 0.0.0.0 0.0.0.0 10.0.0.1 global ``` > The `global` keyword enables traffic from the VRF to exit into the global space, assuming NAT occurs before it crosses the boundary. Without the following NAT configs, a ping could get out, but could not return, since you cannot have a route from Global pointing to a VRF. ```none access-list 1 permit 192.168.1.0 0.0.0.255 ip nat inside source list 1 interface g0/0 vrf INSIDE overload ``` Explanation: - Traffic from `192.168.1.0/24` (inside the VRF) gets **NATed** using the **outside interface IP** (`g0/0`). - NAT happens **within the context of the `INSIDE` VRF**, ensuring translation occurs BEFORE hitting the global routing table. - Return traffic from the WAN will be translated **back into the VRF** BEFORE forwarding decisions are made by the Global VRF. ## VRF-Aware Software Infrastructure (VASI) [VASI Cisco IOS-XE Whitepaper](https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/200255-Configure-VRF-Aware-Software-Infrastruct.html) On **Cisco IOS XE**, classical inter-VRF NAT is **not directly supported**. To perform NAT between VRFs, Cisco introduced **VASI**: *VRF-Aware Software Infrastructure*. ### What is VASI? VASI is a technique that enables **inter-VRF NAT** by creating **VASI interface pairs**: - Each **VASI interface** is tied to a **different VRF** - One is used as the **inside NAT** interface, the other as **outside** - Packets are routed between them just like physical interfaces - Example interface names: `vasileft1`, `vasiright1` VASI interfaces act as **loopback-style virtual links**, switching packets between two VRFs at Layer 3. > VASI is the supported method to implement inter-VRF NAT on IOS XE. ### Configuration In this example, we are NATing from **VRF_LEFT** to **VRF_RIGHT** only. ![[VASI-CML.png]] #### **NAT on `vasiright`** **Typical use case.** Most common scenario: the WAN or upstream-facing interface is part of **VRF_RIGHT**. - **Vasiright1** (in VRF_RIGHT) is the **NAT inside** - **GigabitEthernet2** (WAN-facing) is the **NAT outside** ```none interface GigabitEthernet1 vrf forwarding VRF_LEFT ip address 192.168.1.2 255.255.255.0 interface GigabitEthernet2 vrf forwarding VRF_RIGHT ip address 172.16.1.2 255.255.255.0 ip nat outside ``` ``` vrf definition VRF_LEFT rd 1:1 address-family ipv4 vrf definition VRF_RIGHT rd 2:2 address-family ipv4 ``` ``` interface vasileft1 vrf forwarding VRF_LEFT ip address 10.1.1.1 255.255.255.252 interface vasiright1 vrf forwarding VRF_RIGHT ip address 10.1.1.2 255.255.255.252 ip nat inside ``` ``` access-list 1 permit any ip route vrf VRF_LEFT 172.16.0.0 255.255.0.0 vasileft1 10.1.1.2 ip route vrf VRF_RIGHT 192.168.0.0 255.255.0.0 vasiright1 10.1.1.1 ip nat inside source list 1 interface GigabitEthernet2 vrf VRF_RIGHT overload ``` #### **NAT on `vasileft`** In some designs, NAT is done **entirely within VRF_LEFT**, before sending traffic into VRF_RIGHT. - **GigabitEthernet1** (LAN-facing) is the **NAT inside** - **Vasileft1** (link to VRF_RIGHT) is the **NAT outside** ```none interface GigabitEthernet1 vrf forwarding VRF_LEFT ip address 192.168.1.2 255.255.255.0 ip nat inside interface GigabitEthernet2 vrf forwarding VRF_RIGHT ip address 172.16.1.2 255.255.255.0 interface vasileft1 vrf forwarding VRF_LEFT ip address 10.1.1.1 255.255.255.252 ip nat outside interface vasiright1 vrf forwarding VRF_RIGHT ip address 10.1.1.2 255.255.255.252 access-list 1 permit any ip route vrf VRF_LEFT 172.16.0.0 255.255.0.0 vasileft1 10.1.1.2 ip route vrf VRF_RIGHT 192.168.0.0 255.255.0.0 vasiright1 10.1.1.1 ip nat inside source list 1 interface vasileft1 vrf VRF_LEFT overload ```