M and MSM Series

[MSM765zl] User-defined vlan via radius attributes

Occasional Contributor

[MSM765zl] User-defined vlan via radius attributes



I've got working access-controlled wireless network (802.1x auth), based on HP MSM765zl module with MSM410AP. Everything works fine but user-defined vlans.

I would like to override "VSC egress mapping" in VSC profile. I added local user with custom attributes (Tunnel-Type=VLAN, Tunnel-Medium-Type=802, Tunnel-Private-Group-ID=VLANID), and "egress interface" option in account profiles. Nothing works :((( Is there something more to do to configure user-defined vlan?? User always belongs to vlan defined in "VSC egress mapping" settings.


Ap are connected to LAN port. MSM Internet port are user-defined vlan tagged. Is it right? More... I've assigned IP address to that VLAN ("VSC egress mapping" option requirement). Maybe that's wrong.


I tried also with external radius server (freeradius), but the result is the same :( My current Freeradius configuration works fine with old HP WESM ZL module. I don't use and I don't want to use IDM.


Has anybody configured user-defined vlan via local account or external radius server? Could you show your configuration?


When i disabled a access-control mode in VSC, AP properly support dynamic VLAN - user frames are properly tagged by AP according to received radius attributes.


Re: [MSM765zl] User-defined vlan via radius attributes


I have the same problem.


Until to now, I used a non-access controlled VSC and the APs operated as "thick" clients. The APs and the controller were all in the same subnet and communicated with each other over an untagged vlan. Radius assigned dynamic VLANs to the users and the user-traffic was egressed directly at the APs in the correct tagged VLANs.


Yesterday, I wanted to change this setup into an access controlled VSC and ran into the same problem.


I created a new VLAN (ID 8) on the switch that houses the 765zl and the APs. I put all switch ports that are connected to APs and the LAN port of the controller (port A2 on my switch) as tagged members into VLAN ID 8. This vlan as supposed to carry the wireless traffic between the APs and the controller.


I created a new network profile on the controller and assigned VLAN ID 8 to it. I put the LAN port of the controller and the LAN port of all APs as tagged members into this network profile.  I created a VSC that used this VLAN as ingress VLAN (Controller -> VSCs -> "My VSC" -> VSC ingress mapping -> 8). I created a group for my APs that uses this VLAN as the egress VLAN in the VSC binding. (Contolled APs -> "My Group" -> VSC bindings -> VsC binding -> "My VSC" -> Egress network: 8).


The result ist the following:


The users can successfully authenticate against the RADIUS server as before. The APs forward the wireless traffic to the controller via VLAN 8 successfully. But at the controller the user traffic egress via VLAN 8 instead of the radius-assigned user vlan.


The expected behaviour would be:


The APs forward the wireless traffic to the controller via VLAN 8. At the controller the user traffic leaves the controller via the internet port with the radius-assigned vlan.


Best regards, Matthias


Re: [MSM765zl] User-defined vlan via radius attributes [PARTIALLY SOLVED]

I solved the problem partially.


1) The information shown on the page "user session" is misleading, because the column VLAN always shows the ingress vlan which is indeed always the same because this is the one used between the AP and the controller.


2) The egress VLAN is displayed after one clicks onto the user name to show the detailed information page about the user session.


3) The correct egress VLAN is actually used and (partially) working. If I configure a static IP address on the client everything works as it should and the observed traffic flow is as expected.


But for some reason the controller does neither forward IPv4 DHCP requests nor IPv6 router advertisments, if the egress into the user-defined VLAN takes places at the controller. (But the APs do so, if the egress takes place at the APs.) This is the reason why the clients do not obtain a correct network configuration. But this is a different problem, so I will open a new post for that.