How to setup VLAN infrastructure with WPA Enterprise, RADIUS & friends?

With this thread, I'd like to invite you to collect material required to compile skd of a coherent "poor-man-802.1X-How-to".

There are many loose bits around, many of them covered deep in TL;DR threads.
In my case I got stuck at configuring radius, raising a github issue, https://github.com/openwrt/packages/issues/25441... maybe even insulting developers (sorry for that) ... just to come to the conclusion that openWRT might not in every setting be the best place to run RADIUS on.

So let's start with my example setting:

  • Farm premises, 100 x 200 m extent, plus a remote and a cloud location.
  • Two families, frequent guests, service staff requiring internet access.
  • fast growing number of IoT widgets and gadgets
  • quite some cctv cams required for a reasonable coverage of the area
  • At the moment 5 WLAN AP, maybe 8...10 required for reasonable coverage.
  • Unmanaged 1GB LAN backbone.
  • About 60 DHCP leases at my venerable 12.09 on TL-MR3220

upcoming needs:

  • seperate confident from open traffic
  • upgrade internet access from 80 to 1000 Mbit
  • keep Guests separate
  • keep all those (mostly chinese) IoT widgets separate
  • allow to separate some nasty proprietary multicast stuff
  • ensure high bandwith media access
  • VoIP
  • CCTV (about 12 ... 20 cams) to cover the whole area

Components selected:

  • HPE 1810 / 1820 1Gbit enterprise grade manageable switches are abundant in eBay, so that's going to be the backbone
  • LAN bound AP, no mesh/extender stuff to keep air as tidy as possible
  • dual band openWRT based AP look promising for that purpose
  • successfully now on 4 D-Link DAP-X1860 (< 35 € each, ample RAM and Flash), 2 TL-CPE210 (8 MB Flash, still ok, 2.4 GB narrow beam outdoor)
  • not so succesful on two TP-Link RE450 (effectively only 6MB flash)
  • observium monitoring node (snmp at the core, augmented by lldp and collectd)
  • openWrt x86 on a 4-core Fujitsu S920 with 4+1 x 1GB Lan as router
  • openWrt x86 on a 1-core Fujitsu S900 as RADIUS with mySQL, dolaRADIUS Web GUI

My previous idea was to run the RADIUS on the router. Maybe, hardware, disk and memory might suffice for that. As long as it does not have to route all TV-, zoom and cctv streaming...

With regard to this page

I decided to assign it a dedicated box - not only a docker image.

FreeRADIUS brags itself beeing "as tiny as 100 MB". So I perfectly understand that squeezing this into the world of single-digit-MB-flash gadgets requires more tweaking than just removing the myriad of command lines in the dozens of config files. May be, a RADIUS pro easily finds his way through the reorganized structure. A novice in search of the details he finds in some HowTo gets lost.

So, may be there are use cases for a minimalistic radius. But without proper documentation / Howto / explained example config, in my eyes the learning curve is unmanageable for a RADIUS novice.

The pristine setup of my dedicated RADIUS-to-be already occupies 3 GB:

  • standard headless debian
  • freeRADIUS
  • Apache
  • daloRADIUS
  • mariaDB

No problem to fit on some 16 GB mSATA.

1 Like

If you stretch to 1920 series you will get OpenWRT support.... But then you probably lose wired 802.1x or other port security features if you were after that.

This network looks a little small for the overkill radius implementation. I'd have a look at basic vlan config files that you distribue to all the AP's. Especially now that SAE PPSK made it into mainline openwrt?

HPE 1920 are traded about triple the price.
And the 1820 are already there - and I hope they do the job.

Regarding the overkill:
Hardware cost is about 30 €, and gadgets on shelf anyway.
Getting debian, apache and mysql onto it is a nobrainer for me.

And installing Radius and daloRADIUS was straightforward till now - first login at the web UI.

My hope is to get a central configuration point for all those cams and Iot gadgets still to come. I don't want to reconfigure them when I move around APs.

But of course, may be I'm completely off track with my expectations.

1 Like

Remember to have encoutered this expression, some days, or weeks, or years ago ... just gave it a quick web search again.
Might be it were right what I'm looking for, for all those IoT gadgets.
But it's WPA3, right?
How long will it take until all the tasmota, ESP, aliexpress and similiar cheap crap talks this language?

Not a language.

More that it's like WPA2 PPSK. So you can do it with WPA3 too.

One of the motivations is that all your cheap IoT you can have them all on different PSK's and then assign different vlans so as to mitigate risk. Similarly one "should" be able to do that in snapshot with WPA3 now too? Only ever done it myself with wpa2.

Anyway, my point overall is that you can get single SSID multiple VLAN, multiple keys without going the whole radius thing. Just need to distribute config files to the AP's.

https://openwrt.org/docs/guide-user/network/wifi/basic#wpa_psk_file

