Tunnel-Private-Group-Id problem

[deimos]

Hello, 

I have a Aruba Controller 3200 in a test enviroment. There is a pfsense that works as a Radius. I want to distribute clients who authenticate with the related ssid, based on vlans. So I configured pfsense to send vlan information in tunne-private-group-id. I also wrote a server dervation rule for that. Unfortunatly when I authenticate it doesn't send the clients to relative vlan which mentioned in the rules. But when I configured the rule based on user-name it works. I made a radius authentication test with a software called NTRADPING. It says that the server returns the tunnel-private-group-id successfully(and gives me the correct value). Someone else tried it with a different software and send me this output;

Sending Access-Request of id 163 to 78.46.170.10 port 1816

        User-Name = "test"

        User-Password = "123456"

        NAS-IP-Address = 78.46.170.10

        NAS-Port = 0

        Message-Authenticator = 0x00000000000000000000000000000000

rad_recv: Access-Accept packet from host 78.46.170.10 port 1816, id=163, length=36

        Tunnel-Type:0 = VLAN

        Tunnel-Medium-Type:0 = IEEE-802

        Tunnel-Private-Group-Id:0 = "80"

Should I do some extra configuration on aruba controller to encrypt or read the data that concerns tunnel-private-group-id ?

Thank you for your help!

[clembo]

Can you share your server derivation rule?     Also, does pfsense support responding with vendor specific attributes (VSAs)?   If so, you can send back the Aruba-User-Vlan attribute.

[deimos]

Here is the rule that seems not working. I also checked it by changing equals to contains.

[cjoseph]

Do this:

Start radius attribute debugging:

config t
logging level debugging security process authmgr
logging level debugging security subcat aaa

 Authenticate your user then type "show log security 50" to see what attributes the controller sees coming back from the radius server.

[deimos]

Hello,

I was not in the location where I can authenticate and observe the logs. So I had to wait until Monday. Now I tried with my iphone and laptop.

First log is from iphone authentication where the rule was If tunnel-private-group-id is 80 set vlan 80 and ip assigned to the iphone was from vlan 60. (subnet of vlan 60 is 10.0.60.0)

Second log is from the laptop where the server-derivation rule was if tunnel private group id is 80, set vlan 60 and ip assigned to the laptop was from vlan 80.(subnet of vlan 80 is 10.0.80.0) 

The output of show log security 50 command for both procedure is in the attached file.

[cjoseph]

deimos,

The proper way to use that attribute is to send the Microsoft "Tunnel-Type", "Tunnel-Medium-Type" and the "Tunnel-Private-Group" attributes (all three) together:  http://www.arubanetworks.com/techdocs/ArubaOS_63_Web_Help/Web_Help_Index.htm#ArubaFrameStyles/Network_Parameters/About_VLAN_Assignments.htm

Unfortunately, once the Aruba controller sees one of those VSAs (Vendor-Specific attributes) and not the other two, it will not process any Server Defined rules, so your "Tunnel-Private-Group" attribute SDR (server defined rule) is ignored in the process (VSAs trump SDRs).  There are easier ways to do this, by sending the non-VSA "filter-id" radius attribute back and using a server defined rule to match that filter-id to a number and changing the VLAN as a result.  That would allow you to sidestep how the "Tunnel" VSAs are handled.  

There is also a way using Aruba VSAs (Vendor Specific Attributes) where you do not need to write a server defined rule, but I do not know if configuring Aruba VSAs on your radius server is out of the question.  You would only need to send back the "Aruba-User-Vlan" attribute below to acheive the same functionality you desire:

