Security

After some internal changes and upgrading to the latest VIA several of my users started complaining that they could no longer connect.

Investigating this further in Access Tracker showed those authentication events were matching a wlan dot1x service.

In this wlan dot1x service we have a 'radius-aruba'  condition that it must match the 'aruba-essid-name' of our wlan.

For VIA we have the same condfitions configured with the exception that we refuse to match any auth request that has the aruba-essid-name of our wlan.

So now, I'm a bit confused... why would VIA send the aruba-essid-name in its authentication request?

More importantly... what would be the best differentiator to only 'capture' VIA authentication requests?

If you look at Access Tracker, does it show Aruba-ESSID-Name as being passed under the Input tab?  Also can you give a quick screenshot of your two services (conditions)?

Sorry, I should have phrased my question a bit better.

If VIA is connecting from a client that is connected to a local WLAN the radius request sends the aruba-essid-name attribute along with the auth request.. Clearpass then 'correctly' uses this when deciding what service it matches.

When VIA is launched from a wired connection (or non-local) WLAN this aruba-essid-name attribute is not sent along with the auth request.

This also means it isn't too important since outside of the office it all works as intended but it would be nice that it would work the same even if used fron the internal local aruba wlan.

I am pretty much just wondering why VIA would send along something like that and more importantly and how I would be able to avoid it.

Koenv,

I have an install with a VIA service that is setup in Clearpass in the following manner:

1. Connection, NAD-IP-ADDRESS, BELONGS-TO-GROUP "Aruba-Devices" (custom group I created for the controllers)

2. RADIUS:Aruba, Aruba-AP-Group, EQUALS, default

3. RADIUS:IETF, Service-Type, NOT_EQUALS, Administrative-User (6)

It took me a hot minute of playing around to get it to work, but it seems to have been good for the past 2-3 weeks.

-Mike

Thx boston, that is pretty much how I have it configured but try connecting VIA from an internal Aruba WLAN.

You will see the actual Aruba-AP-Group in the authentication request and fail to hit that service.

That's my "problem".

Then again, therre is no real need to connect from a known local WLAN so it isn't a huge issue or anything anyway. I'll just tell people to test VIA from outside the office WLAN.

Can you make the conditions such that you put the VIA service above the wireless LAN service?   

You can further differentiate this by creating a duplicate RADIUS server entry and server group on the controller for VIA use.   Then put a specific NAS-Identifier in the server entry on ArubaOS;  include this as part of your condition inthe appropriate service.

Have you tried the VIA service template in 6.2?  It may prove useful

The problem is that the VIA auth from the LAN is identical to a wireless authentication. Putting it in front would be bad :)

The idea of using a different NAS-ID however does sound like a solution.. thanks.

Haven't tried the service template either, will check what that thing builds as template.. thanks again.

---

@KoenV wrote:

The problem is that the VIA auth from the LAN is identical to a wireless authentication. Putting it in front would be bad :)

The idea of using a different NAS-ID however does sound like a solution.. thanks.

 

Haven't tried the service template either, will check what that thing builds as template.. thanks again.

---

Koenv,

VIA by default uses PAP for authentication.  Remove PAP and it should not be processed by that rule.

So you have a couple challenges here.

Mainly the VIA provisioning

I ran into this same issue and the challenge is that the auth comes in when you are local and it will have the same radius parameters as a standard auth so unless you use a separate controller than the VIA controller you will have a challenge.

The way I over came the issue was to either

1. Force VIA provisioning on the internet only so it will trigger a PAP auth

2. Or add a PAP auth to your wired/wireless service (which is what I did)

       A. I also have my service trigger to put my VIA users in my provisioning role that allows CPPM and VIA.

If your VIA is setup correctly it will recognize that you are local and not trigger an auth. 

Is there a reason you are triggering your VIA local?

Im not a VIA expert so there might be some other options and I will ping engineering to see what they say. :)

ok, "solved" this by creating 2 identical services with the exception that the wireless  dot1x service specifies an ssid where the via service does not. Still won't enable users to use this internally but I guess that can't be solved as of now other than by creating additional radius servers and using Clembo's nas-id tip.

 

 

What I still don't understand is why you would have VIA sent all the attributes to the radius as if it was a wireless dot1x authentication. I mean, what use is it that VIA sents back 'Radius:Aruba:Aruba-AP-Group', 'Radius:Aruba:Aruba-Essid-Name' or 'Radius:Aruba:Aruba-Location-Id' attributes?!

 

Have VIA sent an 'Radius:Aruba:Aruba-Location-Id=VIA' or something back instead and all is possible again. Heck, just leave those attributes out completely and we've gained flexibility again.

 

Or is there a valid reason (that I'm missing) why those attributes are being returned with a VIA authentication?

Why is VIA even giving a nas-port-type 19 (wireless IEEE802.11)? It is not a wireless authentication!

 

Did you get an answer from engineering Troy?  If not, could you bugger them with the above questions pretty please?

 

 

oh, and the reason i would prefer this to work internally is users tend to test issues internally and then come to me because it doesn't work. I rather not keep explaining that this software is the exception and shoul donly be tested remotely.

Koen,

Amen on that one!

-Mike

I would love an answer as to way VIA bevhaves like a wlan authentication..

Any chance anyone has the answer?

You realize I'm going to keep pestering you regarding this issue untill I get a satisfactory answer or you tell me to sod off right :P

Koenv,

Engineering wants to obtain the logs.tar from the controller and the via logs from the client when the "ESSID in the Radius Packet" issue occurs.  Would you be able to provide that for us?

Just sent you a link through PM where you can download the requested files.

Let me know if you need any more info. My details are included in the .txt

Just to be complete.. using clembo's NAS-ID tip and creating different radius -servers just for VIA we can get everything working including on the internal WLAN. Not the nicest solution having to create different radius servers and server-groups but at least it works.

What does still baffle me is why this client acts as a wlan client instead of a vpn client.. If someone could clarify me on that bit I would greatly appreciate it too.

it doesn't help you but from experience i have seen that vendors are quite liberal with choosing which radius attributes they include in their request. doing auth request without the auth type, doing it via wired without the ethernet type, ...

someone at aruba decided on these attributes at some point probably. maybe they made more sense back then, but like you say they don't make full sensenow. i don't see a good one for a VPN client btw, Virtual comes the closest.

changing it suddenly might also be interesting as some people probably filter on the current one.