Deploying Network Access Control with PacketFence: Controlling Internal Network Device Access with Security Policies – ITFROMZERO

It started on a Monday morning — I received a report from the sysadmin team: three employees’ personal laptops had connected to the internal VLAN through a third-floor switch, and nobody knew about it. The network at the time relied on plain VLANs for segmentation, but there was no mechanism to verify whether a connected device was actually trustworthy.

I manage the network for a 50-person office and a small datacenter — that incident was enough to push me into researching Network Access Control. PacketFence is what I landed on after comparing a few solutions.

Table of Contents

What Is NAC and Why Your Network Probably Needs It

Think of it this way: your internal network is like an office building. Right now the front door is wide open — anyone who plugs in a cable gets access. NAC (Network Access Control) is your access control system: devices must “show their credentials” before they can reach internal resources.

PacketFence has been around since 2006 and is currently at version 13.x — its feature set covers nearly every real-world scenario:

802.1X authentication — devices authenticate via RADIUS before the switch grants access
MAC-based detection — identify and classify devices by MAC address
Captive portal — web login page for guest Wi-Fi or BYOD
VLAN isolation — automatically pushes unknown devices into an isolation VLAN
Compliance check — integrates with Nessus/OpenVAS to verify devices before granting access

What I needed most: when someone plugs a personal laptop into a switch or connects to the office Wi-Fi, the system automatically recognizes the unregistered device and moves it to a separate VLAN — completely isolated from internal servers.

Installing PacketFence on Ubuntu 22.04

PacketFence needs a dedicated server — don’t run it alongside other services. Minimum requirements: 4 CPUs, 8 GB RAM, 2 network interfaces (one for management, one connected to your switch/AP).

Step 1: Add the Repository and Install

# Add PacketFence repository
wget https://inverse.ca/downloads/PacketFence/ubuntu/PacketFence.list \
  -O /etc/apt/sources.list.d/PacketFence.list

# Add GPG key
wget -O - https://inverse.ca/downloads/PacketFence/ubuntu/key.gpg | apt-key add -

# Update and install
apt-get update
apt-get install packetfence -y

Step 2: Start the Web Configurator

# Enable the configurator service
systemctl start packetfence-config
systemctl enable packetfence-config

# Check status
systemctl status packetfence-config

Once the service is up, open your browser and navigate to https://<IP-server>:1443. The wizard is quite user-friendly — it walks you through your network topology step by step and generates the corresponding config automatically. Initial setup takes around 15–20 minutes.

Step 3: Declare Network Interfaces

PacketFence needs to know which interfaces to listen on. Basic configuration in /usr/local/pf/conf/pf.conf:

[interface eth1]
ip=192.168.10.1
mask=255.255.255.0
type=management

[interface eth2]
ip=10.0.0.1
mask=255.255.255.0
type=internal

In practice, I usually configure this through the web UI — fewer mistakes since it validates input immediately.

Configuring RADIUS and Setting Up 802.1X Integration

FreeRADIUS comes bundled with PacketFence — no additional installation needed. The next step is configuring your switch to send authentication requests to the correct RADIUS server address.

Registering Switches in PacketFence

Go to Admin UI → Configuration → Network Devices → Switches and add each switch with the following parameters:

IP: the switch’s IP address
Type: select the correct vendor (Cisco, HP, Dell, Aruba…)
RADIUS Secret: the shared password between the switch and RADIUS server
Roles: map role → VLAN (registration VLAN, isolation VLAN, production VLAN)

Configuring the Cisco Switch Side

! Declare RADIUS server
radius server PACKETFENCE
 address ipv4 192.168.10.1 auth-port 1812 acct-port 1813
 key MySecretKey123

! Enable 802.1X globally
aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
dot1x system-auth-control

! Apply to user-facing ports
interface GigabitEthernet1/0/5
 switchport mode access
 authentication port-control auto
 dot1x pae authenticator
 spanning-tree portfast

Integrating Active Directory for User Authentication

AD integration is practically mandatory in an office environment — employees authenticate with their Windows accounts, so you don’t need to create separate accounts for NAC. Go to Configuration → Policies and Access Control → Authentication Sources → Add → Active Directory.

