Packetfence - Network Access Control

All of us need to control who can get onto our networks (at least, we OUGHT to control who can get onto our networks...). Whilst there are many potential solutions, we want one that is reasonably easy to use, scalable, flexible, resilient and low cost (free is good). Such systems are generally discussed under the tech term "Network Access Control". In this blog post, I'll be covering the basic installation of one such technology - PacketFence.

In particular, the flood of devices triggered by "BYOD" means you're probably going to want a slightly more scalable, rigorous and user-friendly mechanism for sign-ups that doesn't involve filling in bits of paper and manually registering devices. It is quite something when several hundred users turn up and immediately want to get onto the network (at the beginning of 2015, it took us around 2 weeks to deal with the first influx of BYOD for just two grades of official BYOD, and those bringing personal devices onto campus "for fun" - this year we're adding three more grades; we were using Active Directory integrated MAC Authentication; now we've mostly moved to 802.1x, but the solution isn't quite where I want it to be)...

What we want to do is:

1. Ensure that users can only "register" a certain number of devices, depending on their user class. Whilst you may be able to use something like Active Directory to authenticate user credentials, it does not keep track of (and limit) MAC addresses used, and allows people to use as many devices as they feel like (trust me that students will work this out quickly). Policy and rules only take you so far; sometimes, you have to enforce rules with tech!
1.  So, for instance, you may want: 
1. staff to have as many devices as they want (because if they use more, they can support more BYOD OS ecosystems in class!); 
2. students in the formal BYOD deployment get two (an official work device, like a tablet or laptop, and a smartphone or other WiFi equipped "play" device); 
3. other students get one "play" device. 
2. With many network access control systems, you can "cap" the number of devices registered per user - which is very useful. 
2. Allow self-registration of devices, based on user class rules.
3. Integrate with our existing user directory (AD/LDAP).
4. Have a fairly flexible "guest" network.
5. Potentially, hook into the federated eduroam network (which many of our student assistants, who are registered at the local university would find useful) - sadly only as a service provider given the rules. 

You may wonder why we want to limit per user BYOD device numbers - it's primarily to (attempt to) manage bandwidth demands. I've noticed that kids will stream as much rich media on as many devices as they have simultaneously. Why, I don't know, but they do it. There are also other scarce resources like IP addresses (although we're mostly forced to use NAT given our limited pool of non-RFC1918 addresses).

You may find certain jurisdictions require you to keep records of devices you give network access to (in South Africa, that law would be RICA). You should probably also keep a record that matches IP address (DHCP leases) and times back to MAC addresses - particularly if you use real world IP addresses (most of us will sadly have to use NAT). NAC may or may not help you do that, depending on how it works and what logging you do. Make sure anything that logs has reasonably accurate time, preferably tied to your country's "official" source of time.

Packetfence

Introduction

Packetfence is a neat open source solution to enabling Network Access Control. In this blog post, I'm going to cover setting up PacketFence from the PacketFence ZEN (Zero Effort NAC!) .ovf template, which you should install on a compatible virtual machine hypervisor. This is designed to be very easy to configure in a "try before you buy" kind of way. You can also of course deploy it from the full installer and configure everything yourself, but this "preinstalled" version is much more in line with the amount of time the typical school sysadmin might have to evaluate a potential solution.

I'll be using (free) VMWare ESXI as the hypervisor for this example (if you've not got it set up yet, see here). You can also use it in a "liveCD/USB" mode, but we are not going to configure that here. You could also theoretically use Hyper-V if you're more "Microsoft-y"; you will, however have to convert the image using a tool like this to do so.

Installation Steps

1. Download the required software (a compatible hypervisor and the Packetfence ZEN .ovf)
2. You will generally need a minimum of four VLANs; setting these up is beyond the scope of this article (and often differs greatly depending on your setup), but you generally need Registration, Isolation, Management and LAN VLANs. In this example, I'll be using something closer to our wireless production network - Registration, Isolation, Management, Guest, Junior Student, Senior Student and Staff. If you're not using VLANs, you really ought to do so; PacketFence supports an "inline" mode of operation, but it is limited and we will not be covering it here.
   Make sure those VLANs are trunked through to your hypervisor on the NIC(s) you want to use. 
