Can anyone think of a way to replicate the feature that Meraki implemented to reject clients based on their device type. We no longer have Meraki devices (the subscription cost is ridiculous) but I've repurposed their devices as great OpenWrt APs!
The way they do it is detailed here https://documentation.meraki.com/MR/Group_Policies_and_Blacklisting/Applying_Policies_by_Device_Type and wondered if there is already a package to do this, or if developing one may be fairly straightforward?
TIA
Not so difficult. Needs a good proxy on the openwrt-device, i.g. "squid", to interpret http-info from the clients.
As squid is RAM-hungry, 128MB RAM is minimum, 256MB recommended.
Depends upon other packages used, of course.
Just curious: Whats the reason to do it ?
Thanks for the quick reply. On the Meraki you can apply the rules per SSID, and then you can segregate traffic more easily. Each SSID can be routed via a separate VLAN. It's very useful for preventing staff putting their phones on the corporate WiFi!
There's a lot more resource efficient approach.
You can set up individual or group MAC address filtering using DHCP server and/or firewall:
And if you use separate VLANs, you can apply custom firewall rules per VLAN.
According to the link, westiej gave, "Device_Type" is like "Android" to be blocked. That only can be determined using the http-info.
Of course, in case you know the MAC to block already in advance, proxy not necessary.
So it needs to be clarified, what is the criteria to identify devices to be blocked. Or, even easier, to be allowed.
Yes, to replicate the solution it can only be done through http-info, however implementing a full proxy seems like a sledgehammer to crack a not. The Meraki appears to do it when the device attempts to join the AP, and simply rejects it's join request, negating the need to inspect all its traffic as it can't generate any!
Interesting. I can not believe, that identification of device type, like "Android", can be done (more or less reliably, as it can be forged) without the http-info. There is another possibility to use string matching within firewall. But this is even more complicated to implement. and needs real traffic, too. Another (very) unreliable method could be the classification of the MAC itself. Like "If Apples MAC" then IOS else Android ;
So I could only trust your last information, in case you made a tcpdump during the period of time, when a new (not previously used) supposed to be blocked device type unsuccessfully tried to associate to the Meraki.
This assumes, you do NOT have MAC-based auth in use, i.e. using RADIUS.
Signature identification in hostapd by enabling device taxonomy at build time is the quickest way.
And you'll need A signature database.
https://w1.fi/cgit/hostap/commit/?id=04059ab84458f43dda9130e4fff745b268424b99
Yes and no. According to your link, for the FIRST appearance of a client, its type is checked using something like a proxy, as I wrote already. On next appearance, the MAC is checked against Merakis "dashboard" (better: internal database/RADIUS), which in this case works like a white-/blacklist. So, if on first appearance, client was blocked because of its http-agent, on second appearance its MAC will already be blocked during association. Which can be implemented in various ways. Most likely Meraki, as a commercial product, will use RADIUS.
All this can be implemented using openwrt. Although I doubt, to be worthwile for a small network only.
To identify the clients using HTTP during the initial connection, you do not need a full proxy (that is not going to do anything for HTTPS, by the way), but something like the "fake internet" package or some "captive portal".
You are wrong.
Fazit: Intercepting proxy best suited to determine device type (browser type, OS type), according to requirements. Intercept proxy like squid has the hooks to interface with RADIUS etc. for blacklisting/whitelisting of clients MAC.
First you tell me I am wrong, then you explain roughly the same ideas... I think you did not understand my message!
What I tried to explain is that a full HTTP proxy is not the right solution, but something based on the concepts () behind "fake internet" and "captive portal" could be developed, perhaps.
Looks like you did not understand.
In a good http-proxy, like squid, you have access to the http-headers, too. So you can identify the "device type" (iOS, Android etc.) and trigger some action on it, like blockage of the users MAC. I.g. blockage on hostapd-level, i.e. by using RADIUS. Or a plain-text blacklist. The intercepting/transparent proxy does not alter anything of the data transfer. It is just read-only.
"Fake internet" alters data exchange, by purpose. As it "redirects" traffic, by means of manipulating DNS.
Captive Portal (intercept) does not deal with http-stuff, as it works on the lower level. Either very low level (coova-chilli), or connection/packet level, like wifidog.
Theoretically, you could modify their C-code, but that definitely is not simpler, compared to using some built-in features of squid, for example.
From a question on Stackexchange:
When Android connects to a wireless network, it tries to connect to http://connectivitycheck.gstatic.com/generate_204 (or one of the other similar google pages) specifically to check if the request is being redirected.
You could redirect that hostname to your Openwrt via DNS, or catch it with some iptables, etc. Point is, now even a simple 'Netcat-in-a-script' could detect the Android UA, and trigger arbitrary actions, or try and get it from uhttp logs, if it makes any
Yes, netcat-in-a-script should work , in principle. But also this setup is intercepting, non-transparently, as it modifies data traffic between client and host. Which will create some sideeffects, as it interferes with the Captive Portal Detection in the client device.
As soon, as you pass on the intercepted data, to its real destination (host), you have a proxy again.
So, why not to use a real, stable proxy, like squid, in first place, which is (also) built for such purposes, to transparently (non-modifying) interception of pass-thru data ?
This is very simple to do using NodogSplash-FAS and a short PHP script. It is also very simple to bypass by spoofing the client UA, but that would have applied to the original solution as well.
Interesting. Never used Nodog-Splash, which seems to be some kind of Captive Portal. Only often using coova-chilli, which is the most sophisticated CP AFAIK. But as every CP always does some type of REDIR (coova on very low level, Nodog-Splash using iptables, other solutions messing around with DNS), all interfere with real data traffic, and modify it. No way out.
Assuming, that this does not harm, you are correct, CP can be used for the required purpose.
However, non-modifying, transparent, intercept proxy, does not need such an assumption.
Yes, NoDogSplash uses iptables, but it does not "interfere with real data traffic, and modify it". It works with the standard CPD, does the validation you define, then either allows or denies access - no more complicated than that. The OP asked if there was a package that will do this - the answer is Yes.
Thanks to everyone for their input on this topic, it's been very educational. I'll take a look at the captive portals to see if they're worth the effort! I agree that spoofing the user-agent isn't hard, and that according to the Meraki documentation you could easily get round the checks for them anyway, but it is what it is!