Bring Your Own Device – A Technical Perspective

This is a description of how I have set up our Bring Your Device solution at my current school. It makes use of the following hardware and software:

  • Smoothwall UTM1000
  • Netgear WC7520 WiFi Controller
  • Netgear WNDAP360 and WNDAP350 Access Points
  • Netgear GSM7328S v2 L3 Switch
  • Netgear GS724TPS Smart Switch
  • Microsoft Server 2008 R2 NPS RADIUS Server
  • Microsoft Server 2008 R2 DNS and DHCP Servers

Here is my diagram of the completed set up:

BYOD Setup - 20130117

So let’s get straight into some detail…

Switch and VLAN Configuration

To start with we designed the VLANs for our network. We are running two separate BYOD networks, one for staff devices and one for student devices. The two VLANs were created on all switches which they would need to travel across but were not set up as routed VLANs on our L3 switch.

Let’s say Staff BYOD is VLAN 300 and Student BYOD is VLAN 305. All links between all switches and WAPs are Tagged members of both VLAN 300 and 305. We then define two ports on the main L3 routing switch which are an untagged member of VLAN 300 and 305 respectively. A cable from these two ports are then connected ports 2 and 3 of the Smoothwall UTM. See the section on configuring the Smoothwall for more details on this.

That’s really it for the switch configuration. In essence you now should have three separate networks; one for each BYOD VLAN and your main LAN, and these networks should not be able to see each other. Now would also be a good time to decide upon your BYOD IP Scheme. I chose a Class B scheme with a 21 bit subnet mask, giving us a maximum of 2046 addresses per network – more than enough I think!

NPS / RADIUS Configuration

I thought the easiest route for our end-users would be if we implemented 802.1x on our WiFi so that they could authenticate with their Active Directory user names and passwords, without us having to configure every device or try to securely circulate WPA2 keys around the school. To do this requires us to set up a RADIUS implementation to handle the authentication of our WiFi clients.

Operating System Choice

I spent a lot of time looking into implementing a Linux FreeRadius install and even got so far as having one installed and integrated into our Active Directory. However it became clear that achieving full integration with our Microsoft Active Directory was going to be troublesome at best and nigh on impossible at worst. I bought up a Server 2008 R2 VM and installed the NPS Role on the server to see if I could have any more luck with Microsoft’s own products integrating with Active Directory. In the end I did get this working, but it was by no means straight forward!

Most of the online guides I found fell by the wayside, and tended to rely upon implementing 802.1x for your own corporate devices and being able to push all the settings out to them via Group Policy. This was not an option for us, as users would have to configure their own devices.

I started out by referring to this MS guide which details the differences between NPS (Their Radius implementation on Server 2008 R2) across the different versions of the Server 2008 R2 operating system. The main difference being that Enterprise and Data Centre versions allow you to configure unlimited Radius clients (WAPs in this set up) whereas Standard version only allows you to configure 50 clients. You can also only define clients as a single entry (IP Address or FQDN) in Standard Edition whereas Enterprise and Data Centre allow you to define groups of clients by IP Address Range.  These two restrictions meant that we installed our NPS / RADIUS server on Server 2008 R2 Enterprise. I would recommend doing the same unless you are absolutely sure that you will never need more than 50 WAPs on your system and that you are happy entering each WAPs IP address individually!

NAP Install and Configuration

Now that we had the operating system installed and the server added as a domain member server, we began to look at the installation and configuration of NAP. I read lots of conflicting information on how to do this and went around the houses quite a bit, but in the end I found this site which really helped me get NPS up and running. I pretty much followed that guide to the point of issuing the self-signed certificate, and then moved over to the guides on configuring 802.1x for wireless connections using the self-signed cert to secure the communications.
However to be sure that the 802.1x was working I really needed a test laptop connecting via 802.1x over WiFi. To this we needed to set up our WiFi system…

WiFi Configuration

We are using a Netgear managed WiFi controller system (WC7520) with the relevant WAP attached. This system allows up to eight different SSIDs to run from each WAP (16 if you count both 2.4 GHz and 5 GHz bandwidths!), so we configured a new profile for the group of WAPs which had the one by our office in. This was fairly straight forward, and we just followed the Netgear documentation really.

Once we had the WiFi profile up and pointing at our newly configured RADIUS server we could start testing clients!

After a lot of fiddling about with the 802.1x settings on a Windows XP laptop we got it to connect. Great! Now to try an Android phone… Now that was a whole lot easier! We tested and documented the process for the following devices:

  • Windows XP – 8
  • iOS
  • OSX
  • Android
  • Blackberry

We also tested Ubuntu Linux, but figured anyone running Linux could probably adapt the other instructions to get it working!

Smoothwall Configuration

The configuration of the Smoothwall was fairly straight forward. First we configured a spare NIC with an IP address in your chosen BYOD range (I went for the first available address just because that is where I like my gateways to be! After the NIC is configured you can then patch it back to your core switch to a port which is an untagged member of only the BYOD VLAN with its primary VLAN ID set to the same VLAN.

Then we enabled the auto-discovery proxy on this NIC and enabled the proxy.pac file too. ‘

The next step was to enable the Proxy Authentication for this port. We enabled a non-transparent and a transparent policy which both redirect users to a SSL Login Page using a session cookie. As our users would be using their personal devices and we would have no effective way to distribute a self-signed certificate to all devices before they connected, we decided to install a real-world SSL certificate to the Smoothwall for the purposes of the SSL login page. You can read more about the tweaks and ongoing issues that this causes on this post!

Aside from setting up Zone Bridging to enable access back into our internal LAN, that was about it for the Smoothwall set up…

DHCP and DNS Configuration

As we want our BYOD devices to be able to access certain internal servers we needed to bring up a DNS server with a copy of our public DNS zone which points the DNS addresses to our internal LAN IP addresses. We then set the Smoothwall up to allow “Zone Bridging” between the BYOD LAN and the internal LAN to those IP addresses we set up in DNS on the required ports / services (HTTP and HTTPS in the most part).

We bought up a VM for each BYOD network to run DHCP and DNS on and gave them each two NICs. One was connected to teh BYOD network and the other back to the internal LAN for RDP, management and Nagios access. DNS and DHCP were both set to only run on the BYOD NIC and the firewalls were set appropriately to only allow the required services in and out from the main LAN.

The DHCP server set up was pretty much standard. We left some space at the start of the range in case we needed to assign any static addresses and then we configured the scope so the gateway of the network was set to the IP address of the NIC configured earlier on the Smoothwall. DHCP server scope also points everyone to the DNS server and to the Smoothwall for NTP.

That is about it for the technical set up really; now we have a working BYOD implementation the real challenge begins… How to make this have an impact in the Learning and Teaching within the school!

One thought on “Bring Your Own Device – A Technical Perspective

Leave a Reply

Your email address will not be published. Required fields are marked *