3. Once the hypervisor is installed and configured (with the requisite VLANs available), you need to deploy the .ovf template. I'm using 5.4.0 in this example. Open the .zip file and extract the .ova inside to a known location
4. In vSphere client, connect to your ESXI host and load the template (File>Deploy OVF Template...). In the window that pops up, navigate to where you just unzipped the .ova file; select it. Follow the wizard through, choosing sensible options for your environment. Don't choose to turn the machine on at the end; you will probably need to tweak some settings (like VLAN assignments/NICs) before turning it on.
   It uses around 8 gigabytes of RAM and 50 Gigabytes of disk space, and configures itself with 2 vCPUs; make sure you have enough resources to support that!
5. The wizard will then take some time to expand and provision the virtual disk image. Wait until this is complete. 

   

   Completed deployment
   (We use dragon themed host names for servers around here due to there being a wyvern on the school's crest)

6. Networking: I recommend using a dedicated NIC port for this on your hypervisor. On the switchport it connects to, create a trunk port with all the VLANs you need to enforce, ensuring the Management VLAN is untagged (native/pvid). Create a new vswitch; put it in all VLAN mode (4095). Ensure it is put in promiscuous mode so that you can see all the traffic, otherwise things might not work too well. 



Ensure you have Promiscuous Mode enabled.

7. Power on the VM. 
8. Watch the console; you will see the CentOS 6.7 guest OS start up.
   

   

   CentOS 6.7 starting up. 

9. Eventually, you will see a login prompt. On your workstation, connect to the full URL given in the CLI Prompt to do the setup.
   

   

   Login prompt with web URL
   Don't forget to use the HTTPS:// in front; you will get an error if you use plain http.

10. Accept/bypass any privacy warnings due to the untrusted rootCA. 
11. Select the VLAN configuration mode:

    

    Select VLAN enforcement mode, click Continue

12. Configure all the required network interfaces; you will need VLAN IDs, IP addresses, subnet masks and default gateways for them all (it's outside the scope of this guide to set these up; you should know how to do this as a sysadmin on your system!). When you create the subnets, make sure they are adequately sized for your expected usage patterns (i.e. is a /24 big enough?). 


1. Management VLAN should usually be that on which your network equipment management interfaces are (what happens if you have more than one of these?)
2. Registration VLAN is that on which devices seeking access live; packetfence will install a DHCP server here, so use the IP Address as whatever you usually number your default gateway (typically high (often .254) or low (often .1) throughout a network; I inherited a "high" numbered network, but I prefer low). 
3. Isolation VLAN is that into which devices that are "naughty" are placed; again PacketFence will run a DHCP server here. Make sure you document these ranges in your IP Numbering Plan, so you don't end up hitting a nasty surprise several years later... 
4. Add all your NAC-requiring client VLANs. We have quite a few...

   

   Step 2 with many VLANs

13. Click Continue. 
14. Set up MySQL credentials. Keep them somewhere safe in case you need them. KeePass may be a good idea if you haven't already implemented some other reasonably safe credential storage system. Take a look at point 47 below for some problems you may like to consider if you pick properly random passwords.
15. Setup the packetfence database
16. Setup your Packetfence MySQL username and password (store them somewhere safe) - make sure they are strong as if anyone gets in, they control your network access and can wreak merry havok on your SQL data...
17. (Save your keepass database in case of crash now!) - I've not taken a screenshot of Step 3 for perhaps obvious reasons; the screen has plenty of helpful prompts on it; you won't go wrong if you follow them. 
18. Click Continue
19. Set up your server's name, domain name and other parameters.

    

    Complete Step 4. Bcrypt is good!

20. Continue
21. Change the password for the Admin user. Again, make it something secure! (and again, if you're using Keepass to store non-memorable passwords, save it, back it up...). 

    

    Change the Admin Password.

22. Continue.
23. Click Start PacketFence

    

    After you click Start PacketFence, the various core services will start up... 

24. You're probably going to want to ensure the server has accurate time. Make sure it can reach NTP servers on the Internet (configure your firewall appropriately). Our upstream ISP blocks NTP (except to their 3rd tier NTP server), so you may need to reconfigure the /etc/ntp.conf file to work in your environment from the packetfence server shell. 
25. Wait until all the services are started. Of course, mine didn't... At this stage, you may need to RTFM. (5.5.0 ZEN deployment guide). RTFMing didn't help much. Eventually, I discovered many of my woes were underlain by a complex MySQL user password probably not being parsed from the configuration files properly. 

    

    Mine got stuck. Zero effort they say...?

26. It turns out (not surprisingly) that PacketFence doesn't like multiple management interfaces. Don't think you're being clever by setting up your "legacy" management VLAN and your "future" management VLAN at this stage... Only set a single VLAN to be (each of) Registration, Management, and Isolation. 

    

    More Green Is Good...
    See point 47 for some reasons why these last few might not start.
    Hint: complex passwords for the packetfence database user might not be a good idea.

27. Ensure the FQDN you set up in step 19 can be resolved...
28. After quite a bit of patience, the various services should start. Once they've all started, there ought to be a prompt inviting you to go to the management interface. If they don't, you're going to have to log into the shell and figure out what is going on using logs. The login credentials are giving in the manual.
    While you're there, change the root password from the default...!
29. It's a poor show, but it turns out that Heartbleed still rears its ugly head... 

    

    Really? Zero Effort and you haven't patched heartbleed to let a core part of the NAC start...?
    Freeradius (radiusd) will refuse to start.

30. You've got two options: Patch OpenSSL or tell freeradius to just ignore the vulnerability.
    Ideally one would patch, and the normal thing to do would be to use the builtin update tools (package manager) - because heartbleed was discovered in April 2014, you'd expect it to be patched by now.
31. yum update should upgrade all your software to the latest available versions.
32. Packages are managed with yum in CentOS. For whatever reason, the latest packaged version of OpenSSL for CentOS 6.7 is 1.0.1e, and that was already installed (and might be vulnerable). However, after doing more reading, it seems if the version is 1.0.1e-16 or later it is not vulnerable to heartbleed. So as this is 1.0.1e-42, we're going to override the Radius security setting. If you want to get a later version, you're going to have to compile it yourself or find an RPM somewhere - exercise for the reader!.
    To find your version, in a shell, type rpm -q -a | grep "openssl"
    You may like to play around with the fastestmirror configuration file to make sure it's getting the fastest possible server (.ac.za are likely to be orders of magnitude faster for me because of SANReN). 
33. Therefore, we're going to tell freeradius to put up with what looks like an unpatched version (but isn't).
34. Edit the allow_vulnerable_openssl line in the security section of /etc/raddb/radiusd.conf to allow CVE-2014-0160 by changing the no to a yes. 
35.  In /etc/init.d/ issue a ./radiusd start command
36. You will be greeted by a friendly green [ OK ]
37. Go back to the web configuration screen. It will still tell you radiusd has not started (even though a ps -aux | grep radiusd tells you otherwise).
38. At this stage, I decide it's time for a reboot. Issue shutdown -r now at a command prompt. Because.
39. That doesn't help
40. There are error messages complaining about FQDN not resolving. 
1. Edit /etc/sysconfig/networking so that the HOSTNAME= your actual resolvable FQDN server name. 
2. issue hostname <your FQDN>
41. Restart networking (service network restart)
42. If the hostname in the shell prompt changes to the FQDN, carry on. Otherwise redo step 38. 
43. Issue a service packetsense restart - and watch for things that fail. Another configuration error crops up in collectd, which causes radsniff3 to also fail. 
44. At this point, you're probably starting to bang your head against the desk. I know I was. So, skip the wizard...!
45. Connect instead to http://<IP>:<port>/admin/ and login with the admin credentials you specified earlier. 
46. If things are still wonky, check all the logs in /usr/local/pf/logs/ particularly those relating to services that fail to start; I eventually found RADIUS was chocking on MySQL connection which lead me to the conclusion (and resolution) of the point immediately below. 
47. It turns out that MySQL kind of sucks (at least the implementation where credentials are passed from a config file). If you use complex passwords, it's likely to croak. Just use plain ASCII (letters and number) and you should be OK. If you reset this in MySQL and the two config files (pf.conf and pfconfig.conf) you should find everything launches...
    

    

    Finally all green!!!

1. I've been bitten by this before. Quite annoyed it took me this long to remember about complex MySQL user passwords underlying much misery. I strongly suspect it's when you include brackets that chaos breaks loose.
2. If it doesn't launch, make sure you go over all the various things I discussed already, and, if necessary, start diagnosing the various log files; 
1. /var/log/messages
2. /var/log/radius/radius.log
3. /usr/local/pf/logs/
4. If you've not used linux CLIs before, you will find the commands cat, tail and vim very useful for viewing and editing log and config files. Be very careful what you do, as by default, you login as a super administrator (root); linux assumes you know what you are doing and does not generally (unlike windows) attempt to help you not to shoot yourself in the foot!
48. Joy! The configuration wizard completes...!

    

    AT LAST!

49. Click on the Visit Administration Interface Now! button.
50. Login using the username and password you set up in step 21.

    

    Login prompt

51. That's the basic installation completed. 

The next post will look at actually configuring things to be useful.