We have had a similar experience with PacketFence as Temple.  Everything we 
looked at was overpriced, for us, in the six-figure range especially when 
compared to everything PacketFence offered us for only the cost of ongoing 
support if we so choose (other than the equipment for the box to house it).  We 
started with Bradford years back, but dropped it for a home grown solution that 
only provided DNS redirection and was rather easy for a knowledgeable 
individual to circumvent.  We dropped that solution for PacketFence in order to 
deploy secure wireless via 802.1x across campus.

We have been using Packetfence for over two years now.  We began deployment in 
our student reshalls and moved over to academic buildings last summer.  We send 
a copy of all traffic to our PF box using RSPAN for Snort to take a look at it, 
but we don't have the staff to really customize much, so we just have some 
default rules in place.  I have been able to customize some of the violations 
in the system to prevent 3rd party router connections, remote desktop scans, 
and some other basic policies the system provides.  The remediation pages were 
very easy to configure and seem to do a good job informing the user what steps 
they need to take for self-remediation.  We've customized the amount of times 
they are allowed to self-remediate as well depending on the violation.

We have our employee machines rather locked down and feel confident in our 
antivirus solution, so we do not really have much of an issue with remediation 
on those devices.  All updates to OS and AV are centrally managed, so it is 
rare that a machine will be out of compliance unless it is a personal machine.

For guest access, we use a mixture of guests who pre-register themselves and 
are e-mailed credentials to use upon their arrival, guests who are sponsored by 
a faculty or staff member upon their arrival to campus (for special presenters 
and other one-off visitors) and bulk account creation for larger groups.  
Offering these options seems to meet the needs of a majority of individuals 
across campus that requires guest registrations while still giving us username 
to machine accountability.

For our wired access, we are currently using port-security on all Cisco devices 
but would like to move over to 802.1x on our wired network sometime in the 
future.  As far as compatibility, we only had issues at first on old 
non-supported Cisco devices.  We've upgraded our wired network to mostly 2960's 
but still have some 3560s and 3750s and we have not had issues with Packetfence 
compatibility on these devices using the port-security setup.  Some of our 
3560s required a firmware update for everything to work properly, but that 
needed to be done anyway.

Similar to UTC, we also separate devices based on their role.  We have our PF 
deployment configured to auto-register printers upon connection and move them 
into our printer vlan across campus.  We use the same process for student 
gaming consoles in the reshalls since a few are not intuitive or browser 
enabled.

The support from Inverse has been great for us, and any time we've had a 
question, they've helped or provided a customization to suite our needs.  Thus 
far, we've been very pleased with the solution as well as Inverse's support.


Isaac Lopp

Technical Support Center Manager
support.ship.edu<http://support.ship.edu/>
Shippensburg University
(717)-477-1639

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:[email protected]] On Behalf Of Osborne, Bruce W
Sent: Friday, April 27, 2012 8:09 AM
To: [email protected]
Subject: Re: [WIRELESS-LAN] PacketFence

That's interesting, Jeff.

Your history is very similar to ours here at Liberty University, but we are 
taking a slightly different approach.

We were one of Cisco's first CCA customers after their takeover of Perfigo. 
Some of our people visited Perfigo during our evaluation of the product. That 
was before I worked here.

We found CCA to be a management nightmare with a large number of servers. The 
summer after Windows Vista was released, our semester startup was a nightmare. 
CCA was requiring patches that had been superseded earlier in the week during 
patch Tuesday. These patches were no longer available. Cisco TAC was not any 
help. Our only option was to manually customize the CCA rules to not require 
those patches.

We then started investigating alternative NAC solutions. As we started 
evaluating Aruba Networks branded Bradford solution, it was obvious that to 
deploy that solution, we would need to replace our Cisco fat AP wireless 
infrastructure. After almost 2 years of evaluation, we deployed Aruba's 802.11n 
wireless solution along with their rebranded Bradford NAC. Our NAC initially 
went from 32 CCA servers in high availability mode to 4 Aruba ECS server in HA 
mode. Due to scaling issues, that number increased to 10 servers and some of 
our NAC manageability issues returned.

We started looking seriously at NAC alternatives, in addition to NAC solutions. 
In tandem with this project was an Internet bandwidth management & chargeback 
requirement. We  looked closely at PacketFence and impulse point SafeConnect 
NAC solutions. We decided that wired & wireless 802.1x would be needed to 
properly identify traffic for bandwidth chargeback