Dictionary
----------
Attribute                         Value  Type         Vendor     Id
---------                         -----  ----         ------     --
Aruba-Mdps-Device-Version         21     String       Aruba      14823
Aruba-Mdps-Max-Devices            18     Integer      Aruba      14823
Aruba-Location-Id                 6      String       Aruba      14823
Aruba-Template-User               8      String       Aruba      14823
Aruba-No-DHCP-Fingerprint         14     Integer      Aruba      14823
Aruba-AirGroup-Device-Type        27     Integer      Aruba      14823
Aruba-Mdps-Device-Profile         33     String       Aruba      14823
Aruba-Mdps-Device-Udid            15     String       Aruba      14823
Aruba-AirGroup-Shared-User        25     String       Aruba      14823
Aruba-Mdps-Device-Serial          22     String       Aruba      14823
Aruba-AP-IP-Address               34     IP Addr      Aruba      14823
Aruba-Auth-Survivability          28     String       Aruba      14823
Aruba-User-Role                   1      String       Aruba      14823
Aruba-Port-Id                     7      String       Aruba      14823
Aruba-Priv-Admin-User             3      Integer      Aruba      14823
Aruba-Mdps-Device-Product         20     String       Aruba      14823
Aruba-WorkSpace-App-Name          31     String       Aruba      14823
Aruba-AS-Credential-Hash          30     String       Aruba      14823
Aruba-User-Vlan                   2      Integer      Aruba      14823
Aruba-AirGroup-Shared-Role        26     String       Aruba      14823
Aruba-Device-Type                 12     String       Aruba      14823
Aruba-Mdps-Device-Imei            16     String       Aruba      14823
Aruba-Essid-Name                  5      String       Aruba      14823
Aruba-AP-Group                    10     String       Aruba      14823
Aruba-AS-User-Name                29     String       Aruba      14823
Aruba-CPPM-Role                   23     String       Aruba      14823
Aruba-Mdps-Device-Name            19     String       Aruba      14823
Aruba-Mdps-Provisioning-Settings  32     String       Aruba      14823
Aruba-AirGroup-User-Name          24     String       Aruba      14823
Aruba-Mdps-Device-Iccid           17     String       Aruba      14823
Aruba-Framed-IPv6-Address         11     String       Aruba      14823
Aruba-Named-User-Vlan             9      String       Aruba      14823
Aruba-Admin-Role                  4      String       Aruba      14823

[deimos]

Hi Colin,

My collegue configured the radius per your instruction. And in the document it also says:

After client authentication, the VLAN can be derived from Microsoft Tunnel attributes (Tunnel-Type, Tunnel Medium Type, and Tunnel Private Group ID). All three attributes must be present as shown below. This does not require any server-derived rule.

Tunnel-Type="VLAN"(13)

Tunnel-Medium-Type="IEEE-802" (6)

Tunnel-Private-Group-Id="101"

The only different parameter here is Tunnel-Private-Group-Id="80" in our configuration. But it says that we don't need a server-derived rule for vlan derivation. But we didn't able to authanticate to the appropriate vlan. I also run the command show aaa debug vlan user 10.0.60.22(the ip my iphone gets) and the output is 

VLAN types present for this User
================================

Default VLAN : 60

VLAN Derivation History
=======================

VLAN Derivation History Index : 7
1. VLAN 0 for Reset VLANs for Station up
2. VLAN 60 for Default VLAN
3. VLAN 60 for Current VLAN updated
4. VLAN 0 for Reset Role Based VLANs
5. VLAN 0 for Reset Dot1x VLANs
6. VLAN 0 for Reset Role Based VLANs
7. VLAN 60 for Current VLAN updated

I would be very happy if you can share your recommendations. And thank you for your help so far.

[cjoseph]

deimos,

You have to choices:

- You can open a TAC case so that they can get your information and find out if this is a bug,

or 

- Have your radius server send back the filter-id radius attribute and use a server derivation rule to change the VLAN.

I do not have enough information about your setup to determine what is not working properly and why.

[deimos]

Hello,

I want to update my post with the following information.

This system works if I use user-name in server-derivation rules. And when I run the command show aaa debug vlan user ip 10.0.80.21(the ip address my iphone gets) the output is below:

VLAN Derivation History
=======================

VLAN Derivation History Index : 9
1. VLAN 0 for Reset VLANs for Station up
2. VLAN 60 for Default VLAN
3. VLAN 60 for Current VLAN updated
4. VLAN 0 for Reset Role Based VLANs
5. VLAN 0 for Reset Dot1x VLANs
6. VLAN 80 for Dot1x Server Rule
7. VLAN 0 for Reset Role Based VLANs
8. VLAN 80 for Current VLAN updated
9. VLAN 80 for VLAN exported

Current VLAN : 80 (Dot1x Server Rule)

The server-derivation rule is user-name equals test set vlan 80.

I still couldn't understand why tunnel-private-group-id is not working:(

[cjoseph]

Server Derivation rule should work all of the time.  The Tunnel-Private-Group-ID attribute is not seen often in deployments, so if there is a bug, it was probably not reported.  Server derivation rules are used often.  You should use a different attribute, then use a server derivation rule to trigger the change.