Security

Using IAP, is it possible to have a guest network that uses mac auth, without requiring users to interact with a portal when connecting? The goal here is to replicate the configuration of our old WiFi solution so that users won't have to enter new information into their devices or do anything differently.

 

WLAN "Secure" clients are assigned to VLAN1. There is a single PSK for this WLAN. This is for company-owned devices.

 

WLAN "Insecure" clients are assigned to VLAN2. There is a different PSK for this WLAN. This is for BYOD.

 

In addition to the PSK, each WLAN has a set of MACs that are allowed to associate with it. (It would be okay for Secure clients to access the Insecure WLAN, but it would not be acceptable for Insecure clients to access the Secure WLAN. This needs to be enforced at the MAC level since all employees have access to the PSKs. Yes, I am aware that MAC-based filtering isn't the greatest, but it's what I need to have right now.)

 

So far I've created MAC-based accounts in the internal AAA server for the Secure clients (defined as type "Employee" in the GUI, "radius" in the CLI) and for the Insecure clients ("Guest"/"radius"). Then I created a WLAN of type "Employee" with MAC auth. This is fine--it only allows the Secure clients to associate.

 

But when I create a WLAN of type "Guest" for the Insecure clients, I have to choose one of the captive portal options before I can select MAC-auth.

 

In the CLI it's possible to have the necessary combination of options, e.g.

 

[...]

 

But I haven't tested whether this works. I'm also concerned that the config could be overwritten by the web admin interface.

 

Any advice? Would it be possible to create a "dummy" external captive portal config?

 

Failing that, how can I get the best performance in a simple "Acknowledged" captive portal? What I'm seeing right now is just as bad as what I often get in public free WiFi locations--it takes forever for an iOS device to display the splash page with an "Accept" button.

 

You can just use the employee preset instead of guest and it should let you do open with MAC-auth. 


Thanks, 
Tim

I don't think that will work for me. If I use the employee preset I do have that option but then accounts marked as guest cannot associate.

If I go ahead and change those accounts to employee then they will be able to associate with the Secure WLAN, which is not acceptable.

you talk about PSK and MAC auth and then suddenly start about guest accounts and employ accounts.

 

where do the accounts come from?

 

the names IAP uses are just names. even for guests you can create a employee "type" network based on PSK and MAC auth. guest "type" probably always adds some form of captive portal.

You're right: the terms we use to classify the two groups of machines don't matter.

 

What does matter is that both groups need to be authenticated via MAC and PSK AND GroupB can't be allowed to use the same WLAN/VLAN as GroupA even if they get hold of the GroupA PSK.

 

The simple way to do this is to assign GroupA to an Employee WLAN and GroupB to a Guest WLAN, then set up the corresponding clients as Type Employee and Type Guest within the Internal Server. (In the CLI, the same types are referred to as "radius" and "portal".) Unfortunately, Guest WLAN with MAC/PSK auth always requires some kind of captive portal even if it's just "acknowledge". This conflicts with existing user expectations from our old system and we don't want to deal with potential issues and questions.

 

If we make GroupB an Employee WLAN and turn the corresponding clients into Type Employee ("radius"), then we can't easily exclude the GroupB clients from WLANA based on MAC.

 

After speaking to Aruba support I've been given a workaround, which is to use Roles based on MAC address. I'll have to create a role assignment rule for each client in GroupA. Support told me that I can create 512 role-based rules (per cluster? per WLAN? doesn't matter), which will probably be adequate for the time being.

 

It's a clumsy workaround but barring any performance issues with having dozens of role assignment rules, it looks like it will work.

Well, it turns out that support steered me wrong as only 16 role-assignment rules are allowed per-WLAN.

 

At this point I'm willing to accept having a captive portal of type "Internal - Acknowledged" but I've found that performance of the captive portal is horrible with Apple devices. This is apparently because Apple devices that encounter captive portals will try to reach any of a number of Apple-controlled websites as part of the process, and when they don't succeed, there's a delay of up to half a minute or more. This is an issue that's described in a few places such as: http://stackoverflow.com/questions/18891706/ios7-and-captive-portals-changes-to-apple-request-url and https://discussions.apple.com/thread/6103468

 

There's even an Aruba article at https://arubanetworkskb.secure.force.com/pkb/articles/HowTo/R-1680 but it's outdated and it seems to refer to commands that aren't available in Instant.