Skip navigation

Tag Archives: RADIUS

When I took on the role of Systems and Network Administrator at my work, we had been using a Linux-based software firewall as the backbone of our network.  In fact, up until about seven weeks ago, we’d been running the same hardware box for around seven years.

Then it crashed.

Luckily, the crash was caused by a problem with the motherboard, and we had a recently-decomissioned server running on the same hardware that we could just swap in without too many problems (though I did spend most of a weekend at work getting everything back up and running).  After we got the firewall back up and running, though, more and more problems started coming out of the woodwork.  Our RADIUS-based MAC authentication was spotty sometimes, and whole classes were unable to access the network.  It was clear that something had to change, but until we could isolate the problems, we couldn’t even start.

Consultants were consulted, outside eyes looked over our infrastructure, and there was an “aha!” moment.  The Linux firewall, the heart of everything, had become insufficient.  Every year, we’ve added more devices, and with the pilot of a one-to-one iPad program in our middle school, we had hit the breaking point.  If our firewall had only been doing firewalling and routing functions, we might have been able to go on for another year, but with iptables, RADIUS, squid caching, routing, and DHCP all running on the same box, with pretty much all of our traffic making several trips through the one internal interface, the system bus, and asking for CPU clock cycles on our firewall, there was no way that we could sustain the model indefinitely.

So what did we do?  We made a major overhaul of our core infrastructure, moving different services to different hardware.  You can (for a pretty penny) get switches that do both layer-2 switching and layer-3 routing at line speed.  We had a firewall appliance that had never been fully deployed before precisely because it takes a lot of work to break out all the services we had running on our firewall and keep everything running smoothly without the end-user noticing a change.  Of course, with such a big change on an inherited network, there are things that didn’t get caught right away, but that always happens.  After some late nights, our network has smoothed out to the point that I’m not just putting out fires constantly.

But where does this leave the Linux firewall?  While I have a working, if somewhat limited knowledge of Cisco switching, wireless, and internet-telephony solutions, their security appliances and layer-3 switches are mostly foreign to me.  I won’t claim that I’m an expert with iptables, but I knew my way around the command well enough to maintain things.  But the question is larger than this one case.

For small and even medium businesses, a Linux firewall is probably still the best, most economical choice if you have a serious network, as long as you have or are willing to gain the appropriate Linux wizardry, with the caveat that that box should only be doing firewalling and routing.  If you have other services that you need to run on your network, put them somewhere else, especially if you’re running something like RADIUS, where timely response packets are required for authentication.  However, if you’re supporting many hundreds of devices across multiple VLANs and expect to expand even further, a hardware-based solution will be a better investment in the long run, even if it’s a greater initial expense.

Advertisements

So I’ve got two different cloud-controlled AP in my office right now.  The Meraki is now hanging up on our equipment rack through creative use of the provided mounting hardware, and the Aerohive HiveAP 121 is sitting on the workbench, waiting on the authorization email from Aerohive that will get me set up with their cloud controller.  I really like the idea behind these things.  We have a fairly large campus, and it’s expanding to across the street, which is miles away as far as I’m concerned, so I’m really interested in the idea of being able to manage our hardware from anywhere, whether I’m in the office, at home, or even (if the need were to arise) on vacation, as long as I had web access.  There are some things that I find bothersome, though.  Chief among those things is how many of my resources I have to make security exceptions for in order for these cloud-controlled APs to work seamlessly with our existing system.  Maintaining a level of security is part of my job description, so I don’t like the idea of putting a path between the web and the closed-garden systems on my network.

My most recent frustration in this regard cropped up today, just after I thought I’d sorted my previous problems out.  Our traditional APs are all controlled from an internal-only VLAN, and they sit on trunked lines that give them access to our other networks for the business of actually accessing the internet wirelessly.  That model, I’d already figured out, wouldn’t work right out of the box for the Meraki AP because there needed to be a path to the outside world so the cloud controller could talk to the AP, so I put the AP on a different network that can get out without a fuss.  But then: problems.

As I think I’ve mentioned before, our student and instructional networks authenticate clients against a RADIUS server that we have on campus.  Well, I know how to set up an AP to authenticate against a RADIUS server, so I thought there wouldn’t be any differences when it came to hooking the Meraki up to the thing.

What I didn’t know was that the cloud controller needs to access the RADIUS server, which would mean putting a hole in the firewall for that purpose.  I’m not particularly excited about that prospect.  I can see how it would be nice to have the RADIUS server accessible from the outside–we could, for instance, set up a remote AP at a totally separate site and let users authenticate normally.  Still, in the context that I’m using, or trying to use these APs, which is to say as nearly-pnp devices that I can just drop into my existing network with a minimum of fuss so I can put them through their paces to see whether I really want us investing in this technology (and in theory, I really would like to deploy these things).  In practice, this just hasn’t been working as I’d hoped.

In the end, I may just grin and bear it if I have to open some holes in order to make things work the way I’d like, but I really wish that there was an option to let these APs work with our existing RADIUS server without making that server available to the outside world.  After all, except for the cloud controller itself, which is in a server-farm somewhere (probably in California), everything I’m working with is inside one discrete network, so all the hardware involved should be able to talk amongst themselves.

