Higher Education

I'm interested in exploring the repercussions of turning *off* wireless client isolation and I'm curious to know other peoples' experiences.  We have been getting more requests/complaints that one wireless device can't communicate with another wireless device.  

 

We currently have ~2k APs with approximately 10k users per day.  These devices are load balanced in a VLAN pool of 10 /22 networks.  I fear that turning off isolation will unload a slew of broadcast traffic on our APs and measurably degrade performace.  

 

Specific Questions:

Has anyone in a large network turned off client isolation? To what effect?

Is there a way to limit broadcast traffic? (to just ARP I guess, is there other broadcast traffic necessary?)

Can anyone think about a reasonable way to test this change without swamping the entire network?

Is there another solution to the problem I haven't thought of?

 

If this is a controller, enabling Broadcast filter All  (block Broadcasts and Unknown multicast) on your Virtual APs will suppress all broadcasts.  Enabling Deny inter user bridging will not suppress all broadcasts.

 

Deny inter user is probably what is blocking your clients connectivity to each other....

You misunderstand.  I know that wireless client isolation is on and I know how to turn it off.  I am asking how do I turn it off without melting my network.  10k devices broadcasts for who-knows-what reasons is a lot of traffic to bounce around the air.

You are right.  I don't understand.  

 

I will say that there are many people running large networks without client isolation enabled.  Client isolation cannot block clients sending out a broadcast.  It can only block clients attempting to unicast traffic to each other.

IMO client isolation does provide some good protection for recent security related events like the WannaCry ransomware attack.  Otherwise you could setup ACLs to provide some additional protections on some high risk ports, etc between wifi clients and disable client isolation.

 

Personally in my environment I like the added protection of isolation and we clearly state this in our AUP.

You do not understand.

Small vlans in a pool used to be the best way to control broadcast traffic. the "drop broadcast & multicast" option is not the best way.

We do not do client isolation and have clients on /16 networks with no broadcast issues.

Try it, you'll like it! :D

 

You can turn off just broadcasts/multicast without hurting ARP.  We've been running with this on all vlans for forever with big flat VLANs.

 

vlan XXX

   ip local-proxy-arp
   bcmc-optimization

 

wlan virtual-ap XXX

   broadcast-filter all

 

Then look into AirGroup if the users want to discover their gadgets.  ISTR setting an option that allows same-username devices to multicast to each other is dead simple and doesn't get into the weeds at all.  Then you can work up from there, being careful not to let the punk in the next room over screenshare offensive material to someone's unsecured TV just because he's on the same AP.

 

And to further the point, Aruba has been recommending a single vlan, no matter the size, with the settings configured the way bjulin posted about, for the past few years.  The reason being, vlans do not limit broadcast traffic on the wireless side the way that they limit it on the wired side.  If a single client is connected to an AP from VLAN 100, that AP will broadcast that to all clients connected to the AP, regardless of the VLAN that they are on.  However, if you make the optimizations that are recommended, then of course that behavior will not occur.

 

If I am mistaken with this information, please let me know.

---

@pmauretti wrote:

And to further the point, Aruba has been recommending a single vlan, no matter the size, with the settings configured the way bjulin posted about, for the past few years.  The reason being, vlans do not limit broadcast traffic on the wireless side the way that they limit it on the wired side.  If a single client is connected to an AP from VLAN 100, that AP will broadcast that to all clients connected to the AP, regardless of the VLAN that they are on.  However, if you make the optimizations that are recommended, then of course that behavior will not occur.

 

If I am mistaken with this information, please let me know.

---

You are mistaken.

The reason Aruba first introduced vlan pools was to reduce broadcast traffic. That is handles much better now with the "drop broadcast and multicast" settings.

Well, the real reason to do it is to intentionally break all the living-room-ware before it can cause problems.  Not having your network drown in a sea of discovery protrocols is just a side-benefit :-)

 

But to put a less cynical, technically pretty spin on it: First you make your network a NBMA topology.  Then, if you want, use AirGroup to introduce BC/MC domain that is completely decoupled from the legacy IP netmask.

 

