Controllerless Networks

Introduction : For IEEE 802.1X Authenticators, the attribute called-station-id is used to store the bridge or Access Point MAC address(upper or lower case) with octet values separated by a none(default)/colon/dash/none.  Example with upper case with dash: "00-10-A4-23-19-C0".

In IEEE 802.11, where the SSID is known, it should be appended to the Access Point MAC address, separated from the MAC address with colon(default)/dash/none. Example with colon: 00-10-A4-23-19-C0 : ARUBA

Does Aruba Instant AP  support  this one ?

No, it just sends the AP’s MAC. The SSID is send in an Aruba-VSA.

Dear Cappalli,

Thanks a lot. But which one that I can use in the Aruba-VSA list ?

Best regrads.

Lewis.

 

Aruba-Essid-Name

 

Hi Cappalli,

Thanks. My question is " Does the virtual controller of IAP really send the name of SSID in Radius message out to the Radius server ? "  I coludn't it in the capture file of Wireshark. How can I enable the meaasge of SSID to be sent out in IAP, or even by the CLI mode ?

 

Br.

Lewis

Hi, anyone who has an anwers in this question? I'm in need of the same because I'm using Microsoft NPS to authenticate. I don't see the Aruba IAP sends the SSID within the called-station-id. I really require this as this is the only way to distinguish policy access between the SSÍD's.

The Aruba VSA is a solution when using clearpass but I don't so really need the IAP to send it in the called-station-id field.

 

The Aruba controller does support this option, so I'm wondering why the IAP could not.

I'm using 6.4.3.1 with 225 and 6.4.1.1 with 7220 ad 325.

 

Thanks!

Aruba Instant APs do not support RFC 3580 to configure called-station-ID with SSID.  The Aruba controllers just started supporting that in ArubaOS 6.4, but there is no promise that the Instant APs will support it.

 

At issue is that Microsoft NPS/IAS do not support using incoming 3rd-party VSAs (Vendor Specific Attributes) to make decisions about radius traffic.  Both the Aruba controllers and instant send the Aruba-Essid-Name VSA, but NPS has no way to process it.  How would you identify a different SSID on instant?  You would configure two Radius Authentication Servers in instant with the same ip address as your radius server, except, you would have a different nas identifier (below the nas identifier is ssid1), for each depending on which SSID you would want to authenticate it to:

 

 

Again: Two radius servers, the only difference is the NAS-ID.  When you setup the SSIDs in instant, you use one radius server for one SSID and the other radius server for the other SSID.  How do you configure it on NPS?  You use the NAS identifier as a condition to determine which SSID the authentication is coming from:

 

 

I hope that makes sense..

 

Hi Colin, thanks for your quick and clear explanation. It surprises me somehow that Aruba just started supporting RFC3580 on their controllers and still not on the IAP's, if I compare this with other WLAN vendors. Hopefully this will be added to be supported by IAP as well.

However your workaround is a solution that fits my needs. I just tested it and it works like a charm.

 

Thanks again, really appreciated!

Sorry for the thread necromancy, however, this is a very specific issue with little or no other places to lodge a comment in context.

 

 

What's surprising - and disappointing for the same reason, is this has been an RFC since 2003 and is even suplemented by RFC 7268 (albeit still at a proposed level).

 

Defining RADIUS servers on a one-to-one ration is fine for small deployments but clearly this doesn't scale.

 

We bought 150 (at a cost of around $140,000, which is far from insignificant for a not-for-profit) of these with the expectation that in being managed by Airware, we'd greatly reduce our administrative effort and cost, however, this unexpected surprise  - which arguably is my fault for not researching right down to the RFC level, has now shot that entirely in the foot.

 

This is a really disappointing outcome for what should be an entry level-but-solid enterprise WAP (more a comment on the IOS than the hardware, which is wonderful).

 

Cheers,

Lain

In what context do you use RFC 3580/7268?

Hi Colin,

 

We expect that the called-station-id is populated as per RFC 3580 by any of our APs - new or old, so that we can correctly associate the designated network policy with it's associated requests by SSID.

 

This is important as if we cannot achieve this match then we cannot align the correct authentication choice to the specific wireless network.

 

For example, we have SSID1 that uses EAP-TLS for trusted domain-joined clients. This wireless network has full network access.

 

We have a second network identified by SSID2 with access only to the Internet which is not using RADIUS but we'd like it to. What's stopping us is the inability to use called-station-id in the conditions so we can discern between wireless networks, which in this example would require us to use MS-CHAP or MS-CHAP-v2.

 

