Controllerless Networks

Hey all,

I've been charged with the task of creating a WPA2-PSK network for VoIP. We're doing this to prevent any non-SIP traffic from being dropped, and the offending device not engaging in SIP-based activites blacklisted from all SSIDs attached to the controller.

I've looked over both the Controller based and Instant based User notes and have found a fair number of sip, sip-dns, sip-dhcp, and other sip related commands, but wanted to see if anyone had already done this and could lend their experience to this scenario so that I could save some time without having to prove out something that'd already been done before. I couldn't find a test case, so I wanted to reach out here to see if someone had already done it.

I know that this can probably be facilitated by assigning a role with sip-only rules to whatever attaches itself to the network, but I'm not sure in what combo (sip and/or sip-dns and/or sip-dhcp, etc. etc.) I should create this profile. Any advise, tips, or assistance would be greatly appreciated. Keep in mind I'd need to know how to do this for both a Controller-based and Instant-based scenario

Thank you!

Ryan

Because Aruba is role based, there is no need to create another network just for Voice.  Everything can be converged onto less SSIDs and the criteria for creating other networks is based on encryption type and not necessarily based on devices accessing the network.  For example, WPA2-Enterprise (802.1x), WPA2-PSK, and open (guest).

To fully answer your question, the access rights with QoS is needed to properly define this role for the VoIP phones.  In that way, you can create the role and apply only permits for the protocols and destinations needed for the phones and drop everything else.  In addition to the permits, Aruba can put QoS priority tags on this traffic and handle appropriately both internally as well as making sure marking is correct heading upstream of our system.

Regardless of Instant or Controller, the role and permissions can be identical albeit the implementation of each will vary slightly.  

Thanks, Seth.

I'm aware that you don't have to create a new SSID in order to facilitate SIP-only traffic, but the encryption type required for a couple of devices does not match our requirements security-wise in order to collapse it into our main production SSID, so I'll have to create a new one.

Also, while I understand the theory and practiced method of allowing only SIP traffic, I was more or less asking for a walkthrough as to where I could go to look for the appropriate commands, for both a controller-based and non controller-based solution, and what to consider before having to flesh out something via extensive testing in our lab. I'm looking more for specifics and less for propositions; I've read all of the VoIP info that Aruba has to offer, but I'm still finding myself looking for more information before I proceed. Anything else that you can contribute would be greatly appreciated.

Thank you,

Ryan

OK.  Well, to start in the Controller UI, take a look at Access Control under the Configuration tab.  In order to write out a role for these phones, I would need to know what traffic they need to run other than SIP.  Here is a brief sumary of my thoughts on this.

In our system, a role is a "stack" of policies.  In the policies, there are the actual rules (permits/denies/QoS/etc).  So, starting from the top down, here is how I would tackle this.

Controller based

First, proceed with defining your detination aliases.  This is done to minimize the rules in the policies but to also make things more modular in the future. By using aliases, you can edit them, add to them, delete entries without having to re-write the policy. It's very handy.  

1. Alias for SIP servers

2. Alias for DNS servers

3. Alias for internal networks (usually RFC 1918 addresses)

This is how that would look in the CLI

netdestination SIP-Servers

  host 192.168.1.10

  host 192.168.1.11

netdestination DNS-Servers

  host 192.168.1.15

  host 192.168.1.16

netdestination internal-nets

  network 10.0.0.0 255.0.0.0

  network 192.168.0.0 255.255.0.0

  network 172.16.0.0 255.240.0.0

Second, define the Control traffic needed to get the phone up and operational such as

1. allow dhcp

2. allow bootp

3. allow ICMP

4. allow DNS to DNS servers

5. Deny things like DHCP server port and certain subnets

That would look like this in the CLI

ip access-list session logon-control

  user any udp 68  deny 

  any any svc-icmp  permit 

  any alias DNS-Servers svc-dns  permit 

  any any svc-dhcp  permit 

  any network 169.254.0.0 255.255.0.0 any  deny 

  any network 240.0.0.0 240.0.0.0 any  deny

Third, Define the SIP-VoIP policy and place in the high queue

This is a short example as there may be other protocols needed here.

ip access-list session sip-acl

  any alias SIP-Servers svc-sip-udp  permit queue high 

  any alias SIP-Servers svc-sip-tcp  permit queue high

Last, create the role for voice

user-role voice

 access-list session logon-control

 access-list session sip-acl

Instant (IAP) Based

Same theories apply but the implementation is a bit different.  All policies are written under the role name.  There is no concept of "stacking" firewall policies like the controller has.  There is also no concept of creating aliases.  

So, under the role, you will have a complete list of rules with the appropriate IP addresses or subnets for destinations.  The thing to keep in mind is that you will need to select the appropriate priority for the packets based on the rules you are writing if they are unmarked (DSCP, 802.1p values).  Also, for all VoIP traffic, tick off "Classify Media" to ensure it goes into the right queue.

Seth,

This is exactly what I was looking for. I will use this to build it out, test it, and let you know what I find. Wonderful! Kudos to you, good sir. Thank you very much for putting this together.

Thank you,

Ryan