The Business Need

It is pretty common that an organization has branches where guest users are permitted to connect to the network and provided Direct Internet Access (DIA). As a rudimentary security measure, the guests can be confined within their own VPN. However, by default in Cisco SD-WAN,  any-to-any connectivity within a single VPN is automatically established between all sites through the exchange of OMP routes and TLOCs. In most enterprise VPNs, this automatic any-to-any behavior is desired. However, most organizations would not want to allow guests to communicate with other guests across the overlay fabric as shown in figure 1 below.

Guest VPN on spokes
Figure 1. By default, any-to-any connectivity is established within each VPN.

VPN Membership policies are the tool that allows network administrators to prohibit the exchange of control plane information for particular VPNs and subsequently to isolate the users within a VPN from the SD-WAN fabric.

What is a VPN Membership policy?

A VPN membership policy is a special type of centralized control policy that is used to control what VPN routing tables are distributed to which particular vEdge routers. In a default SD-WAN fabric with no VPN membership policy applied, the vSmart controller advertises all OMP routes for all VPNs to all vEdge routers. However, if an organization wants to restrict the participation of specific vEdge routers in particular VPNs, a VPN Membership policy that enforces this restriction is applied to vSmart.

VPN Membership Policy
Figure 2. VPN Membership Policy

An important point to notice is that we do not set a direction when applying a VPN membership policy. This type of policy is automatically applied in an outbound direction from the perspective of the vSmart controller and affects the OMP updates sent from vSmart to the vEdge routers.

Configuring VPN Membership policies

For this lab example, we are going to use the same lab topology that we have been using through all lessons for centralized control policies. For a guest segment, we are going to use vpn_id 2.

VPN Membership Policy Lab Diagram
VPN Membership Policy Lab Diagram

As you can see in the lab topology, there is one directly connected prefix in VPN 2 on each site. If we check the routing table on any of the branch vEdge routers, we are going to see that the vSmart controller has advertised all prefixes to all routers and every vEdge knows about all networks in the guest segment.

vEdge-4# sh ip route vpn 2 | t

     ADDRESS                   PATH             PROTOCOL          NEXTHOP  NEXTHOP                                       NEXTHOP          
VPN  FAMILY   PREFIX           ID    PROTOCOL   SUB TYPE  METRIC  IFNAME   ADDR     TLOC IP      COLOR            ENCAP  VPN      STATUS  
------------------------------------------------------------------------------------------------------------------------------------------
2    ipv4     192.168.50.0/24  0     omp        -         0       -        -        50.50.50.51  mpls             ipsec  -        F,S     
2    ipv4     192.168.50.0/24  1     omp        -         0       -        -        50.50.50.51  public-internet  ipsec  -        F,S     
2    ipv4     192.168.60.0/24  0     omp        -         0       -        -        50.50.50.51  mpls             ipsec  -        F,S     
2    ipv4     192.168.60.0/24  1     omp        -         0       -        -        50.50.50.51  public-internet  ipsec  -        F,S     
2    ipv4     192.168.70.0/24  0     connected  -         0       ge0/3    -        -            -                -      -        F,S     
2    ipv4     192.168.90.0/24  0     omp        -         0       -        -        50.50.50.51  mpls             ipsec  -        F,S     
2    ipv4     192.168.90.0/24  1     omp        -         0       -        -        50.50.50.51  public-internet  ipsec  -        F,S

However, in order to isolate the guest users from communicating over the SD-WAN overlay fabric, we are going to configure a VPN Membership policy that will prohibit the vSmart controller from advertising any OMP routing information associated with vpn_id 2 to the branch sites. 

The first thing that we have to do is to create a vpn-list that matches the vpn-ids of all VPNs that we want to be permitted to communicate across the overlay fabric. As we have only got one guest segment with id 2, the vpn-list will match vpn_ids 1,3-65000 (practically every single segment except for the guest one). Let's create the list by going to Configuration > Policies > Custom Options > Lists as shown in the screenshot below:

Create a new policy list
Create a new policy list

Then we go to VPN lists and create a new one named VPNS-EXCEPT-FOR-GUESTS that includes ids 1,3-65000.

Define a new VPN list
Define a new VPN list