In not being able to discern the difference using called-station-id, every wireless request will simply match the first network policy which in turn will allow the lesser MS-CHAP-based authentication to work, which in turn will allow these untrusted devices access to the full corporate network.

 

From a literal usage perspective, called-station-id is matched with the following regular expression using SSID1 as the example of this part of the condition:

 

\:SSID1$

 

We have five wireless networks in total but there's no value in going through each scenario. The fundamental issue is that without being able to conveniently leverage the RFC definition for called-station-id, we'd have to be willing to take on board the management of the additional RADIUS servers on a per local controller basis, which is a length to which we are not willing to go - particularly as our environment grows, when we know there is a more appropriate route.

 

Cheers,

Lain

Just a side note, the SSID is sent in the RADIUS request with the
Aruba-ESSID-Name VSA which could be used in your policy today.

Thanks, Tim.

 

I'll go away and read more about the usage of VSA, as what I've read to date left me with the understanding - rightly or wrongly, that these acted as directives contained in the Access-Accept response back to the calling station about how to modify the policy sent to the client. i.e. use this VLAN, etc.

 

If they are indeed usable by NPS as part of the Access-Request then I have a workaround I'm happy to use until RFC 3580 compliance comes along and I'd offer an apology for grandstanding on the issue in the interim.

 

Cheers,

Lain

Hi Colin,

 

NPS on Windows Server 2012 R2.

 

Cheers,

Lain

Yes, Aruba VSAs can be used on any RADIUS server. You just have to
create/add the dictionary and then they will be available to you.



The Aruba vendor code is 14823 and the Aruba-ESSID-Name attribute number is
5.

Hi Tim,

 

I'm not seeing the evidence bear out what you're stating about VSA's being usable as a condition. Rather, what the network traces and NPS logs are confirming is Colin's (and mine) representation from midway down the first page of this thread, which is that vendor VSA's aren't consumable as a condition but can readily be used to provide further client configuration back during the Access-Accept response.

 

This really takes me back to not having a workable, scalable solution - excluding the ray of hope you've provided at the top of this page (though with no estimated timeline, it's a slim ray - but I'll still take it) indicating this may be remediated.

 

The details of the configuration, trace and logs are below, if you're interested.

 

Cheers,

Lain

 

NPS policy configuration:

