Everyone knows how to do NAT on vanilla IOS-XE, but what happens when you put IOS-XE in SD-WAN mode? There are two different ways to do NAT when you use IOS-XE in SD-WAN mode, neither of which is similar to normal IOS-XE. This added complexity is brought on by the addition of the SD-WAN software running on the box and shimming itself into the IOS-XE data plane. Also, remember that SD-WAN mode is always VRF aware. You always will have your WAN connections in a different VRF than your clients. Don’t worry, there’s no “vasiLeft” or “vasiRight” to this solution, the solutions are actually a bit more friendly.
Common Settings
Regardless of what NAT method you choose, there are common settings that must be applied globally on the device to enable NAT on the transport side. These are normal IOS NAT commands that sit on the IOS side of the configuration.
The first change that needs to be made is under the transport interface template (facing your internet connection). NAT needs to be turned on with the NAT Type set to Interface.
Changing those template settings will result in the following additions to the IOS-XE configuration:
ip nat inside source list nat-dia-vpn-hop-access-list interface GigabitEthernet1 overload
interface GigabitEthernet1
ip nat outsideThis configuration is not the only configuration that gets added as a result of the template changes, there are also translation timers that are unimportant to the topic at hand.
Now that you have the transport VRF ready to perform NAT, you need to choose a method to steer traffic from your service VRFs to get NAT’d.
NAT DIA (Direct Internet Access) Route
The first solution, and in my opinion the simplest, is the NAT DIA route. The NAT DIA route is a route added to the service (LAN) side VRF that points out VPN 0. You can make some simple changes to your service VPN template to insert this route. This method is my personal favorite because it is easiest to verify. Since you are placing a route in the RIB, and not relying on the SD-WAN steps shimmed into the data plane FIA you can verify this solution with a simple “show ip route”.
To add the NAT DIA route, edit your VPN template just like you were adding any other route. Instead of the route having an IP next hop, the route has a VPN next hop.
The template change will result in the following change to the IOS configuration which adds a route to the VPN’s RIB towords the global VPN (0).
ip nat route vrf 100 0.0.0.0 0.0.0.0 globalTo verify the complete configuration ping from the service VRF an internet destination:
--- output of "ping vrf 100 200.200.26.1" ---
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.200.26.1, timeout is 2 seconds:
!!!!!To check verification of the NAT DIA route you can show the routing table for the service VPN:
--- output of "show ip route vrf 100 | b Gate" ---
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
n*Nd 0.0.0.0/0 [6/0], 00:04:45, Null0Here it can be seen that a route of type Nd is pointing to Null0. In reality this route is traversing the VRFs to the transport VRF. To see this in action we can check a FIA trace to see the NAT feature invoked:
--- output of FIA Trace ---
Packet: 0 CBUG ID: 10
Summary
Input : INJ.2
Output : GigabitEthernet1
State : FWD
Timestamp
Start : 864736620479848 ns (05/18/2024 23:27:02.79042 UTC)
Stop : 864736620742915 ns (05/18/2024 23:27:02.79305 UTC)
--- Output Omitted for Brevity ---
Feature: NAT
VRFID : 1
table-id : 1
Protocol : ICMP
Direction : IN to OUT
From : Service side
Action : Translate Source
Steps : SESS-CREATE
Match id : 1
Old Address : 10.1.101.1
New Address : 50.50.25.11
Orig src port : 4
New src port : 4
Orig dest port : 4
New dest port : 4
--- Output Omitted for Brevity ---Data Policy NAT
The second solution to leaking the traffic is a little less straight forward. It relies on the shim that the SD-WAN software has in the IOS-XE data plane to shim NAT into the packets path. This means that there is no way to see this in the normal routing table. Since this is a central data policy, configuration happens on the SD-WAN controller not the edge device itself.
Below is the basic Traffic Data policy required for NAT. Using a custom control policy allows you to add a sequence rule with the action “NAT VPN 0”, which sends the traffic to VPN 0 to be subject to NAT. Although, similar to old style site-to-site VPNs, you need a sequence rule above to disallow NAT of private traffic traversing the SD-WAN. I won’t show the complete Central Policy, but this is the only requirement aside from defining your lists of interest.
The above template results in the following configuration to be pushed to the edges listed in the site list:
data-policy _CORP-VPNS_NAT_DIA_BR3_3
vpn-list CORP-VPNS
sequence 1
match
destination-data-prefix-list RFC1918
!
action accept
count NO-NAT_751429611
!
!
sequence 11
match
source-ip 0.0.0.0/0
!
action accept
nat use-vpn 0
count NAT-DP_751429611
!
!
default-action dropThrough my testing I have found that this method of NAT does not allow you to do a “ping vrf” on the edge device and get to the internet. For some reason the traffic is not subjected to the data policy when it originated from the devices control plane.
Once applied, you should be able to immediately start sending traffic from your service VPN to the internet. If traffic is not being NAT’d first use the counter to see if the sequence in the data policy is being hit:
--- output of "show sdwan policy data-policy-filter" ---
data-policy-filter _CORP-VPNS_NAT_DIA_BR3_3
data-policy-vpnlist CORP-VPNS
data-policy-counter NAT-DP_-1196365765
packets 5
bytes 570
data-policy-counter NO-NAT_-1196365765
packets 0
bytes 0If it is being hit and NAT reachability is still not established, it may be best to do a FIA trace to see the SD-WAN NAT steps in the path of the packet. FIA tracing requires some setup, so I won’t go over how to set up the trace itself (there are many great Cisco Live presentations on the subject).
--- output of FIA Trace ---
Packet: 0 CBUG ID: 0
Summary
Input : GigabitEthernet3
Output : GigabitEthernet1
State : FWD
Timestamp
Start : 2169193606409 ns (05/19/2024 01:05:45.646672 UTC)
Stop : 2169193663617 ns (05/19/2024 01:05:45.646729 UTC)
Path Trace
--- Output Omitted for Brevity ---
Feature: SDWAN Data Policy IN
VPN ID : 100
VRF : 1
Policy Name : _CORP-VPNS_NAT_DIA_BR3_3-CORP-VPNS (CG:4)
Seq : 11
DNS Flags : (0x0) NONE
Policy Flags : 0x10010
Policy Flags2: 0x0
Action : REDIRECT_NAT
--- Output Omitted for Brevity ---
Feature: NAT
VRFID : 1
table-id : 1
Protocol : ICMP
Direction : IN to OUT
From : Service side
Action : Translate Source
Steps : SESS-CREATE
Match id : 1
Old Address : 10.3.1.2
New Address : 100.100.23.2
Orig src port : 30
New src port : 30
Orig dest port : 30
New dest port : 30
--- Output Omitted for Brevity ---Here we can see the SD-WAN policy feature invoking IOS-XE NAT which happens later in the chain of features. As stated before, there is still no default route in the service side table, and this is purely a data plane invocation of NAT. In fact, even showing the CEF table shows not trace that NAT will be invoked.
--- output of "show ip route vrf 100 | b Gate" ---
Gateway of last resort is not setThese characteristics make policy NAT in my opinion harder to troubleshoot for someone not familiar with the IOS data plane, and the order of operations of the NAT process.
| Cisco SD-WAN Manager (vManage) | 20.13.1 |
| Cisco SD-WAN Validator (vBond) | 20.13.1 |
| Cisco SD-WAN Controller (vSmart) | 20.13.1 |
| Cisco SD-WAN Edge (IOS-XE) | 17.13.01a |
| Cisco CML | 2.7.0+build.4 |