Once the list is configured, we need to copy the latest active control policy that is applied. We go to Configuration > Policies > Centralised Policy and click the more options. In there we select Copy.

Copy the existing Control Policy
Copy the existing Control Policy

As a general rule of thumb, we included a version number in the name of the new policy - CENTRALIZED-CONTROL-POLICY-V5, and in the description, we write a timestamp in cleartext. 

Set up a new name for the control policy
Set up a new name for the control policy

You can see the new policy is created but is not activated yet (The activated value is false). Before we push it to vSmart, we need to edit it and create a new VPN Membership policy that achieves the objectives of this lab example. We go to the more options button and select Edit, as shown in the screenshot below:

Edit the new policy
Edit the new policy

Once we enter the Edit Policy menu, we go to the Topology tab and then to the VPN Membership subtab. In there, we specify a name and description of the VPN membership policy. Then we select a site-list that identifies which WAN edge routers will be affected by the membership policy and a vpn-list that identifies which VPN routing tables will be sent to these vEdges. In our example, we are going to apply the policy to site-list SPOKES and will use the vpn-list that we have created earlier in the lesson.

Add a new VPN Membership Policy
Add a new VPN Membership Policy.

Once the VPN Membership policy is configured, we can go ahead and activate the latest version of the Centralized Control Policy. This is done by going to the more options and selecting Activate as shown below. 

Activate the new control policy
Activate the new control policy

Once the policy is activated, vManage pushes it to the vSmart controller using a NETCONF transaction. If the policy is successfully applied, it becomes part of vSmart's running configuration, and vManage lets us know that the activation is successful.

The new policy is successfully activated
The new policy is successfully activated.

Checking the results

Before we applied the VPN Membership policy, we had checked the VPN-2 routing table of vEdge-4 and saw that the router knew about every network within the guest segment. However, if we check the routing table now, we are going to see that the router has not received any OMP routes for VPN 2 at all. It only knows about its own directly connected subnet at the moment.

vEdge-4# sh ip route vpn 2 | t

     ADDRESS                   PATH             PROTOCOL          NEXTHOP  NEXTHOP                         NEXTHOP          
VPN  FAMILY   PREFIX           ID    PROTOCOL   SUB TYPE  METRIC  IFNAME   ADDR     TLOC IP  COLOR  ENCAP  VPN      STATUS  
----------------------------------------------------------------------------------------------------------------------------
2    ipv4     192.168.70.0/24  0     connected  -         0       ge0/3    -        -        -      -      -        F,S

However, if we check any other VPN we are going to see that the router has received every OMP route that is available in the overlay fabric.


vEdge-4# sh ip route vpn 1 | t

     ADDRESS                  PATH             PROTOCOL          NEXTHOP  NEXTHOP                                       NEXTHOP          
VPN  FAMILY   PREFIX          ID    PROTOCOL   SUB TYPE  METRIC  IFNAME   ADDR     TLOC IP      COLOR            ENCAP  VPN      STATUS  
-----------------------------------------------------------------------------------------------------------------------------------------
1    ipv4     0.0.0.0/0       0     omp        -         0       -        -        50.50.50.51  mpls             ipsec  -        F,S     
1    ipv4     0.0.0.0/0       1     omp        -         0       -        -        50.50.50.51  public-internet  ipsec  -        F,S     
1    ipv4     172.16.50.0/24  0     omp        -         0       -        -        50.50.50.51  mpls             ipsec  -        F,S     
1    ipv4     172.16.50.0/24  1     omp        -         0       -        -        50.50.50.51  public-internet  ipsec  -        F,S     
1    ipv4     172.16.60.0/24  0     omp        -         0       -        -        50.50.50.51  mpls             ipsec  -        F,S     
1    ipv4     172.16.60.0/24  1     omp        -         0       -        -        50.50.50.51  public-internet  ipsec  -        F,S     
1    ipv4     172.16.70.0/24  0     connected  -         0       ge0/2    -        -            -                -      -        F,S     
1    ipv4     172.16.90.0/24  0     omp        -         0       -        -        50.50.50.51  mpls             ipsec  -        F,S     
1    ipv4     172.16.90.0/24  1     omp        -         0       -        -        50.50.50.51  public-internet  ipsec  -        F,S