Cisco SD-WAN access list and application firewall is to filter data traffic as in non-SDN network environments. In this section we learn how to filter data traffic in network and transport layer and also application layer with the help of native cisco SD-WAN application firewall.
Cisco SD-WAN Policy Overview
Before we start configuring, let’s review SD-WAN policy types and what we have learned so far an what we will learn in the next few sections.
As you know, there are two types of policies, centralized policy where policy is applied to the vSmart controller and localized policy where the policy is applied directly to WAN edge routers.
For each type of policy, we have different applications in control plane or data plane. We have already implemented two application policies, both in control plane. one through centralized policies to create different SD-WAN topologies and the other through localized policies to manipulate routing updates.
In this section we see our first policy which will be applied at data plane. This policy is used to filter data traffic. Although it seems that data traffic filter needs to be implemented in localized policy and be applied directly in WAN edge routers, but here it is implemented through a centralized policy and vSmart controller.
although we are implementing traffic filter in vSmart controller, but final policy is pushed to WAN edge routers. Otherwise it is not possible to implement traffic filter since data traffic never goes through vSmart controller.
Topology Overview
This is the topology we prepared in the previous section where all branch offices have non-direct Internet access through IPsec tunnel with Site1 that already has direct Internet access.
As an example, I have prepared a computer in Site4 that has internet access through Site1. Before starting traffic filter, we make sure that there is an internet connection on this computer by checking icmp, telnet connection and also teamviewer as an application.
C:\Users\raykaremote>ping 8.8.8.8
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=59ms TTL=104
Reply from 8.8.8.8: bytes=32 time=55ms TTL=104
Reply from 8.8.8.8: bytes=32 time=51ms TTL=104
Reply from 8.8.8.8: bytes=32 time=53ms TTL=104
At the moment there are no restrictions in connectivity but we will filter icmp traffic with 8.8.8.8, telnet traffic with 172.16.11.2 and also teamviewer. I am testing Teamviewer because we will be filtering Teamviewer in application layer unlike icmp and telnet traffic which will be filtered in network and transport layer.
Cisco SD-WAN access list and Firewall Configuration
configure lists
To start configuring Application Firewall, first we have to create our required lists which will be used in the policy.
CONFIGURATION -> POLICIES -> Centralized Policy -> Custom Options -> Lists -> Data prefix -> New Data Prefix List
Data Prefix List Name: LANs
Add Data Prefix: 172.16.0.0/16
Data Prefix List Name: NET_8_8_8_8
Add Data Prefix:8.8.8.8/32
Data Prefix List Name: NET_172_16_11
Add Data Prefix: 172.16.11.0/24
Application List Name: teamviewer
Application: TeamViewerEnable NBAR
To enable filtering teamviewer in application layer, we have to enable ”nbar” (network based application recognition).
CONFIGURATION -> POLICIES -> Localized Policy -> cEdge_Policy -> Edit -> Policy Overview -> Set "Application" option
With enabling nbar feature, “app-visibility” command will be enabled in Edge routers.
policy
app-visibility
interface GigabitEthernet3
ip nbar protocol-discoveryconfigure data traffic filter policy
Now we can start to write our traffic filter policy. As I have said earlier, we implement data plane traffic filter and application firewall through centralized policy.
I choose the name “ACL_from_Services”, since it filter the traffic when passes from Service VPN into WAN infrastructure. of course, it is possible to filter traffic when it comes from WAN infrastructure to Service VPN.
As you can, in vSmart controller and in data plane, in addition to application firewall, it is also possible to implement other policies like QoS, Service Chaining and Traffic Engineering. some of them will be discussed in next sections.
CONFIGURATION -> POLICIES -> Centralized Policy -> Custom Options -> Traffic Policy -> Traffic Data -> Add Policy -> Create New
Name: ACL_from_Services
Description: ACL_from_Services
Sequence Type: Application Firewall (QoS, Service Chaining, Traffic Engineering, custom)
Sequence 1:
Match:
Protocol: 1
Source Data Prefix List: LANs
Destination Data Prefix List: NET_8_8_8_8
Action:
drop
Counter Name: icmp_drop
Sequence 2:
Match:
Protocol: 6
Source Data Prefix List: LANs
Destination Port: 23
Destination Data Prefix List: NET_172_16_11
Action:
drop
Counter Name: telnet_drop
Sequence 3:
Match:
Applicatio: teamviewer
Action:
drop
Counter Name: teamviewer_drop
Default Action: AcceptIn next step, our policy must be applied in vSmart controller.
CONFIGURATION -> POLICIES -> Centralized Policy -> vSmart_Policy -> Edit -> Traffic Rules -> Traffic Data -> Add Policy -> Import Existing -> ACL_from_Servicesas you know final policy must be pushed directly to WAN edge routers. so we have to configure, to which sites, this policy must be applied and in which direction, from Service VPN to WAN Infrastructure or from WAN infrastructure to VPN Service?
We apply it to all spokes and in the direction, from Service VPN to WAN Infrastructure.
# go to Policy Application Tab
Policy Application Tab -> Traffic Data -> New Service List and VPN List -> From Service
Select Site List: SPOKES
Select VPN List: VPN10Before activating policy , we can preview native Viptela commands
viptela-policy:policy
data-policy _VPN10_ACL_from_Services
vpn-list VPN10
sequence 1
match
protocol 1
source-data-prefix-list LANs
destination-data-prefix-list NET_8_8_8_8
!
action drop
count icmp_drop_1388732384
!
!
sequence 11
match
protocol 6
source-data-prefix-list LANs
destination-port 23
destination-data-prefix-list NET_172_16_11
!
action drop
count telnet_drop_1388732384
!
!
sequence 21
match
app-list teamviewer
!
action drop
count teamviewer_drop_1388732384
!
!
default-action accept
apply-policy
site-list SPOKES
data-policy _VPN10_ACL_from_Services from-serviceNow we can save and activate the policy.
The policy must be pushed from vSamrt controller to WAN edge routers. we can check it with commands:
cEdge4#show sdwan policy from-vsmart lists
from-vsmart lists vpn-list VPN10
vpn 10
from-vsmart lists data-prefix-list LANs
ip-prefix 172.16.0.0/16
from-vsmart lists data-prefix-list NET_172_16_11
ip-prefix 172.16.11.0/24
from-vsmart lists data-prefix-list NET_8_8_8_8
ip-prefix 8.8.8.8/32
from-vsmart lists data-prefix-list teamviewer
app-list Teamviewer
cEdge4#show sdwan policy from-vsmart data-policy
from-vsmart data-policy _VPN10_ACL_from_Services
direction from-service
vpn-list VPN10
sequence 1
match
source-data-prefix-list LANs
destination-data-prefix-list NET_8_8_8_8
protocol 1
action drop
count icmp_drop_-1118663109
sequence 11
match
source-data-prefix-list LANs
destination-data-prefix-list NET_172_16_11
destination-port 23
protocol 6
action drop
count telnet_drop_-1118663109
sequence 21
match
app-list teamviewer
action drop
count teamviewer_drop_-1118663109
default-action acceptIf we check the connectivity again from the computer in Site4, we expect that no icmp to 8.8.8.8, no Telnet connection to 172.16.11.2 and no Teamviewer connection should be possible. But ping with 4.2.2.4 must be possible.
C:\Users\raykaremote>ping 4.2.2.4
Pinging 4.2.2.4 with 32 bytes of data:
Reply from 4.2.2.4: bytes=32 time=114ms TTL=44
Reply from 4.2.2.4: bytes=32 time=97ms TTL=44
Ping statistics for 4.2.2.4:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 97ms, Maximum = 114ms, Average = 105ms
Control-C
^C
C:\Users\raykaremote>ping 8.8.8.8
Pinging 8.8.8.8 with 32 bytes of data:
Request timed out.
Request timed out.And finally we can check drop counters to make sure that traffic matches our access control policy.
cEdge4#show sdwan policy data-policy-filter
data-policy-filter _VPN10_ACL_from_Services
data-policy-vpnlist VPN10
data-policy-counter default_action_count
packets 438
bytes 95253
data-policy-counter icmp_drop_1645468881
packets 1
bytes 189
data-policy-counter telnet_drop_1645468881
packets 0
bytes 0
data-policy-counter teamviewer_drop_1645468881
packets 102
bytes 7455