We tested PacketFence mainly with Cisco wired switches because they appeared to 
have better support for the Cisco switches than Aruba wireless. Their solution 
initially did not work with our Cisco 3750 access switches, even though they 
are officially supported. We ended up submitting a patch after we were told 
they did not even have any of these switches for testing.

A year ago, when we looked at SafeConnect, they did not have a user 
self-registration solution. We liked their product for both Aruba wireless & 
Cisco wired, but the lack of the user self-registration feature for non-802.1x 
devices led us elsewhere.

One of our preferred vendors, Aruba Networks, subsequently purchased the Avenda 
NAC solution and renamed it to ClearPass Policy Manager.  This summer we are 
deploying ClearPass as our RADIUS, mac authentication, and registration 
solution. Although ClearPass is a NAC, we will not be using that feature and 
did not need to license it. We will initially use Cloudpath XpressConnect for 
802.1x provisioning until Aruba's solution is improved. ClearPass will feed 
connection data to our Procera PacketLogic solution for bandwidth management.

Rather than NAC, we will be using the Aruba Networks firewall roles to restrict 
student users from staff. On the wired side, we will be using ACLs to restrict 
internal student access. The Cloudpath initial provisioning solution allows us 
to perform a one-time NAC check.

Bruce Osborne
Network Engineer
IT Network Services

(434) 592-4229

LIBERTY UNIVERSITY
40 Years of Training Champions for Christ: 1971-2011

From: Jeff Kell [mailto:[email protected]]<mailto:[mailto:[email protected]]>
Sent: Thursday, April 26, 2012 9:26 PM
Subject: Re: PacketFence

On 4/26/2012 4:13 PM, Mark Duling wrote:
I think many have found enforcing remediation of NAC to be problematic with an 
increasingly protected and sophisticated user base.  Whether or not to do 
posture assessment and enforce remediation seems to me to be the main 
determinant of how much one needs to spend, rather than the vendor of the 
solution chosen.

We are at somewhat of a crossroads, and about to embark on an experiment...

We were an early Perfigo customer, following the fallout from 
Slammer/Blaster/Nachi/etc.  We carried over to the Cisco takeover, and stuck 
with Cisco until the release of Windows Vista, which was not supported by our 
CCA version (and not maintenance-upgradeable either, it was a large 
re-licensing/repurchase path, and the "new" version did not support all of our 
"old" switches, so there was a 6-figure "update" projected).

We then went with Bradford.  After an initial learning curve / implementation 
smoothing, it took the place of CCA rather well, and relaxed the Cisco 
end-to-end dependence that CCA required.  It did a spectacular job of network 
tracking and management (it's hard to tie a time, MAC, IP, hostname, 
switchport, and userID together in one place, and searchable to boot).  The 
"posture assessment" worked well for OS / AV, but in today's world, that is 
hardly sufficient given the plethora of exploit kits targeting Flash, Java, 
Acrobat, Shockwave, etc.

The "remediation" is the klunky part, and if you enforce it brute-force 
captive-portal style, you are due for some serious feedback if not outright 
outrage.  The current versions of the software allow for "delayed" forced 
remediation, so you get an obvious indication that you are out of compliance 
(icon in system tray bleeps at you like the windows update one does) for a 
configurable number of days before remediation is enforced.

But just "getting out of remediation" is somewhat un-intuitive.  You have to 
remediate yourself, more or less, but the icon remains "at-risk" until you 
navigate to the portal page and initiate a re-scan (users typically expect that 
to reflect their status in "real-time" and get confused when it doesn't change 
after they patch).

We ditched forced remediation over a year ago, but still very much use the 
tracking, and even do role-based port security based on registration to 
separate various user groups, printers, special devices, and so forth on their 
own vlans.

For security incidents, e.g., IPS/IDS detected infections, you still have the 
"quarantine" mechanism available to you.  Quarantine overrides everything and 
keeps infected machines in their own captive portal, regardless of where they 
connect; and if the device is registered, it carries over to every network 
interface on the box (e.g., wired, wireless laptop).

Our current "experiment" is looking at IBM's Tivoli Endpoint Manager (a.k.a. 
BigFix) to handle the remediation cases for university-owned equipment.  With 
the BigFix agent in place on the machine, you can have it do the remediation 
steps automatically (you just push the needed "fixlets" to the device yourself).

We hope this will provide the "missing link" in the whole policy / posturing / 
endpoint compliance picture while incorporating the common third-party 
applications as well.

Will see how it goes :)   If anybody else has "been there, done that, go the 
T-Shirt" I'd be interested in any stories you can share, good, bad, or 
otherwise.

Jeff
********** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/groups/.
********** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/groups/.

**********
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

Reply via email to