Archive for January, 2015

As I’ve secured my main Wi-Fi network with WPA2 Enterprise, my Apple Airport devices are pointed at a RADIUS server, which in turn is pointed at an LDAP directory which contains the user details. The LDAP directory does not store the password in the clear which means that authentication methods like CHAP, MSCHAP and MSCHAPv2 don’t work as they require the original password. I need to use EAP-TTLS with PAP authentication however iOS and OS X clients will not attempt this method by default.

It’s theoretically easy to make iOS and OS X clients use this method, you simply install a Mobile Configuration Profile (a file with a .mobileconfig extension) which amongst other things instructs the client how to connect to a given Wi-Fi network. The tricky part is generating this file if you maybe don’t have access to an OS X Server. Apple originally provided the iPhone Configuration Utility (iPCU) which has been deprecated in favour of the Apple Configurator utility. This works fine for iOS devices that you can attach directly by USB but sometimes you might want to transfer a profile to someone via e-mail or install it on an OS X client. It’s not obvious how to export a profile from the tool, but there is a way.

When you open Apple Configurator it looks like this:

If you enable Supervision the Profiles section changes to allow you to click + and create a new profile:

In my profile as a minimum I needed to import the root certificate of the authority used to sign the certificate on my RADIUS server. Then configure my Wi-Fi network with the SSID, Security Type, EAP Type of TTLS and then select PAP as the Inner Authentication. I also trusted the certificate I’d just imported which prevents iOS and OS X prompting you to trust it. By not setting the Username and Password this keeps the profile generic for any user. Then after saving the profile you can then export it:

This gives you the familiar .mobileconfig profile which can then be imported on any iOS or OS X client.

The feature of being able to configure a separate guest Wi-Fi network has been present for a while now on Apple Airport gear. However, the documentation only ever alludes to this feature working when the Airport device is running in router/NAT mode, i.e. it’s in charge of connecting directly to the Internet and sharing the connection from your ISP.

Quite often people (like myself) use the Airport device(s) in bridging mode, i.e. as regular access points to attach Wi-Fi clients onto the Local Area Network and then some other device handles the routing and NAT function, (in my case an OpenBSD host), and it would be nice if you could also create a guest Wi-Fi network in this mode. The obvious way I would expect it to work is to utilise VLANs; the Airport device uses a single unique VLAN ID to tag Ethernet frames from clients on the guest Wi-Fi network. As the administrator you can then use that tag to segregate the traffic on your network; usually to allow guests some form of heavily-restricted Internet-only access, and not be able to access the rest of the network. The Airport Utility lets you create the guest network in bridging mode but doesn’t give you any details as to the mechanics of it.

Well it turns out my hunch was correct, it does use VLANs; Ethernet frames from clients on the normal Wireless network stay untagged so they Just Work on your network as before, however Ethernet frames from clients on your guest network are tagged with the VLAN ID 1003. This ID is not mentioned anywhere, nor can it be changed so you’d better hope you’ve not already used that ID for something else.

Armed with that information, I configured my Cisco SG300 switch like so:

This creates the VLAN, names it, configures two trunk ports where my Airport and OpenBSD router are attached and adds the new VLAN to the list of allowed ones on each port. Finally all that is left to do is to create a VLAN interface on the OpenBSD router:

Providing any DHCP and/or DNS services and firewalling the traffic is outside the scope of this post but you now have a separate interface and subnet that you can treat it like any other regular network.

So now I have two separate wireless networks; one that gives me access to my LAN which I can secure using WPA2 Enterprise and another that can only reach the Internet which can be unrestricted or more likely secured with WPA2 Personal.