This lab will examine another common use case referred to as Direct Cloud Access (DCA). As more and more organizations leverage cloud services such as IaaS/SaaS, backhauling Internet-bound employee traffic to a data center across the overlay fabric causes increased bandwidth and latency, resulting in a degradation of the application quality of experience (AppQoE). The solution to this problem is to enable local Internet exit to employees at remote branches. However, there is a big difference in the requirements when direct internet access is provided to guests and when it is provided to business users or employees. From a security standpoint, giving employees unrestricted access to the entire world-wide-web exposes the organization to some serious cyber security vulnerabilities. From an availability standpoint, if Internet access is used for business, it has to be available at any given moment irrespective of any local ISP failures.   

In this lab example, we will show how a regional data center is used as a backup Internet breakout site for branches. We are going to enable DIA to VPN 1. However, this time the DIA would be used by employees, so we will make sure that the Internet access works in case of any direct or indirect failure within the local ISP. To achieve this objective, we will use two Cisco SD-WAN features called NAT Tracker and NAT Fallback. 

What is NAT Fallback?

If we check the current data policy applied to the guest VPN, we will see that the nat use-vpn 0 action that does the DIA has an optional configuration argument called nat fallback.  

vEdge-6# show policy from-vsmart
! 
from-vsmart data-policy DATA-POLICY-TO-SPOKES
 direction from-service
 vpn-list VPN6
  sequence 10
   match
    destination-data-prefix-list RFC1918
   action drop
  sequence 11
   match
    source-data-prefix-list PROXIES
   action accept
    count TRAFFIC-FROM-PROXIES
    nat use-vpn 0
    no nat fallback
  default-action accept
!

The NAT fallback configuration specifies what the forwarding behavior should be in case there are no local NAT-enabled interfaces that are operational. At the moment, if the biz-internet interface of vEdge-6 goes down, the local Internet exit will no longer be usable, and the guest VPN will no longer be able to access the Internet.

With the nat fallback enabled, if all NAT-enabled transport interfaces go to a non-operational state due to a failure, the local DIA traffic will follow the forwarding path determined by an IP lookup in the underlying VPN routing table. In other words, the nat fallback tells the vEdge router - “in case there is no local Internet-facing interface in an operational state, fallback to regular routing.” 

In a typical SD-WAN deployment, this would mean that in case of a failure of the local ISP circuit, the local Internet-bound traffic would go across the overlay fabric and egress at a regional hub site or data center. However, a key point here is to understand what types of failure would trigger the fallback to regular routing. By default, only direct failures, such as all Internet-facing interfaces going down, would trigger the nat fallback process. That is why the nat fallback is typically combined with another feature called NAT DIA Tracker.

What is NAT DIA Tracker?

The NAT DIA tracker is a tool that detects indirect failures along the Internet path to a given external service. The tracker is configured on any NAT-enabled transport interface used for DIA. The tool works by sending probes to a configured external endpoint and monitoring whether probes fail or succeed. If the number of failed probes exceeds the configured threshold value, the tracker considers the external endpoint unreachable and makes the transport interface unavailable for DIA. The tracker continues to check the status of the external endpoint periodically. When it detects that the service is available again, the Internet-facing transport interface is available for NAT DIA again.

Lab Topology and Initial Config 

The lab topology that we will use for this example is shown in figure 1 below. The overlay topology is hub and spoke with vEdges 1 and 2 acting as hub routers and the vEdges 3 - 6 being spokes. (VPN6).

In lab#1, we have enabled Direct Internet Access (DIA) to VPN 6 (Guests) and in lab#2 we have applied a VPN-wide ACL that denies any traffic from the guest segment destined to RFC1918 addresses.

Configuring NAT DIA Tracker

In this lab example, we will configure a tracker that monitors whether the public website linkedin.com is reachable through the biz-internet transport interface on vEdge-6, as illustrated in figure 2. 

The tracker configuration goes under the system settings on a vEdge router. It is given a name (up to 128 lowercase characters), and then, at a minimum, an endpoint IP or DNS name is specified. The tracker is applied under the Internet-facing transport interfaces used for DIA on the local vEdge. In our example, this would be interface ge0/0.