Last week, I attended a webinar (I don’t like that word) presented by Meraki on the subject of BYOD solutions in a K-12 environment.  The presentation was interesting, certainly, but perhaps the best part was that, as a technology professional and as someone who makes purchasing recommendations for an organization with a budget for technology, I qualified for getting a free access point from Meraki.  Specifically, they sent me an MR12 access point and gave me a free several-year license for their cloud controller to go with it.

In case you don’t know Meraki’s deal, they make a full range of network hardware–APs, switches, and security appliances–which can be managed through the cloud from anywhere.  They also claim that, once you have your cloud controller set up, you can configure a new AP in as little as 15 minutes.  These are things that I like.  I also like getting free things to try out, so I was happy to get an opportunity to evaluate their hardware.

Simple packaging makes me happy.

Nothing superfluous here.

First of all, simple packaging makes me happy.  The box was just big enough for the AP, some mounting hardware, and a bit of padding to keep the thing safe.  No excess packaging.  There was barely any paper literature included in the box, either–just a single piece of paper listing the contents of the box and explaining, in short, that in this digital age, it’s stupid to print out documents that most people are going to throw away or lose anyway.  The access point itself seems to stick to this philosophy as well with a very spare aesthetic that I imagine would be next to invisible when deployed.

(Note, you don’t hear me talking in this unboxing video because I hate hearing my recorded voice and because narrating unboxing videos just seems awkward to me.)

So what happens after you get the thing out of the box?  Well, in my case, a lot of frustration to begin with.  My initial attempts to configure the AP as if it were any other of our APs, putting it on our control network with a static IP, putting it in bridge mode so that clients connected through it are on the LAN, and setting it up to authenticate against our RADIUS server, then making sure that the switch port it’s getting plugged into is associated with the right VLANs.

Then I plug it in and nothing works.  Sure, the power came on and I could see the AP on the cloud controller page, but the controller was reporting that the AP had never connected to the cloud controller, and the lights were flashing in a way that told me that it was getting a bad gateway.  That ain’t no good.

Well, I read through a lot of documentation, tried some things, and basically frustrated myself more working on it while during the afternoon when I kept on running off to attend to more urgent matters.

Wawa travel mug for scale (and because it was there first, and I'm not kicking it out of its home for some upstart AP).

Wawa travel mug for scale (and because it was there first, and I’m not kicking it out of its home for some upstart AP).

Today, after some more fiddling with the firewall and quiet swearing, I decided, what the hell, I’ll just plug it in to a regular network port, not trying to put the thing in Bridge mode, and just hoping that it would work as simply as I’d been promised.  Wouldn’t you know?  It worked.  It came on no problem.  The lights all went green (well, the power light started flashing orange after a bit, but that’s because it was updating the firmware for the first time, but after a reboot, it came back on no problem).  So now it’s sitting on my desk, plugged into the only network cable I had on hand, which is going through the switch in the back of my desk phone.  Maybe it’s not ideal, but I can finally start messing around with the cloud controller some more and really get an idea of what I’m working with and if I’m going to make the recommendation that we invest in Meraki hardware as we expand and upgrade our wireless.

Expect to see more about this hardware and probably some competing wireless solutions on here in the coming weeks.

Today’s awful-looking (though fairly tame) regular expression comes to you from my work at making my life, and the life of anyone who comes after me and still has to use our RADIUS server that much easier.

We make, edit, and delete entries from our RADIUS server’s database using the wlesscmd command which includes a list option that takes a string and gives back a list of entries that match that string. We use this in conjunction with the -n (note) option to give us an idea of who a particular MAC address belongs to when we’re looking at logs and whatnot. It’s also useful for doing housekeeping–we make a note of a student’s graduating year whenever we put one of their devices into the system so we can clear out batches of graduating students. The output of the list option looks something like this:

STUDENT 2010 Mike Jones lappy 1a2b3c4d5e6f STUDENT
STUDENT 2010 Janet Jones phone 0f9e8d7c6b5a STUDENT
...
STUDENT 2010 Frederick Wong lappy 5b8a9d4cfeef STUDENT

Which isn’t quite as nice as the comma-separated sheets that get used to add lots of devices all at once.

Enter the regexp.

sed -e 's/\([^ ]*[ ]*\)*\([0-9a-f]\{12,12\}\)\([ ]*[^ ]*\)/\2/g'

First, it looks for the note, which is any number of characters separated by any number of spaces any number of times: \([^ ]*[ ]*\)* . Then it looks for something that looks like a MAC address, which is exactly twelve hexidecimal numbers (0-f): \([0-9a-f]\{12,12\}\) . Finally, it looks for an SSID: \([ ]*[^ ]*\) . Then, sed takes just the MAC address, represented by \2 (the second regexp) and (in a code segment that isn’t included here) appends it to a temporary file of MACs prepped for removal.

This has been your scary-looking regular expression for the moment.