Before configuring, test the LDAP connection from the PacketFence server:

ldapsearch -H ldap://192.168.1.10 \
  -D "CN=pf-bind,OU=ServiceAccounts,DC=company,DC=local" \
  -w "BindPassword" \
  -b "DC=company,DC=local" \
  "(sAMAccountName=testuser)"

I created a dedicated service account in AD with read-only permissions — never use a domain admin account for this.

Defining Security Policies per Device Group

This is where PacketFence shines compared to plain VLANs: you define policies for each device type and each user group.

Connection Profiles

Open Configuration → Policies and Access Control → Connection Profiles. I created 3 profiles suited to our office environment:

Corporate-Wired: Company laptops, 802.1X authentication via AD → production VLAN
BYOD-WiFi: Employee personal devices, registration via captive portal → BYOD VLAN (internet only)
Guest-WiFi: Visitors, simple captive portal → guest VLAN (internet only, limited to 10 Mbps download)

Handling Devices That Don’t Support 802.1X

Printers, IP cameras, smart TVs — these devices can’t authenticate via 802.1X. The workaround: whitelist them by MAC address or place them on a dedicated VLAN.

I created a dedicated “IoT” VLAN with a matching Connection Profile, applied to the switch ports connected to IoT devices. Simple but effective.

Testing and Monitoring

Viewing Connected Devices

I keep the Nodes tab bookmarked in the Admin UI — it’s the first thing I open every morning to see all registered devices, who’s online, and who’s been quarantined.

# Query the database directly for reporting
mysql -u pf -p pf -e "
SELECT mac, computername, status, last_seen, role
FROM node
WHERE status = 'reg'
ORDER BY last_seen DESC
LIMIT 20;"

Monitoring the RADIUS Authentication Log

# View authentication log in real-time
tail -f /usr/local/pf/logs/radius.log

# Filter by specific MAC address
grep "aa:bb:cc:dd:ee:ff" /usr/local/pf/logs/radius.log | tail -50

# View recent authentication failures
grep "Access-Reject" /usr/local/pf/logs/radius.log | tail -20

Debugging VLAN Assignment

When someone reports “I plugged in but can’t access the network,” here’s the debugging process I typically follow:

# Test RADIUS directly
radtest testuser TestPassword 127.0.0.1 1812 testing123

# Run a full system health check
pfcmd checkup

# Check the node's current status and VLAN assignment
pfcmd node view aa:bb:cc:dd:ee:ff

# Restart RADIUS if needed
systemctl restart packetfence-radiusd-auth

Setting Up Alerts for Unknown Devices

Alerts are an often-overlooked feature but genuinely valuable. I configured email notifications under Configuration → Integration → Alerts for any new device registrations outside business hours — and sure enough, it caught employees plugging in personal devices at 9–10 PM on a few occasions.

# Manually trigger a test email alert
pfcmd emailreport type=node action=new

Lessons Learned After 6 Months in Production

Roll out gradually, don’t enable enforcement right away: Start with detection-only mode — let PacketFence log devices without blocking anyone. After 1–2 weeks, you’ll have a complete list of legitimate devices to whitelist before enabling enforcement. Skip this step and you’ll be drowning in support tickets on day one.

MAC spoofing is a real weakness to be aware of: MAC-based NAC is not bulletproof — an attacker can clone the MAC address of a legitimate device. Certificate-based 802.1X authentication (EAP-TLS) is far more reliable, but significantly more complex to deploy (requires an internal PKI). For my use case, MAC detection for IoT devices combined with 802.1X for laptops is enough to sleep soundly at the current scale.

Document everything: Every time I add a new device to the whitelist, I note what it is, who owns it, and why it was whitelisted. Looking back six months later, that list is more accurate than any inventory spreadsheet I’ve ever maintained manually.

PacketFence isn’t a quick setup — initial configuration takes 1–2 full workdays. But after that, you have clear visibility into every device connected to your network, and that’s something no ordinary switch or firewall can give you.