vEdge-6# conf t
Entering configuration mode terminal
vEdge-6(config)# system
vEdge-6(config-system)#  tracker linkedin.com
vEdge-6(config-tracker-linkedin.com)# endpoint-dns-name linkedin.com
vEdge-6(config-tracker-linkedin.com)# interval 30
vEdge-6(config-tracker-linkedin.com)# multiplier 5
!
vEdge-6(config)# vpn 0
vEdge-6(config-vpn-0)# int ge0/0
vEdge-6(config-interface-ge0/0)# tracker linkedin.com 
vEdge-6(config-interface-ge0/0)# commit and-quit 

Once the tracker is configured and applied under the transport interface, we can see that the interface ge0/0 reports that the “IF TRACKER STATUS” is Up.

vEdge-6# show int vpn 0 | t
                                    IF      IF      IF                              
                AF                  ADMIN   OPER    TRACKER  ENCAP                  
VPN  INTERFACE  TYPE  IP ADDRESS    STATUS  STATUS  STATUS   TYPE   PORT TYPE  MTU  
------------------------------------------------------------------------------------
0    ge0/0      ipv4  39.3.0.1/16   Up      Up      Up       null   transport  1500 
0    ge0/1      ipv4  10.10.0.1/16  Up      Up      NA       null   transport  1500 
0    system     ipv4  6.6.6.6/32    Up      Up      NA       null   loopback   1500 

Before we show what will happen when the linkedin.com website becomes unreachable through ge0/0, let’s first enable DIA with NAT fallback on VPN 1. 
First, we will need to configure a VPN list that matches VPN 1 and a data prefix-list that matches the enterprise IP addresses used within the VPN. 

policy
 lists
  !
  vpn-list VPN1
   vpn 1
  ! 
  data-prefix-list ENTERPRISE-IPS
   ip-prefix 10.0.0.0/8
  !

Then under the existing data policy DATA-POLICY-TO-SPOKES, we will configure a new section under VPN-list VPN1. 

data-policy DATA-POLICY-TO-SPOKES
  vpn-list VPN1
   sequence 11
    match
     destination-data-prefix-list ENTERPRISE-IPS
    !
    action accept
   !
   sequence 21
    action accept
     nat use-vpn 0
     nat fallback
   !
   default-action drop
  ! 

The policy’s logic is that sequence 11 matches all employee traffic destined to internal enterprise services. In our example, this would be all packets destined to 10.0.0.0/8. Then sequence 21 matches all packets that had not been matched at seq 11 and leaks them into VPN 0 and out to the Internet. Notice that this time, the nat fallback option is enabled.   

At this point, clients in VPN 1 at branches should have Internet access while being able to reach any internal services over the sd-wan fabric.

vEdge-6# ping vpn 1 linkedin.com
Ping in VPN 1  #pinging public Internet service
PING linkedin.com (13.107.42.14) 56(84) bytes of data.
64 bytes from 13.107.42.14 (13.107.42.14): icmp_seq=1 ttl=127 time=20.1 ms
64 bytes from 13.107.42.14 (13.107.42.14): icmp_seq=2 ttl=127 time=22.9 ms
64 bytes from 13.107.42.14 (13.107.42.14): icmp_seq=3 ttl=127 time=12.8 ms
^C
--- linkedin.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 12.891/18.655/22.924/4.233 ms
!
vEdge-6# ping 10.1.1.1 
Ping in VPN 0 #pinging enterprise service hosted at the hub
PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data.
64 bytes from 10.1.1.1: icmp_seq=1 ttl=254 time=9.03 ms
64 bytes from 10.1.1.1: icmp_seq=2 ttl=254 time=10.3 ms
64 bytes from 10.1.1.1: icmp_seq=3 ttl=254 time=17.0 ms
^C
--- 10.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 9.035/12.138/17.078/3.531 ms

In case of a failure of the Internet-facing interface or within the Internet path to linkedin.com, the NAT tracker will make the transport interface ge0/0 unavailable for DIA. Then, because the “nat fallback” option is enabled, the vEdge router will fall back to the VPN routing table. However, at the moment, there is no default route in VPN1’s route table, and the routers do not know where to forward any Internet-bound traffic. 