Yeah, just by accident I finished a script last night, round robbin ssh into a list of OpenWRT AP, retrieving (a subset of) uci configuration and display them in a table for comparison.
So I might just as well have a similiar script

  • pulling configuration file(s) from some server
  • restarting wapd or whatever required

This way, I had a single point of maintenance for e.g. wpa_psk and maybe vlan_file - correct?

https://openwrt.org/docs/guide-user/network/wifi/basic#wpa_psk_file

Ah, that whas right the point - shinig in my memory - where I started to have a look at the RADIUS thing.

Let me reconsider (P?)PSK:

  • we may assign VLAN by passphrase
    this requires change in the client / gadget config
  • we may assign VLAN by MAC
    this requires redistribution of wpa_psk file
  • we may silently migrate both gadgets and human guest users using knwon old passphrase from now full network access to some guest vlan
  • special VIP or gadgets get their special pass phrase
  • password change (for humans in particular) reuqire administrative action (redistribute wpa_psk file)

Still feels like this matches 80 % of my expectations.
Agree, might go with that, if RADIUS remains sturdy.

Additional features I hope to get with RADIUS:

  • DHCP integration (not sure yet how to pipe this to DNS)
  • user UI to change their password (I think daloRADIUS has it)
    management of access at admin level is performed on user name, independent of password, OK?

The last one is "nice to have".
The coherent maintenance of DHCP and DNS turned out to be quite cumbersome and error prone on my old "OpenWrt Attitude Adjustment 12.09". While it appears to be automagic at a first glance, it turned out that after a restart of the router, gadgets remain unaccessible by their hostname until the next renewal of the lease - which may take several hours.

May be there is an easy way out on more recent OpenWRT?

Kinda yeah. Depends on how you want to define that. Similarly with how you want to make a portal for radius and integrate it into an LDAP server etc. I've seen people just editing radius server config files so you're just moving a text config file.

As an aside when talking about small networks. I prefer AP's that can be autonomous haha.
centralised servers are great until your centralised server goes down. So having some sort of config file push setup. a la openwisp or ansible could be nice. There would be ways to do automations here but if you want the enterprise and self service solution I guess you can't beat doing radius properly.

If the developer is not serious about making improvements to FreeRadius, maybe you won't see FreeRadius in OpenWRT

Ok, by time I begin to go with you.
RADIUS is a nightmare of complexity by itself, and daloRADIUS even adds a thick layer of obscurity on top. I even spent the 15 bugs to buy Liran Tal's ebook on this just to find out that any feature I'm looking for seem to be metioned in the book but have disappeared in the current version.
Or they throw errors, and if you search for cause their issue tracker point to cause in RADIUS. Does not look like a coherently maintained pair of software, at least.

For sure it is easier to copy / paste some stanza in a configuration file to keep 3 attributes coherent than to perform a dozen click / select / paste / missing selection cycles.

Will recheck this again
https://www.freeradius.org/documentation/freeradius-server/3.2.7/howto/protocols/dhcp/index.html
but when I don't see light at the end of the tunnel, I'll drop that RADIUS thing

Well, but we have that with DHCP, router and Internet access, anyway.
Still relying on a single decade old OpenWRT 12.09 ....

Rethinking my case, I encountered this section:
https://openwrt.org/docs/guide-user/base-system/dhcp#static_leases
where it says
dns boolean no 0 Add static forward and reverse DNS entries for this host.

Don't know why I have missed that in the past - maybe it was simply not yet available in my old version.
Does this mean that there is no need to keep in sync a second "domain" stanza in /etc/config/dhcp just to make sure that name resolution starts immediately after router reboot, even if clients have not yet renewed their lease?
This was the first motivation for me to head for RADIUS, not anticipating that I'd just drifted quite deeper into the quagmire.

I personally would bring in someone more qualified and have someone else manage it. There are MSPs who do this kind of thing and they will bring in enterprise equipment to meet your needs.The fact that you are running EOL software is a very bad sign.

I'm not saying that you can't set this up. It is totally feasible and you totally can use OpenWRT but you will need quite a bit of prerequisite knowledge. If anything goes wrong it is going to blow up in your face. You are pretty much on your own and chances are your setup will be a major source of pain.

You want some enterprise gear or at the very least some proper redundancy. Segment your network and break everything into its own role. Setup the core and branch out as you go. Look into highly available setups for the various services.

Good luck

Swapping a router with some sort of manual failover process is easier IMO than trying to go HA and full enterprise stuff. Question is what downtime costs you and what your mean time to recovery would be if something did go wrong.

Adding system complexity and trying to go for redundancy can reduce uptime if not implemented correctly. One also needs to be careful about building something that only you can support. What's your "bus factor" here =P

Since OpenWISP was mentioned, I wanted to share a WPA Enterprise Tutorial fo r OpenWrt and OpenWISP.

1 Like