In the previous section about centralized control policies, in lab#6, we created a VPN membership policy that isolates the users within VPN6 (the guest segment) from communicating over the overlay fabric. However, we have not enabled Internet access for the guest clients. In this lab example, we will configure a centralized data policy that provides DIA (direct internet access) to the users in the guest segment. We will use the same lab topology as in the previous section and manipulate VPN 6.

What is Cisco SD-WAN DIA?

Public cloud and SaaS have redefined the branch and WAN. The majority of employees and devices at branches now access Cloud-based and Internet-based applications. However, the traditional WAN architecture backhauls all Internet-bound traffic to the regional DC resulting in higher latency, high costs, and complex management. Additionally, this creates a bottleneck at the data center WAN links and security stack, as shown in figure 1 below.

Cisco DIA is a component of the SD-WAN architecture that allows Internet-bound traffic from branches to be routed directly to the Internet through the local ISPs, bypassing the inefficiencies of backhauling the traffic to a data center or a regional hub. Enabling local Internet breakout at remote branches has some significant benefits over the datacenter-oriented approach:

• DIA improves the performance of IaaS and SaaS applications by eliminating the latency created by backhauling traffic to the data center and back.
• It lowers the bandwidth consumption at the data center’s WAN links, thereby reducing WAN costs.
• It allows us to segment the Internet access per VPN, allowing for guest and employee traffic separation.
• It allows branches to use DNS and geo-location services based on their actual location.
• The bottom line is a better application experience for customers and employees at branches.

Cisco DIA gives us granular control to choose which users can access what applications through the local Internet exit. We can easily set up a network segment for guests and give them full Internet access. At the same time, we can configure another separate network segment for employees and provide them with access to a few specific Internet applications. We can combine the Direct Internet Access (DIA) feature with most Cisco SD-WAN security capabilities available within the security dashboard on vManage such as Advanced Malware Protection (AMP), Enterprise Firewall with Application Awareness, Intrusion Prevention System (IPS), DNS/Web-layer Security, and URL Filtering (URLF).

Cisco DIA offers a significant improvement compared to the traditional WAN approach, where we rely on the data center or dedicated hardware boxes at branches to apply the company’s security policy. 

Lab Topology and Initial Config 

The lab topology that we are going to use for this example is shown in figure 3 below. We are going to enable Direct Internet Access (DIA) to the branches' guest segment (VPN6).

The overlay topology is hub and spoke with vEdges 1 and 2 acting as hub routers and the vEdges 3 - 6 being spokes. None of the vEdges have any data policy applied.

NAT

An essential part of enabling Direct Internet Access (DIA) at branches is the Network Address Translation (NAT). Before a WAN edge router is enabled for DIA, the transport interfaces that face the Internet must be configured to perform NAT overload. This is as simple as configuring just one command nat under vpn0 > the interface facing the Internet. NAT overload is a feature that maps multiple private IP addresses to a single public IP address by using different port numbers. When the DIA feature redirects some service-side Internet-bound traffic to VPN0, the source IP addresses are translated to the NAT-enabled interface’s IP address before exiting the router toward the ISP network. 

In our lab examples, we will enable DIA on all vEdge routers. Therefore, we first need to enable NAT on the transport interfaces connected to the biz-internet cloud. This is as simple as configuring just one command nat under vpn0 > interface ge0/0.

#this should be configured on all vEdges (1 through 6)
vEdge-6# conf t
vEdge-6(config)# vpn 0
vEdge-6(config-vpn-0)# int ge0/0
vEdge-6(config-interface-ge0/0)# nat
vEdge-6(config-nat)# commit and-quit 
Commit complete.

Once NAT is enabled on the Internet-facing transport interfaces, there are two methods that we can use to enable direct internet access for a VPN.

Method#1: Local breakout using NAT DIA static route

The easiest way to enable DIA on a vEdge router is to configure a static NAT DIA route that points to the transport VPN, as illustrated in figure 4 below. 

This is as simple as configuring a single default route under a given service-side VPN. For example, let’s enable DIA for the users in VPN6 on vEdge-6.

vEdge-6# conf t
Entering configuration mode terminal
vEdge-6(config)# vpn 6
vEdge-6(config-vpn-6)# ip route 0.0.0.0/0 vpn 0
vEdge-6(config-nat)# commit and-quit 
Commit complete.

Let’s now check the routing table of vEdge-6 for VPN6. Notice that the default route has been installed by protocol “nat” and points to “nexthop-vpn 0” in the routing table. It means the NAT DIA route leaks traffic out of the guest VPN through the NAT-enabled interfaces in VPN 0 to the Internet. 

vEdge-6# show ip route vpn 6 0.0.0.0/0 detail
--------------------------------------------
 VPN 6      PREFIX 0.0.0.0/0
--------------------------------------------
 proto          nat
 distance       1
 metric         0
 uptime         5:12:27:21
 nexthop-ifname ge0/0
 nexthop-vpn    0
 status         F,S

If we try to ping an Internet IP address from vEdge-6’s VPN6, we will see that now there is Internet access in the guest VPN.  

vEdge-6# ping vpn 6 8.8.8.8
Ping in VPN 6
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=255 time=21.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=255 time=16.6 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=255 time=11.8 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 11.863/16.537/21.131/3.785 ms

Figure 5 illustrates how the NAT DIA static route works. All packets coming from VPN6, in our example from 10.6.6.0/24, are leaked from VPN 6 into VPN 0 and redirected to the NAT-enabled interface ge0/0. Then the packets are translated through the NAT Overload and sent out directly to the ISP. Within the ISP network, the packets are seen as sourced from ge0/0’s public IP address.

Design considerations

There a few design considerations that must be taken into account when we want to deploy NAT DIA static routes in production environments:

• If a routing protocol such OSPF or EIGRP is running on the service-side VPN, the default NAT DIA route must be redistributed into the routing protocol.
• The NAT DIA static route has an administrative distance of 6. OMP has an AD of 250/251. Therefore, the NAT DIA route will override any default routes received via OMP. 
• The NAT DIA static route is never advertised to vSmart via OMP and subsequently never distributed to other WAN edge routers that run the same VPN.

The static NAT DIA route approach is a very simple and effective way to enable Internet access to VPNs that are restricted from communicating over the overlay fabric. However, this method does not give us the granular control and scalability that centralized data policies can provide. For example, allowing local breakout to specific clients matched by L3/L4 information or particular applications matched by L3/L4/L7 information is not feasible with a default NAT DIA static route. For such a high level of granularity, we need to use a data policy.

Let’s now delete this static route on vEdge-6 (under vpn6 > no ip route 0.0.0.0/0 vpn0) and log in to vSmart, so we can start configuring a new data policy.

Method#2: DIA using a Centralized Data Policy

A more powerful approach to direct Internet access at branches utilizes centralized data policies, as shown in figure 6.

We are going to configure a simple data policy that only allows Internet access to one IP address from each guest subnet. This is a common real-world use case, where only a single proxy server is given access to the Internet and all end clients within that segment are being proxied through that server for security reasons. In our particular example, the IP address 10.x.6.4/32 will be the proxy server on each guest segment, where x is the vEdge number. For example, on vEdge-6 the subnet would be 10.6.6.0/24 and the idea is illustrated in figure 7 below.