Traffic isolation is a key part of the security strategy of any company these days. Network segmentation has many use cases within the business such as:

  • A company wants to keep traffic from different business verticals separate.
  • An organization wants to keep guest users separate from authenticated users.
  • An enterprise wants to grant access to partners and suppliers only to some portions of the network.
  • A company needs to enforce regulatory compliance such as ISO27001 or the Payment Card Industry (PCI) security standards.

In traditional networking, the most rudimentary forms of network segmentation are VLANs (virtual LANs) at layer 2, and VRFs (virtual routing and forwarding) at layer 3. However, these technologies are limited in scope because they are implemented in a locally significant fashion (on a single device per interface) or require complex control plane interactions to work (for example MPLS-based BGP L3VPNs). 

Cisco SD-WAN uses a simpler but more scalable approach to network segmentation using two very efficient techniques:

  • Enforcing segmentation at the edges on WAN edge routers.
  • Carrying the segmentation information in the data plane packets by inserting VPN labels that identify the network segment.

Cisco SD-WAN Pre-defined VPNs

By default, the Cisco SD-WAN solution has two pre-defined VPNs that cannot be deleted or modified: Transport VPN 0 and Management VPN 512.

Cisco WAN Edge Segmentation
Figure 1. Cisco WAN Edge Segmentation

Transport VPN 0

VPN 0 is the pre-defined Transport VPN of the Cisco SD-WAN solution. It cannot be deleted nor modified. The purpose of this VPN is to enforce a separation between the WAN transport networks (the underlay) and network services (the overlay). Therefore, all WAN links such as Internet and MPLS circuits are kept in VPN 0 as is visualized in figure 2. 

Cisco SD-WAN Transport VPN 0
Figure 2. Cisco SD-WAN Transport VPN 0

Additionally, WAN edge routers must have at least one interface configured in VPN0 in order to establish the control plane tunnels to the vSmart controllers. Each interface that is connected to the WAN must have an IP address, color, and encapsulation type configured. These parameters are then advertised to the controllers via OMP as part of the TLOC route advertisements. Typically, a default route is defined via each WAN interface. Note that in Transport VPN0, multiple default routes can exist. In the underlay routing, the actual default route that is chosen depends on the overlay tunnel that is going to be used. When the overlay routing decides to use a particular IPsec tunnel, the underlay routing uses the default route that has a next-hop IP address in the same subnet as the tunnel source IP address.

!
vpn 0
 interface ge0/0
  ip address 10.1.1.2/30
  tunnel-interface
   encapsulation ipsec
   color public-internet
 !
 interface ge0/1
  ip address 14.3.2.2/30
  tunnel-interface
   encapsulation ipsec
   color mpls
 !
 ip route 0.0.0.0/0 10.1.1.1
 ip route 0.0.0.0/0 14.3.2.1
!

Let's elaborate on that with the example shown in figure 2. When vEdge-1 forwards packets through IPsec tunnels sourced from interface ge0/0, in the underlay it will use the default route with next-hop 10.1.1.1, because the next-hop address is in the same subnet as the IP address of ge0/0 (10.1.1.2/30).

Management VPN 512

By default in Cisco SD-WAN, VPN 512 is configured for out-of-band management. It is enabled and ready-to-go out of the box.

Service VPNs

When we want to create an isolated network domain and isolate the data traffic in this domain from the other user networks onsite, we create a new service VPN on the vEdge routers. This VPN is specified by a number different from 0 (Transport) and 512 (Management). Once the network segment is created, you associate interfaces, enable routing protocols, and other network services such as VRRP and QoS within this VPN. One important thing to point out is that interfaces associated with user segments must not be connected to WAN transports.

Cisco SD-WAN VPNs
Figure 3. Cisco SD-WAN VPNs

Secure Segmentation

Each interface on a Cisco WAN edge device must be configured in a particular VPN.  All prefixes learned via interfaces or routing instances in a VPN are kept in a separate routing table. When this network information is advertised to the vSmart controller, each prefix is associated with a VPN-ID. In addition, the vSmart controller maintains the VPN context of each prefix.

Cisco SD-WAN VPN Lables
Figure 4. Cisco SD-WAN VPN Lables

This mechanism is very similar to traditional layer 3 isolation with VRFs (Virtual Routing and Forwarding). Therefore, separate route tables provide network segmentation on a single device. However, the question is how to populate this isolated routing information across the overlay domain. At the packet forwarding level, WAN edge routers will insert a new VPN label field in each IP packet. This label will identify the network segments that the packets belong to. The process is visualized in figure 4. When we configure a new VPN on a WAN edge router, it will associate a label to it. The WAN Edge device will then advertise this label along with the VPN-ID to the vSmart controller via OMP. The controller itself will then redistribute this VPN-ID mapping to the other WAN Edges device in the network. The remote WAN Edges in the network will then use these labels to send traffic for the appropriate VPNs, similarly to the label switching in MPLS.

Arbitrary VPN Topologies

Because the control plane is completely separated from the data forwarding plane, Cisco SD-WAN allows us to define different topologies per VPN. Typical topology types are full-mesh, partial-mesh, hub-and-spoke, and point-to-point. By default, if a specific topology is not defined, all VPNs will build a full mesh. Custom segment topologies can be created by using centralized control policies that filter TLOCs or modify next-hop TLOC attributes for specific OMP routes.

Cisco SD-WAN Arbitrary Topologies
Figure 5. Cisco SD-WAN Arbitrary Topologies

At this point, you might be wondering why custom topologies are important. Well, they are important because some applications may benefit from going via the shortest possible path, e.g VoIP works best in full-mesh topologies. On the other hand, some segments of the network might benefit from controlled connectivity topology such as hub-and-spoke.