Tilting at wind… legacy software
Being a WiFi technology provider, we try to support all popular models of access points in the market. Unfortunately, most-if-not-all of wireless points rely on RADIUS for authentication — a technology dating back to 1991, a technology that looks and feels obsolete today in 2017.
Even though DNS was invented almost 10 years before RADIUS, most RADIUS clients require IP addresses to contact a remote server, not a DNS hostname. And that is… awful!
Imagine you restarted your AWS EC2 instance and the IP address changed. Voila — your RADIUS clients cannot reach the server anymore.
Unless you own an IP subnet and you advertise it globally (anycast-style), using hardcoded IP addresses is a terrible thing to do from fail-over, flexibility and any other point of view.
Another issue with this scheme is that RADIUS servers usually require a dedicated persistence store (a database), and we didn’t want to pollute our stack with yet-another database. Databases are boring, databases bring along high maintenance costs, you just don’t want to have too many of them.
While we couldn’t get around the hardcoded IP address thing, because this limitation lives on client side, we managed to make the architecture more scalable and fault-tolerant.
We point WiFi access points to two hardcoded IP addresses, both of which are elastic IP addresses from two different major cloud providers — AWS and SoftLayer. We cannot easily move away from these providers anymore, but at least we can scale services or migrate from instance to instance.
These external IP addresses are running rock solid UDP load-balancers powered by nginx (nginx rocks!), and behind the load balancers there is an infinite number of horizontally scalable Node.js RADIUS-compliant containers.
Of course there is no real RADIUS server anywhere, we don’t want a 1991 technology at our doorstep. Neither there is a database of any kind. Our Node.js instances are simple RADIUS-to-RESTful proxies that translate obsolete language requests from access points to a modern convention of RESTful.
This scheme is not ideal, but it’s much better than the original flow. If you want to improve it further — get yourself an anycast subnet :)