VLAN pools probably still useful if you can't come up with consecutive IP addresses.

Is there a good link to reference on best practices for this topic? We
are reviewing our deployment and I want to follow the best practices
recommend by Aruba Networks / Airheads Community. Any help toward that
end is greatly appreciated.

---

@plroybal wrote:
Is there a good link to reference on best practices for this topic? We
are reviewing our deployment and I want to follow the best practices
recommend by Aruba Networks / Airheads Community. Any help toward that
end is greatly appreciated.

---

What are your needs?  Topics are general, your specific needs are specific.  Many users ask about best practices, but best practices are always so general.  Many users do not state what is really needed to apply a best practice to their environment, and they end up breaking their networks by cherry-picking some best practices.  Please be specific about what your challenges are and we can give some advice..

---

@bosborne wrote:

---

@pmauretti wrote:

And to further the point, Aruba has been recommending a single vlan, no matter the size, with the settings configured the way bjulin posted about, for the past few years.  The reason being, vlans do not limit broadcast traffic on the wireless side the way that they limit it on the wired side.  If a single client is connected to an AP from VLAN 100, that AP will broadcast that to all clients connected to the AP, regardless of the VLAN that they are on.  However, if you make the optimizations that are recommended, then of course that behavior will not occur.

 

If I am mistaken with this information, please let me know.

---

You are mistaken.

The reason Aruba first introduced vlan pools was to reduce broadcast traffic. That is handles much better now with the "drop broadcast and multicast" settings.

---

I won't go too much into the history of why what was added and when, but if you simply pool VLANs and do not drop broadcasts, like another user posted, users will simply encounter broadcast traffic from VLANs that they are not even part of, which would not happen on a wired network.  VLAN pooling was added specifically so that you can easily add ip infrastructure without changing existing infrastructure.  With regards to broadcast suppresssion, Enabling "Drop Broadcast and Unknown Multicast" plays probably the most significant role in suppressing broadcasts, which can cause as much degradation or even more than co-channel interference.  Aruba has also released a Validated Reference Design about Single VLAN Architecture, the challenges that are faced and the knobs that should be turned on the Aruba infrastructure here:  http://community.arubanetworks.com/t5/Validated-Reference-Design/Single-VLAN-Architecture-for-WLAN/ta-p/257196 Included in that document are discussion of little known knobs like suppress-arp, which prevents the ARP table of clients from being flooded when they are a part of a large single VLAN infrastructure.  On top of this, like another poster remarked, you can also employ multicast protocols like MDNS and Airplay or Airprint, if you deploy Airgroup on top of this.  You can even deploy multicast delivery for any devices that subscribe to a multicast group (Drop Broadcasts and Unknown Multicast).

 

This is all general inormation, so what I am trying to understand is what the original poster's needs are so that he can make the best decisions for his environment.

A comment on the reference design: it oversells identity-based firewalling.  Once you have the relevant broadcast and multicast filtering rules applied, you can indeed have clients on different VLANs on the same SSID (and VLANs that span SSIDs as well.)

 

We've found that being able to do the math in your head as far as knowing what policy a host is under is pretty invaluable.  Having to scurry off to a management console and look up a client to see what dynamic role they are in slows diagnosis down a whole lot.  It's much better if you can say "Oh, the third octet in the IP is 3, that's a professional staff member" or whatnot.  Even helpdesk staff can sometimes be taught such things (depending on the quality of your helpdesk staff, this may require pavlovian techniques, but it is generally doable.)

 

The only real major drawback to multiple VLANs is when you want to configure AirGroup for a protocol that is hardcoded to ignore things outside what it thinks its broadcast domain is.

 

Of course, if you can figure out how to assign different ranges to different clients while keeping them in the same VLAN, you can have your cake and eat it too.

 

bjulin,

 

It is definitely NOT a "one-size-fits-all".  Rather it is a list of things that can be done.  Whatever works for an environment and the admins that needs to run it, is a good idea.  If it is implemented blindly, it is a bad idea.

 

Everyone should NOT do everything in the guide.  Ideas should be tested in the lab to  see what works, and then what works should be evaluated to move to production.  That is the spirit of network design.

