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.
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.
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.
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:
Then we go to VPN lists and create a new one named VPNS-EXCEPT-FOR-GUESTS that includes ids 1,3-65000.
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.
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.
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:
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.
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.
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.
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