Skip Links

Network World

  • Social Web 
  • Email 
  • Close

(Comma separation for multiple addresses)
Your Message:

PacketFence 1.7 offers client-free open-source NAC

Need to deploy NAC, but don't want to manage the annoying client software? Check out a simple open source implementation before you get in over your head.
By Dominik Gehl and Regis Balzard, LinuxWorld.com
August 20, 2008 07:54 PM ET
  • Share/Email
  • Tweet This
  • Comment
  • Print

Do you know who connects to your wired and wireless networks, when and where? Do you know who is using applications forbidden by your network usage policy, such as maybe LimeWire or Gnutella? With the ever increasing number of people accessing your network anonymously or generating illegal activities from it, having reliable security tools is now essential.

A well configured firewall and tools such as Snort and Nessus are important steps to secure your network, but you might be looking for a complementary solution that responds automatically to violations of your network usage policy. It's time to deploy a Network Access Control (NAC) solution on your network.

Almost all switch vendors have their own proprietary NAC which, most of the time, works only with their own hardware. But what if you have a heterogeneous network, or want to customize the solution?

That's where PacketFence comes in. PacketFence is the open source community's answer to NAC.

PacketFence is written in Perl and makes use of common open source components such as MySQL and Apache. It does not require a user agent to be installed on computers accessing the network. Its deployment is non-intrusive, and every interaction with users goes through a captive portal which can be accessed by every web browser.

PacketFence provides an impressive list of features. Among them are:

  • Registration of new network devices
  • Detection of abnormal network activities (computer virus, worms, spyware, etc.) using alerts from Snort sensors
  • Registration-based and scheduled Nessus scans
  • Isolation of problematic devices
  • Remediation through a captive portal

  • VLAN isolation with VoIP support (even in heterogeneous environments) for multiple switch vendors such as Cisco, Edge-Core, HP, Linksys and Nortel

  • Support for 802.1X through a FreeRADIUS module
  • Wireless integration with FreeRADIUS
  • DHCP fingerprinting

 Figure 1: the relations between PacketFence standard features.

PacketFence currently supports ARP, DHCP/DNS and VLAN isolation techniques. Choosing the right isolation method depends on the size of your network and the networking equipment you possess.

In this article, we'll cover VLAN isolation.

What is VLAN isolation ?

The purpose of VLAN isolation is to assign any device connected to the network, an appropriate VLAN based on its MAC, its registration and violation status.

 Figure 2: How PacketFence reacts to SNMP traps

When a device connects to a switch port, the switch sends PacketFence an SNMP trap. This trap is received by the snmptrapd daemon and written to a log file. The pfsetvlan daemon tails this log file and upon reception of a trap, determines the appropriate VLAN for the MAC and then communicates with the switch (mostly using SNMP) to assign the switch port to the determined VLAN. In addition to assigning an appropriate VLAN to devices when they connect to the network, PacketFence can also isolate devices already connected to the network when they violate the network usage policy.

PacketFence can work with different SNMP trap types such as linkup/linkdown, MAC notification, and port security traps. If available on your switches, we highly encourage the usage of port security traps since it is a very efficient mechanism: PacketFence will only receive traps when equipment is newly connected to or moving on your network. The second best option is the combined usage of linkup/linkdown and MAC notification traps. The disadvantage is that PacketFence might receive a high number of traps at periodic intervals due to your switches expiring their learned MAC addresses at fixed intervals and spanning tree recalculations. If your switches only support linkup/linkdown traps, PacketFence can also work solely based on these traps. This implies that upon reception of a linkup trap PacketFence will have to query the switch for some time to determine the MAC address on the switch port (which might take some time).

  • Share/Email
  • Tweet This
  • Comment
  • Print

Comment
Login
Forgot your account info?
Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a NetworkWorld account? Log in here. Register now for a free account.

Videos

rssRss Feed