Please note the deliberate mismatch of the SSID, as this was done to see if NPS would genuinely use the defined VSA to reject the client request (which it didn't; it succeeded).

 

Network trace: Access-Request (noting the client-supplied VSA is there)

 

Network trace: Access-Accept (noting the NPS VSA is there and doesn't match)

 

I decided to leave the Event Viewer confirmation out as it's enough to say (again) that the connection succeeded despite mismatching Aruba-ESSID-Name VSA.

I'm more curious as to why, if the policy isn't being matched (including the VSA), that it's still sending an accept back to the WLAN? What am I missing?

Hi Jerrod,

 

What Microsoft allows is effectively the post-approval configuration of various client properties using VSA.

 

What they don't allow is the initial assessment using VSA. This is why the connection is approved: the VSA are never inspected and compared to the criteria defined in the policie's conditions. In our examples (provided earlier), this means it's only checking the group memberships and enforcing the authentication layer. The inbound VSA is never even looked at.

 

The "why", I clearly can't answer on Microsoft's behalf. Design choice; oversight; being stubborn; who knows? Be that as it may, it's a framework in which we must operate and technically, if RFC 3580 was observed on the Aruba IOS, we wouldn't even be discussing it as called-station-id is one of the attributes catered to in NPS as per RFC 3580. Even the old Cisco units that we're replacing (circa 2006) as end of support provide the called-station-id in RFC 3580 format.

 

Cheers,

Lain

Might be a possibility for a workaround but don't know if it would accept the configuration:

 

can't you add your radius servers a second time and use a different NAS identifier? You can then add server configuration 1 to SSID 1 and server configuration 2 to SSID 2. And those attributes are seen by NPS and can be used to match it to the right authentication. 

---

@Lain Robertson wrote:

Hi Tim,

 

I'm not seeing the evidence bear out what you're stating about VSA's being usable as a condition. Rather, what the network traces and NPS logs are confirming is Colin's (and mine) representation from midway down the first page of this thread, which is that vendor VSA's aren't consumable as a condition but can readily be used to provide further client configuration back during the Access-Accept response.

 

This really takes me back to not having a workable, scalable solution - excluding the ray of hope you've provided at the top of this page (though with no estimated timeline, it's a slim ray - but I'll still take it) indicating this may be remediated.

 

The details of the configuration, trace and logs are below, if you're interested.

 

Cheers,

Lain

 

NPS policy configuration:

Please note the deliberate mismatch of the SSID, as this was done to see if NPS would genuinely use the defined VSA to reject the client request (which it didn't; it succeeded).

 

Network trace: Access-Request (noting the client-supplied VSA is there)

 

Network trace: Access-Accept (noting the NPS VSA is there and doesn't match)

 

I decided to leave the Event Viewer confirmation out as it's enough to say (again) that the connection succeeded despite mismatching Aruba-ESSID-Name VSA.

---

NPS is very limited and cannot use incoming VSAs as a condition.   The vast majority of other radius servers can and NAS manufacturers have well published VSAs to make that situation very flexible .  I would suggest you use the Nas Identifier workaround earlier in the thread for NPS.

Hi Colin and jcelis,

 

Thanks, but these workarounds have already been addressed earlier in the thread.

 

Colin, the more likely outcome is I stop purchasing Dell (rebadged Aruba) equipment, pay the 15%+ premium and go back to an RFC compliant vendor such as Cisco and accept the embarassment of admitting to the business I made a mistake with choosing the W-IAP215.

 

That said, I'm keen to see how Tim's reference to the possibility of RFC 3580 compliance "very soon" at the start of page 2 pans out in the short term before I make that decision.

 

Cheers,

Lain

Lain,

 

You have to do what is best for you.

 

---

@Lain Robertson wrote:

Hi Colin,

 

We expect that the called-station-id is populated as per RFC 3580 by any of our APs - new or old, so that we can correctly associate the designated network policy with it's associated requests by SSID.

 

This is important as if we cannot achieve this match then we cannot align the correct authentication choice to the specific wireless network.

 

For example, we have SSID1 that uses EAP-TLS for trusted domain-joined clients. This wireless network has full network access.

 

We have a second network identified by SSID2 with access only to the Internet which is not using RADIUS but we'd like it to. What's stopping us is the inability to use called-station-id in the conditions so we can discern between wireless networks, which in this example would require us to use MS-CHAP or MS-CHAP-v2.

 

In not being able to discern the difference using called-station-id, every wireless request will simply match the first network policy which in turn will allow the lesser MS-CHAP-based authentication to work, which in turn will allow these untrusted devices access to the full corporate network.

 

From a literal usage perspective, called-station-id is matched with the following regular expression using SSID1 as the example of this part of the condition:

 

\:SSID1$

 

We have five wireless networks in total but there's no value in going through each scenario. The fundamental issue is that without being able to conveniently leverage the RFC definition for called-station-id, we'd have to be willing to take on board the management of the additional RADIUS servers on a per local controller basis, which is a length to which we are not willing to go - particularly as our environment grows, when we know there is a more appropriate route.

 

Cheers,

Lain

---

Fair enough.  What radius server are you using?

It's coming very soon. Please reach out to your Aruba account team.

Hi Colin, found your post and have done the config as described but the NAS Identifier attribute is not showing in our Radius server event log, just the IP adress of the AP. Any tips is appreciated. 

Which radius server are you using? 

Microsoft NPS

NPS does not support parsing 3rd party Vendor VSAs unfortunately.

Hi, Ok I see. That is unfortunate. Can you recommend a Radius server that do support this? We have considered Clearpass but finds it way to expensive. Thank you for your help.

Freeradius should support this.

I suspect this will have come a little to late to help ghanzen above, but RFC 3580 support was indeed added for instant APs as of firmware version 6.5.0.0-4.3.0.0. It slid in a little inconspicuously, as rather than referring to RFC 3580, it snuck in via a barely-there reference in the release notes under the guise of a brief discussion about the called-station-id RADIUS attribute (to which RFC 3580 applies).

 

You can read more about the two relevant commands in the following Aruba support article. Note that these settings were not implemented via the GUI, so you need to SSH in to make these two changes.

 

http://community.arubanetworks.com/t5/Controller-less-WLANs/How-to-configure-called-station-ID-and-Calling-station-ID-in-IAP/ta-p/292705

 

From that point on it's easy enough to create separate network policy rules in NPS using pattern matching (which I demonstrated a few posts back) to capture the SSID.

 

 

Cheers,

Lain