WiNG 5 How-To Guide
Role-Based Firewall
June 2011 Revision 1.0
MOTOROLA and the Stylized M Logo are registered in the US Patent & Trademark Office.
Symbol is a registered trademark of Symbol Technologies, Inc. All other product or service names are the property of their respective owners.
Table of Contents:
1. Introduction: ... 4
1.1 Overview: ... 4
1.2 Distributed Stateful Inspection:... 4
1.3 Role Based Firewall ... 5
1.4 Components: ... 7
2. Use and Configuration: ... 7
2.1 Scenario 1 ... 8
2.2 Scenario 2 ...17
3. Verification ...26
4. Troubleshooting ...28
1. Introduction:
To augment the firewall services of WiNG 5, one may add on the Advanced Security license to enable role-based firewall. The Advanced Security licensing is included with the purchase of the RFS4000 series switches for smaller wireless deployments and can be purchased as add-on licensing for the higher-end models.
Role-based firewall gives enhanced security to the standard firewall features of WiNG 5. Whereas the standard IP and MAC based firewall rules are applied to physical and logical interfaces as well as WLANs, role-based rules are applied to the wireless clients and follow them as they roam on the network.
For further information on the standard Firewall features of WiNG 5, please see the document at: http://compass.mot-solutions.com/doc/392577167/WiNG5_Firewall_How-To.pdf
1.1 Overview:
Roles allow for dynamic assignment of IP and MAC firewall rules to wireless clients based on one or more match conditions that are evaluated when the client associates to the wireless network. These dynamic rules follow the clients, being migrated to other access points as the clients roam. If a role is established that would affect already connected clients, these roles will be evaluated immediately and put into effect against the client traffic.
Match criteria include:
Location: AP or group of AP’s the wireless client is connected to
Authentication: The authentication method used by the client during association Encryption: The encryption type used by the client (not configured on the WLAN) Group Membership: The local group the wireless client is assigned to as obtained from
AAA
Captive Portal Authentication State
MAC Address: MAC address or range of the wireless client(s) SSID: The SSID the wireless client is associated to
1.2 Distributed Stateful Inspection:
The major new feature in WiNG 5 is distribution of services or services at the edge. Since controllers and access points alike run the same OS and thus feature set, processing of traffic for various services is pushed to the edge where it can be performed in real-time and done so dynamically.
Figure 1: Distributed Stateful Inspection
The distributed nature of the firewall allows stateful flows to migrate with clients as they roam between access points. Rules are made up of one or more traffic matching conditions, for which an action is then performed (permit, deny, mark, log). As is the case with firewalls, at least one permit action must be met in order for traffic to be forwarded and at the end of a rule set, there is an implied deny for all traffic not meeting a match condition.
1.3 Role Based Firewall
User Roles to Security Policies Security Policies User Role Default Location Group Membership Hot-Spot State Encryption Authentication SSID MAC-Address Engineering Location Group Membership Hot-Spot State Encryption Authentication SSID MAC-Address Sales Location Group Membership Hot-Spot State Encryption Authentication SSID MAC-Address Guest Location Group Membership Hot-Spot State Encryption Authentication SSID MAC-Address Inbound ACLs ACL ACL Inbound ACLs ACL ACL Inbound ACLs ACL ACL Inbound ACLs ACL ACL
It is possible from time to time that while a role is being evaluated, multiple matches may be found. In this case, the role with the lowest precedence will be assigned to the wireless client.
For each user role administrators can define match criteria and values that can individually be ignored, matched and partially matched. For example a group name could be defined in a user role to exactly match the value Sales which would apply to all users in the Sales group. Likewise an ESSID could be defined to partially match the value Corp which would match any devices associated with the ESSIDs named CorpUsers and CorpGuest. Alternatively specific strings can be ignored by selecting a match of Not Contains or all criteria can be matched using a match condition Any.
Role based firewall requires the Advanced Security licensing on the controller, which is an added cost. The Advanced Security licensing is not shared among devices in a cluster, so in order for dynamic rules to follow a wireless client that roams from an access point on one controller in a cluster to an access point on another controller in the cluster, both controllers must have the added Advanced Security license.
1.4 Components:
The components of role-based firewall are listed below:
Firewall Rules (Access Control Lists) o IP Firewall Rules
o MAC Firewall Rules
Wireless Client Roles (Role-policy)
AAA Policy (optional based on match criteria)
1) CLI Role-Policy options
rfs4000# conf t
rfs4000(config)#role-policy firewalled-users rfs4000(config-role-policy-firewalled-users)#? Role Policy Mode commands:
default-role Configuration for Wireless Clients not matching any role no Negate a command or set its defaults
user-role Create a role
clrscr Clears the display screen
commit Commit all changes made in this session do Run commands from Exec mode
end End current mode and change to EXEC mode exit End current mode and down to previous mode help Description of the interactive help system revert Revert changes
service Service Commands
show Show running system information
write Write running configuration to memory or terminal
2. Use and Configuration:
We will examine two scenarios; an easy method based on SSID followed by a slightly more complex method based on the user’s group assignment.
During the configuration of the role-policy, the necessary IP or MAC access lists will be specified, so it is helpful to have these created already. Thus, following is a preferred order-of-configuration. This assumes that the general configuration of the wireless switch and necessary WLAN’s already exist. In the case of our second scenario, this document will also include the configuration of AAA and RADIUS policies.
1. Configure IP / MAC based access lists 2. Configure the Role-policy
2.1 Scenario 1
2.1.1 CLI Configuration
1) CLI IP Access List configuration
rfs4000# conf t
rfs4000(config)#ip access-list restricted-allow
rfs4000(config-ip-acl-restricted-allow)#permit icmp any any 8 0 log rule-precedence 10 rule-description icmp allow
rfs4000(config-ip-acl-restricted-allow)#permit tcp any any eq ssh log rule-precedence 20 rule-description ssh allow
rfs4000(config-ip-acl-restricted-allow)#deny ip any any log rule-precedence 30 rfs4000(config-ip-acl-restricted-allow)#commit write
In the above example we have created an ACL named “restricted-allow” and we are allowing ICMP echo-request traffic from the wireless clients, as specified by icmp type 8, code 0. We are also allowing SSH traffic as this will be the method of access to the wireless switch from the role-based user. Finally, we are denying any other IP traffic and logging hits.
Next we will create the role-policy and apply it to the access point profile:
1) CLI Role policy configuration
rfs4000# conf t
rfs4000(config)#role-policy firewalled-users
rfs4000(config-role-policy-firewalled-users)#user-role fw-role precedence 10
rfs4000(config-role-policy-firewalled-users-user-role-fw-role)#ssid contains vlan64 rfs4000(config-role-policy-firewalled-users-user-role-fw-role)#use ip-access-list in restricted-allow precedence 10
rfs4000(config-role-policy-firewalled-users-user-role-fw-role)#exit rfs4000(config-role-policy-firewalled-users)show context
role-policy firewalled-users user-role fw-role precedence 10 ssid exact vlan64
use ip-access-list in restricted-allow precedence 10 rfs4000(config-role-policy-firewalled-users)#commit write
2) Access Point profile application
rfs4000(config)#profile ap650 default-ap650
rfs4000(config-profile-default-ap650)#use role-policy firewalled-users rfs4000(config-profile-default-ap650)#show context
profile ap650 default-ap650 autoinstall configuration autoinstall firmware interface radio1
wlan packetstorm bss 1 primary wlan vlan64-wlan bss 2 primary interface radio2
wlan PacketStorm-5G bss 1 primary interface ge1
ip dhcp trust qos trust dscp qos trust 802.1p interface vlan1 ip address dhcp
ip dhcp client request options all use firewall-policy default
ntp server 138.236.128.112 prefer use role-policy firewalled-users logging on
service pm sys-restart
rfs4000(config-profile-default-ap650)# commit write
2.1.2 Web UI Configuration
Following the order that was previously listed, navigate to “Configuration > Security > IP
Web-UI: Adding role-based access list
Give your ACL a name and begin adding rules, clicking “+Add Row” for each new line. Web-UI: Adding ACL Rules
Web-UI: Adding ACL Rules
2.1.3 Role Policy Creation
Next, navigate to “Configuration > Security > Wireless Client Roles” and click on “Add” to create a new role policy:
Web-UI: Role Policy Configuration
Web-UI: Role Policy Configuration
As can be seen, you may select a number of variations for match criteria. We have selected an exact match on the SSID, however other options exist as shown below:
After selecting your match criteria, go to the “Firewall Rules” tab and select the previously configured IP access list or whatever firewall rules you have previously configured. Add additional rows for additional firewall rules as needed by clicking “+Add Row”
Web-UI: Adding Firewall Rules
One other note; on the “Default Firewall Rules” tab of your role policy, you may select default access lists to be applied whether or not match criteria have been met. Realize that these rules are applied at the level where the role policy has been applied (access point level). Exercise caution to ensure traffic is not interrupted inadvertently due to a default rule. In our case we have specified no defaults, as seen below:
Web-UI: Default Firewall Rules
2.1.4 Apply Policy
The final step is to apply the role policy to your devices. This will usually be done at the access point level (profile or device override) as that is the point of ingress for the wireless clients. It may also be done at an RFS4011, which has a built-in access point.
Navigate to “Configuration > Profiles” and select / edit the profile you wish to apply the role policy to. Within the profile, navigate to “Security > Settings” and select your policy from the “Wireless Client Role Policy” drop-down box:
Web UI: Applying the Role Policy
Click “>>Ok: and then Commit and Save your work.
2.2 Scenario 2
Scenario 2 is the same basic setup, except for now our match criteria will be based on group-membership as gathered from AAA. The following sections will just show the configuration of the additional components (in order of configuration), which are:
Radius Services (Server, Group, and User-pool policies) AAA Policy
2.2.1 CLI Configuration
In this scenario, we configured RADIUS in the following order (due to later configuration):
1. Group policy 2. User-pool policy 3. Radius Server policy
1) CLI Running RADIUS Configuration
rfs4000# show running-config | begin radius-group no-internet-users
radius-group no-internet-users policy ssid vlan64
policy day mo policy day tu policy day we policy day th policy day fr
policy time start 06:00 end 17:00 !
radius-user-pool-policy role-users
user user2 password 0 Password2 group no-internet-users user user1 password 0 Password group no-internet-users !
radius-server-policy local-rad-server use radius-user-pool-policy role-users authentication eap-auth-type peap-mschapv2 no ldap-group-verification
use radius-group no-internet-users
Following the radius configuration, we then create our AAA policy:
2) CLI Running AAA Policy Configuration
rfs4000# show running-config | begin aaa-policy local-aaa
aaa-policy local-aaa
authentication server 1 onboard controller authentication server 1 retry-timeout-factor 150 accounting server 1 onboard controller
Then we modify the security on our WLAN to utilize EAP and the new RADIUS / AAA policies:
3) CLI Running WLAN Configuration
rfs4000# show running-config | begin wlan vlan64-wlan
wlan vlan64-wlan ssid vlan64 vlan 64
bridging-mode tunnel encryption-type ccmp authentication-type eap use aaa-policy local-aaa
Finally, we modify our role policy that was created in the first scenario to include the new match criteria. In this way, not all users who associate to the WLAN have the role policy applied to them; only users belonging to the specified group.
4) CLI Running Role-Policy Configuration
rfs4000# show running-config | begin role-policy firewalled-users
role-policy firewalled-users user-role fw-role precedence 10 ssid exact vlan64
group exact no-internet-users
2.2.2 Web-UI Configuration
We will configure in the same order as was executed at the CLI. Navigate to “Configuration >
Services > RADIUS > Groups” and add a new group policy.
One item of note when configuring the group policy WLAN SSID – this box is for administrator-input. The SSID of your WLAN is what is needed, not the WLAN-name as WiNG 5 sees it. Ensure that the SSID is typed correctly, including case or it will be incorrect and the policy will not work. This is denoted in the screenshot below with the numbers 1 and 2:
Type in your SSID and click the down-arrow to apply said SSID to the group policy.
Navigate to “Configuration > Services > RADIUS > User Pools” and create your pool of users. When creating your users, select the RADIUS Group they are to belong to, as shown:
Web UI: RADIUS User-Pool Policy
Navigate to “Configuration > Services > RADIUS > Server Policy” and add your new RADIUS server policy. The (1) RADIUS User Pool, (2) RADIUS Group (specified LDAP Group) and (3) Authentication source and type must be specified:
Web UI: RADIUS Server Policy
Once RADIUS has been configured, we then add the AAA Policy. Navigate to “Configuration >
Web UI: AAA Policy
We now apply this new security to our WLAN; navigate to “Configuration > Wireless >
Wireless LANs” select to edit the WLAN, then navigate to “Security” in the middle working
Web UI: WLAN Authentication
Remember to Commit and Save your work as you complete these tasks.
Finally navigate to “Configuration > Security > Wireless Client Roles” and select to edit the
“firewalled-users” policy that was created for scenario 1. We will add match-criteria for the user
group and specify the “no-internet-users” group policy that was configured during the RADIUS
Web UI: Role Policy Modification
3. Verification
The configuration has been completed and now we can test. We expect that clients connecting to SSID “vlan64” will match our role-policy and will thus only be allowed to send ping requests and perform SSH based sessions.
1) CLI Role Policy Verification
rfs4000# connect ap650-85CD9C ~~~ login output omitted ~~~
ap650-85CD9C#show role wireless-clients Role_policy: firewalled-users
Role: fw-role
00-27-10-94-B8-5C
Wireless Clients not matching any Role:
1C-4B-D6-55-D0-2C 00-25-00-48-BB-AE 64-A7-69-7C-71-A5 ap650-85CD9C#
Next we will test and verify that the rules are actually working. We will initiate a ping from our wireless client to the RFS, followed by an SSH session:
Web UI: Testing the Role Policy
Web UI: Testing the Role Policy
4. Troubleshooting
Remember that the role policy has been applied to the profile for the access points. Thus, we can connect to an access point to which an expected role-based user is associating and determine if the role is being set:
1) CLI Role Policy Verification
ap650-85CD9C#show wireless client
---
MAC IP VENDOR RADIO-ID WLAN VLAN STATE
---
00-27-10-94-B8-5C 192.168.150.126 Intel Corp 00-23-68-85-CD-9C:R1 vlan64-wlan 64 Data-Ready
---
Total number of wireless clients displayed: 1
ap650-85CD9C#show wireless client detail 00-27-10-94-B8-5C
ADDRESS : 00-27-10-94-B8-5C - 00-27-10-94-B8-5C 192.168.150.126 (vlan:64) USERNAME : user2
WLAN : vlan64-wlan (ssid:vlan64)
ACCESS-POINT : Name:ap650-85CD9C Location:Gilbert, AZ RADIO-ID : 00-23-68-85-CD-9C:R1, alias ap650-85CD9C:R1 RADIO-NAME : radio1 Bss:00-23-68-73-BA-11
STATE : Data-Ready
CLIENT-INFO : 802.11bgn, vendor: Intel Corp
SECURITY : Authentication: eap Encryption: ccmp DATA-RATES : 1 2 5.5 6 9 11 12 18 24 36 48 54 mcs0-15 MAX-PHY_RATE : 300 M
MAX-USER_RATE : 225 M
802.11n : Short guard interval: Y Channel width (capability: 40Mhz Current: 40Mhz)
: AMSDU Max-Size: 7935 AMPDU Max-Size: 65535 AMPDU Min-Spacing: 0 uSec
QoS : WMM: Y Type: Non Voice
POWER-MGMT : PS-Mode: N Spatial-Multiplexing-PS: off WMM-PS/U-APSD: Disabled ACTIVITY : Last Active: 00:00.00 ago
SESSION INFO : Session Timeout: 0 days 06:08.00 Idle Timeout: 00.:30.00 RF-DOMAIN : default
MCAST STREAMS :
ROLE : fw-role/firewalled-users ap650-85CD9C#
5. Reference Documentation:
Description Location
WiNG 4 Wired / Wireless Firewall http://compass.mot.com/doc/316513023/WiNG_How_To_-_Wired_Wireless_Firewall.pdf
