Is it necessary to limit the identification based on the PSK entered only? This might be difficult to deploy.
What is easy and straightforward and independent of the MAC address is using WPA2/Enterprise and PEAP-MSCHAPv2 as identification and authentication. (RADIUS username/password)
Multiple logons/sessions is no problem. Username could be the department/service/whatever you want to deliver (e.g. delivery corresponding to a VLAN ID).
The RADIUS user (who has a unique password) would have the “Mikrotik-Wireless-VLANID” attribute and maybe some more that are appropriate for wifi.
Not clear what “Mikrotik-Wireless-PSK” would be used for in this setup, and if it is related to MAC address only or to a RADIUS user. It’s not needed in this setup.
that was my first intention but how to deal with devices that don’t support EAP?
Offering a second (Guest) WiFi to allow such devices to go online. If such a device would be a smart device such as TV-Box the user, who is located in its own VLAN needs access to it, so I would have to migrate it manually from the Guest (untrusted devices) VLAN to its VLAN by modifying the Client-List in the RADIUS Server each time this happens.
I would like to get rid of this manual workflow. Either by allowing self-enrollment of such devices but FreeRADIUS does not have such a feature. I’m exploring such workflow here: Self Service Kiosk / Workflow to trust untrusted devices to add them to personal VLAN dynamically (freeradius.org)
that the AP doesn’t send any information on which RADIUS could decide
how to distinguish between users but it is said as well
The only way to have more than one PSK that every client can use is to use a wpa_psk file on the access point (in addition). It allows for more than one PSK every client can connect to, because> it allows a wildcard MAC of 00:00:00:00:00:00> .
but how to implement that in an MT device?
So my questions are:
Could be any script generated that would enhance the Access-Request or Accounting-Request?
A script what manipulates the MAC before being send to the RADIUS-Server?
It seems that other vendors have the implementation of PPSK or iPSK but as far as I understand there are still based on the assumption that you know the MAN before connecting it to WiFi:
thx for referring to it but I would like to wait until ROS 7.x has a somehow stable feature set.
I’m even not sure if this User-Manager could solve my use-case?
I don’t have a solution. Searching daily for my own challenge which is different … I want the WPA2/EAP login to wifi be the single signon for the Hotspot.
WPA2/EAP(Enterprise) is transparant once the device has stored the credentials, but I want extra controls that are only available in the Hotspot, without a second manual login.
Answer:
In general we have 3 steps when logging in: identification- authentication - authorization, typically assigned to resp. username - password - VLANid, or also MAC - PSK - VLANid.
Here we combine identification with authentication in one step. The proposed method is using the PSK. But it could also be the username (with no password required).
But logging in with a username may require EAP/PEAP, even without a password.
But I know that not all devices can do 802.1x login. (Some people come with very old Windows versions on their laptop, missing that piece of software)
Printers, Chromecast, most wifi repeaters, IOT devices, home automation, … don’t have that EAP method, or just don’t have a menu to enter a username.
MT Usermanager5 starts to function now, but FreeRADIUS is still better. (I run it in NAS, PC, Raspberry Pi, Odroid, as native, Oracle Virtual box or Docker container )
Wanting a GUI interface I use DaloRadius as a layer with extra features on FreeRADIUS. But there is also DeskRadius as a layer on top of FreeRADIUS, and that one has some interesting features for non-interactive devices.
Profiles associated to devices
With BYOD devices; you will typically assign a profile which returns the information that the LAN switch requires to dynamically assign the device into a VLAN after authentication.
The profiles is not limited to it; you can for instance also implement a Captive Portal which makes use of MAC authentication and limit the connection time of a certain device to the captive portal.
define VLAN by RADIUS-Server with default VLAN for non-listed MAC in user-file
3. combination of A & B
for either option the following action would be:
→ devices are put in separated VLAN → UI which list all (recently added) devices in this VLAN → user selects devices → device is added to its user account → device is kicked into users VLAN
Still in test. But tried out succesfully Daloradius+Freeradius3 on all the above mentioned platforms and environments. Don’t know if it will ever fit in RouterOS Docker container.
Also tried out Usermanager5 and had it working. However ROS7.x is not in production for me, and the license policy is unclear and a showstopper for now.
(RADIUS login sessions on wifi was expected to be counted as Hotspot uses, not as limited Usermananger sessions what makes sense for VPN use).
License requirement for 40 named users and 200 active sessions is rather high now.
DeskRadius still to be tested. But allowing IoT devices and non-interactive devices is not my first priority.
It does get close to your DPSK request for Usermanager5 (user can add own devices with MAC authentication)
OpenWisp is interesting, but is rather a compettitor with OpenWRT for RouterOS as far I have seen.
could be but it is said that it can run standalone as well.
In addition you can add additional backends and as ROS 7.x has an REST API, it could be possible to manage ROS as well.
I reached out to them on GITTER in regard openwisp-radius, hope I’ll get some answer. Depending on their motivation I will go for more details on additional backends.
I noted that same, what does not give a good impression of the project.
The learning curve would be very steep, which makes motivation very low (at least on my side)
Also from my side, no much interest, I don’t have that need right now. Just thinking loud here.
What if I needed it. I would forget about the unavailable DPSK, and look at what the real need is.
“Wireless network where devices can connect via PSK, but there should be multiple possibilities to differentiate that connection. There is even a different secret for each of the possibilities.”
Well if one SSID with free varying PSK is not available, then use multiple SSID. One SSID per different PSK. MT can go up to 127 if needed. Would be a complex world if more than 127 VLAN are needed to give different services to devices.
Just pay attention for the drawbacks of the many SSID. Network probably is the 2.4GHz band and the usual, not disabled, 1Mbps beacon would eat too much airtime. (3% per SSID AP sending beacons, so with 33 SSID*AP all air-time is gone.). Avoiding b-protocol an disabling the corresponding basic rates would bring the beacons to 6 Mbps. 0.5% airtime per SSID * AP count. Stretching the minimal basic rate to higher rates (like 24 Mbps) would still reduce this further, but some interaction is always at 6 Mbps. Beacon timing cannot be set in MT, it is 100msec. All but one of those SSID would be hidden, not to overwhelm the other interactive devices where the user picks an SSID out of a list. “but one” to be able to see if the network is in range. And then check what else goes wrong.
For the IOT devices the difference is to not only select the proper PSK but the corresponding SSID/PSK tuple. For a radius based PSK, then only the SSID would have to be selected for the proper VLAN, or not ? Probably depends on the real case, as the SSID is defining the VLAN, not the PSK now. (SSID is now the secret to get to a certain VLAN?)
I’ve been trying to make this work for some time but it is definitely quite complex to make it work on scale.
Other solutions have native capabilities to handle this use case.
I’ve built a solution (cusna.io) that handles automatic user activation/termination with personal PSK that creates a Personal Area Network (PAN). This is achieved by either handling automatically VLANs or relying on the native capabilities of the vendors (such as Private Client Group of Extreme or Personal WAN of Juniper).
The solution does not tie the PSK to a MAC address and it doesn’t require pre-provision of any MAC addresses (and no RADIUS)! This is very user-friendly for many contexts, from senior living to student living.
I am looking forward to finding a scalable solution to make this work on Mikrotik!