vEdge-6# show ip route vpn 1 | t
# there is no default route in VPN1 so Internet-bound traffic can’t be routed over the overlay fabric
     ADDRESS                           NEXTHOP                                     
VPN  FAMILY   PREFIX        PROTOCOL   IFNAME  TLOC IP  COLOR         ENCAP  STATUS
-----------------------------------------------------------------------------------
1    ipv4     10.1.1.0/24   omp        -       1.1.1.2  mpls          ipsec  F,S   
1    ipv4     10.1.50.0/24  omp        -       1.1.1.2  mpls          ipsec  F,S   
1    ipv4     10.1.50.0/24  omp        -       1.1.1.2  biz-internet  ipsec  F,S   
1    ipv4     10.6.1.0/24   connected  ge0/2   -        -             -      F,S  

The first step to configuring the hub to act as a backup Internet breakout site is to inject a default route via OMP into VPN1. As of now, the only possibility to inject a default route into the overlay fabric via OMP is by using the static route “ip route 0.0.0.0/0 Null0”. Of course, this behavior may change in future software releases.

Let’s inject a default route into VPN1 from the hub’s WAN edge routers.

vEdge-1# conf t
#for redundancy, we should configure this on vEdge-2 as well
Entering configuration mode terminal
vEdge-1(config)# vpn 1
vEdge-1(config-vpn-1)# ip route 0.0.0.0/0 null0 
vEdge-1(config-vpn-1)# commit 
Commit complete.

Now you can see that vEdge-6 has a default route pointing to each hub’s TLOC.  

vEdge-6# show ip route vpn 1 | t

     ADDRESS                           NEXTHOP                                       
VPN  FAMILY   PREFIX        PROTOCOL   IFNAME  TLOC IP  COLOR         ENCAP  STATUS
-----------------------------------------------------------------------------------
1    ipv4     0.0.0.0/0     omp        -       1.1.1.1  mpls          ipsec  F,S   
1    ipv4     0.0.0.0/0     omp        -       1.1.1.1  biz-internet  ipsec  F,S   
1    ipv4     0.0.0.0/0     omp        -       1.1.1.2  mpls          ipsec  F,S   
1    ipv4     0.0.0.0/0     omp        -       1.1.1.2  biz-internet  ipsec  F,S   
1    ipv4     10.1.1.0/24   omp        -       1.1.1.2  mpls          ipsec  F,S   
1    ipv4     10.1.50.0/24  omp        -       1.1.1.2  mpls          ipsec  F,S   
1    ipv4     10.1.50.0/24  omp        -       1.1.1.2  biz-internet  ipsec  F,S 

At this point, when a failure along the DIA path occurs, the spoke routers will fallback to the VPN routing table and successfully send the Internet-bound traffic to the hub. However, the hub is not configured to do DIA at the moment. (the current data policy is applied to site-list SPOKES, hence not sent to the hub’s vEdges)

Let’s create another centralized data policy named DATA-POLICY-TO-HUB and apply it to the hub’s vEdges.

 data-policy DATA-POLICY-TO-HUB
  vpn-list VPN1
   sequence 11
    match
     destination-data-prefix-list ENTERPRISE-IPS
    !
    action accept
   !
   sequence 21
    action accept
     nat use-vpn 0
    !
   !
   default-action drop
 !

The logic is the same as in the data policy to spokes, with the only exception being that the nat fallback option is not enabled because there is no other Internet location that the hub can fall back to.

The key difference is the direction in which we will apply the policy. We applied the policy in the "from-service" direction on the spoke routers because they provide local Internet access to clients connected on the service-side in VPN 1. However, the hub should act as an Internet exit for traffic from spokes over the overlay fabric. Therefore, we will apply the hub's data policy in a “from-tunnel” direction.

apply-policy
 site-list HUB
  data-policy DATA-POLICY-TO-HUB from-tunnel

Now, if we introduce a failure and make the LinkedIn website unreachable over vEdge-6's interface ge0/0, we are going to trigger the following chain of events as illustrated in figure 3.

The NAT DIA tracker detects that the configured Internet endpoint linkedin.com is unreachable over the ge0/0 interface, even though the interface itself is up and running. This can be seen in the output of the show interface vpn 0 command.