In the previous lab, we provided direct Internet access (DIA) to the proxy servers in the guest VPN 6 so that guest clients can be proxied to the Internet. However, there is still one traffic optimization that we can make before moving on to another use case. Because we did not specify any destination when matching packets in the current data policy. All traffic flows from the proxy servers are being leaked into VPN 0 and forwarded to the Internet, including packets destined to private IP addresses such as 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 (RFC1918). If we check the forwarding decision to destination 192.168.10.10 using the “show policy service-path” command, we will see that such traffic would be sent out via interface ge0/0 to the ISP. This spends unnecessary bandwidth and resources. 

vEdge-6# show policy service-path vpn 6 \
interface ge0/5 source-ip 10.6.6.4 dest-ip 192.168.10.10 protocol 1
Next Hop: Remote
  Remote IP: 39.3.1.1, Interface ge0/0 Index: 4

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).

Lab topology
Figure 1. Lab topology

In lab#1, we have enabled Direct Internet Access (DIA) to VPN 6 (Guests) on the spoke vEdge routers. No other centralized data policy is applied.

Configuring VPN-wide Access Control List (ACL)

In this lab example, we are going to drop any traffic coming from the guest VPN destined to private IP addresses. To achieve this, we will configure a data prefix list named RFC1918 that matches the three major private address spaces.

 lists
  data-prefix-list RFC1918
   ip-prefix 10.0.0.0/8
   ip-prefix 172.16.0.0/12
   ip-prefix 192.168.0.0/16
  !

Then we will configure a new match-action sequence in the data policy where we will match the RFC1918 data prefix-list and specify the action “drop.” It is important to emphasize again that the match–action statements are processed in sequential order. The configured action is performed when a match occurs, and the sequential processing does not continue further down. If a match does not occur, the configured entity is subject to the default action at the end of the policy.

Having that in mind, we will configure the new match-action clause before sequence 11; otherwise, the traffic coming from the proxy servers will be matched at sequence 11, and the sequential process will not go further down.

 data-policy DATA-POLICY-TO-SPOKES
  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
   !
   default-action accept
  !

The new sequence is as simple as matching packets destined to an RFC1918 address and specifying a drop action. As you recall from the previous lab example, the data policy is applied to site-list SPOKES in the “from-service” direction. Therefore, it will act on any packets received on any interface configured in VPN 6 on any spoken routers, as illustrated in figure 2 below. 

VPN Wide Access Control List (ACL)
Figure 2. VPN Wide Access Control List (ACL)

Once we commit the changes, we can check the forwarding decision for packets destined to private IP addresses. You can see that a packet sourced from VPN 6 destined to 192.168.10.10 would be blackholed while traffic to any public IP address would still be sent out to the Internet.

vEdge-6# show policy service-path \
> vpn 6 interface ge0/5 source-ip 10.6.6.4 dest-ip 192.168.10.10 protocol 1
Next Hop: Blackhole

vEdge-6# show policy service-path \
> vpn 6 interface ge0/5 source-ip 10.6.6.4 dest-ip 8.8.8.8 protocol 1    
Next Hop: Remote
  Remote IP: 39.3.1.1, Interface ge0/0 Index: 4

The key point of this lab example is to emphasize that a data policy acts on an entire VPN and is not interface-specific.