A few months back, I wrote about using IronWifi for WPA2 Enterprise authentication. The problem I was trying to solve back then was not being able to perform RADIUS authentication from an external router, and I thought it was due to NAT (which is easy to blame). IronWifi is great and convenient, but the downside was that instead of using Active Directory, I was simply using Google Apps as a poor man’s LDAP server. This also meant that I needed to maintain two completely independent lists of users (well, user).

I was recently looking into JumpCloud, which seemed like a more robust solution. JumpCloud promises AD integration via their AD Bridge app which synchronizes AD users to their user list. Kind of like what IronWifi was doing with Google Apps actually. One problem I did have with JumpCloud however is that you need to provide a user account on your server with the Read All Users right (okay, reasonable), but that account’s username and password were stored in plain-text in a configuration file (on the server). Sure, that file is locked for reading, and compromising it requires compromising the server first anyways, but I just have that thing against storing passwords in plain-text.

Nevertheless I did not end up using JumpCloud. Because while troubleshooting my JumpCloud RADIUS settings I noticed something while reading their documentation. They mentioned needing port 1812 UDP. It couldn’t be that simple right? Well I checked my port forwarding configuration on my router and sure enough, I set my RADIUS ports to…TCP. Some quick googling confirmed that UDP was what I needed. Most likely when I did my testing locally port forwarding didn’t matter so it worked anyways. So when I turned UDP on everything worked like a charm.

That was a big facepalm moment, but at least I have achieved my original goal (a couple months late) and discovered some awesome services (IronWifi, JumpCloud). One issue still remains to be addressed however, which is the reason I still have one of my WiFi SSIDs point to IronWifi as a fallback: my router firmware doesn’t accept a FQDN or IPv6 address for the RADIUS server field, only IPv4. Static IPv4 addresses are too fancy for me, and I don’t really need one anyways, most of the time. But I’ve had my IPv4 address change randomly a few times now.

One possible solution/workaround would be to ping the RADIUS server’s FQDN for its current IPv4 address, then update the RADIUS server’s IP address field on my router if there has been a change. The second part I imagine can be solved by updating the relevant field in the router’s NVRAM. Update script coming soon I guess…