Dear colleagues, I have the issue with deny inter-user traffic feature on my Aruba 7205 Controller. Actually i've did all as described in user guide, but still no luck. I have vlan 1000 and external DHCP/Gateway in this vlan, which serve ip address and internet access to wireless users. Everything works ok, but as per our security regulation - l2 inter-user communication has to be denied. After enabling "deny inter-user traffic" under the AP profile - i'm not able to obtain ip address from my access gateway. Port is int trunk mode, vlan 1000 is untrusted. Wireless users assigned to "logon" role and wired devices are in guest role. It seems that desired isolation can be achieved just by couple of clicks, but still cannot catch why it doesn't work for me? Never had such a problem with another vendors. 

P.S. Desired network topology in attachements. Controller without PEF license.

P.P.S. Sorry for posting it in here, i'm newcomer ))

Client isolation is a firewall feature and requires PEF licenses.

I've upgraded my feature set on WLC, so now i have PEF-NG license enabled , but still no luck with client isolation. Actually after enabling "Deny inter-user traffic"  feature (both under VAP or globally) - wireless clients lose connectivity to DHCP (which is connected to WLC by wire). All VLANs on WLC are in "untrusted" mode. Wired and Wireless clients assigned to different user roles, no acl's that could entail packet drops. 

Can't understand what's wrong with Aruba ? Why so pretty simple function require such a tons of actions.... 

---

@sgulyamov wrote:

I've upgraded my feature set on WLC, so now i have PEF-NG license enabled , but still no luck with client isolation. Actually after enabling "Deny inter-user traffic"  feature (both under VAP or globally) - wireless clients lose connectivity to DHCP (which is connected to WLC by wire). All VLANs on WLC are in "untrusted" mode. Wired and Wireless clients assigned to different user roles, no acl's that could entail packet drops. 

Can't understand what's wrong with Aruba ? Why so pretty simple function require such a tons of actions.... 

---

The Aruba firewall is a powerful feature and must be configured before it is deployed. The configuration is not "simple" because the feature is so flexible and powerful.

Default acls on roles are to deny all traffic, for security reasons.

I've changed the roles and associated policies (allow all) before posting this issue in here. 

If you change the deny rules in the policy to "log", you can do "show log security all" and review where any drops are coming from. Another issue I've seen is if your dhcp server IPs show up as an entry in your user table, then traffic to/from those servers will be policed by the controller as well.

Finally, "show datapath session table _ipaddress_" will give you a list of all flows associated with that IP. Entries with the "D" flag are denied. "C" flags show who initiated the session. "Y" flags are reciprocated traffic flows that haven't yet received packets. This command can be helpful for diagnosing traffic reachability issues.

===========
Ryan Holland
(sent while mobile)

Thank you Ryan, helpful info. However i have only one policy enabled in my roles (both wireless and wired)  -  "allow all". All i need - just to completely isolate wireless clients from each other (even ARPs should be denied), but wired devices in the same VLAN should be reachable by wireless clients. Rest of wired security policies are implemented on security appliance, not on WLC.  That's why i just turned on  "inter-user isolation", and supposed that that's enough.  

Assuming ArubaOS 6.4.x you are unclear what you enabled.

 

Deny Inter User Bridging

Deny Inter User Traffic

or both?

 

According to the User Guide, there is no "inter-user isolation" option.

 

We have both options turned off in our environment. Unless your wired traffic is tunneled through the controller oto, users coud just access each other over wired.

Assuming ArubaOS 6.4.x you are unclear what you enabled.

 

Deny Inter User Bridging

Deny Inter User Traffic

or both?

 

According to the User Guide, there is no "inter-user isolation" option.

We have both options turned off in our environment. Unless your wired traffic is tunneled through the controller, users could just access each other over wired.

You should contact the SE on your Aruba account team for additional assistance. They can look at your configuraton and assist as needed.

 

Another option may be to open an Aruba TAC support case.

If listing all of the vlans as untrusted that could be part of the issue as well... When marked did you apply a polciy on those vlans?