PacketFence is a NAC platform to control user and device access to wired and Wi-Fi networks. It combines authentication, access policies, guest access and infrastructure integration. Add Solution supports assessment, architecture, piloting and secure deployment.
Add Solution starts with the real environment: identities, endpoints, models and firmware, VLANs, RADIUS, guest portal, contingency and operations.
Associate access with the device or user identity. In a managed fleet, the assessment should consider certificate-based authentication, centralized network profile distribution and access revocation when a user leaves or a device is lost.
Provide an entry path with a defined duration, owner and permissions. For a contractor who needs an internal system, the question is which destinations will be allowed, for how long and who approves the exception.
Organize personal device use without mixing that access with corporate equipment access. The design needs to consider operating systems, privacy, user support and what happens when the device is no longer used.
Reduce permanent, indiscriminate access grants. Equipment without strong authentication needs registration, an owner, access restricted to necessary services and review criteria. In sensitive environments, the risk of disruption requires a joint assessment with operations.
Define a common policy while preserving differences in how each device applies it. Deployment can start with one network, SSID or group of ports, with expansion contingent on pilot results.
The project should turn security rules into manageable access: consistent permissions, organized onboarding and offboarding, objective diagnostics, gradual deployment and documented continuity. Inventory, risks and operational capacity define the scope and acceptance criteria.
In 802.1X, the endpoint presents its identity, and the network device carries authentication over RADIUS and applies the authorization received. The result must be confirmed on the device, in addressing and in permitted traffic.
The endpoint presents the expected user, device or certificate identity.
In the 802.1X flow, the authenticator carries the EAP conversation over RADIUS and receives the authentication and authorization decision.
Context, group, device and location determine the expected outcome for that connection.
The NAS applies a VLAN, role, ACL or another documented, supported native mechanism.
Device state, addressing and permitted traffic confirm effective access.
It is a priority option to assess for managed devices. Authentication uses certificates, reducing reliance on passwords entered for network access. It requires a well-operated PKI and correctly distributed profiles. TLS negotiation must also be compatible between clients and the server. EAP-TLS with TLS 1.3.
They can meet compatibility requirements, but must be selected with the directory and operating systems in use in mind. On Windows, Credential Guard can affect the use of session credentials in MS-CHAPv2-based methods. The review should seek a method appropriate to the fleet while preserving endpoint protections. EAP on Windows.
It can enable access for equipment without a supplicant. The MAC address acts as an identifier and can be spoofed; it does not provide the same identity assurance as a certificate. We therefore recommend bounded exceptions, inventory and restrictive segmentation. Priority and fallback behavior between 802.1X and MAC must be validated on the model in use. MAB limitations and design.
PacketFence offers options such as self-registration, sponsor approval and email or SMS confirmation. The choice depends on the desired experience and available services. Guest and BYOD. Portal-based entry should be assessed together with network isolation, access duration and the authentication used on the Wi-Fi link. The form alone does not define these controls.
EAP-TLS requires certificate lifecycle management: issuance, distribution, validity, renewal and revocation. Validation testing must confirm identity, the chain of trust, certificate purpose and behavior on expiration or PKI unavailability.
With out-of-band control, the endpoint communicates with permitted services through the network device, or NAS, and the production infrastructure. On a separate branch, the NAS exchanges RADIUS authentication and authorization messages with PacketFence. PacketFence uses identity and trust, such as a directory and certificates, according to the method. The NAS applies the authorization. Production traffic does not pass through PacketFence. Conceptual diagram without data from a real deployment.
In the out-of-band model, PacketFence decides authorization and the network device applies it. Production traffic remains on the infrastructure. The design must validate RADIUS, VLANs, ACLs, accounting, authorization changes and contingency on each device.
In inline mode, PacketFence sits in the traffic path of the controlled network. It can serve equipment without suitable enforcement mechanisms, but introduces additional capacity and continuity requirements. Inline architecture. The assessment must include actual throughput, traffic peaks, interfaces, latency and maintenance impact. The choice must be deliberate, especially when the same environment depends on that path to access essential systems.
You can use RADIUS only, without the registration, isolation and portal flows of that deployment mode, or combine mechanisms according to the segment served. Supported modes. In distributed projects, it is advisable to decide where authentication, the portal and identity dependencies will reside. Site-to-site connectivity, failure behavior and contingency access must be defined before expansion.
User, device, certificate or a combination according to policy.
Authentication and authorization carried to the network device.
The switch, access point or controller applies a supported VLAN, role or ACL.
DHCP, DNS, routing and segmentation complete effective access.
Accounting, session state and traffic testing demonstrate the outcome.
Compatibility must be validated by model, firmware and mechanism. The assessment records authentication, authorization attributes, VLAN or ACL, accounting, CoA and behavior during reauthentication and failure.
Huawei compatibility varies by model, firmware and mechanism. The assessment confirms the 802.1X, MAB, RADIUS, dynamic VLAN or ACL, accounting and CoA required for the use case. Validation testing must use the environment's actual equipment and version.
In multivendor environments, the policy can be common, but enforcement varies by vendor. The project documents each integration's attributes, limits and behavior, preserving native capabilities and sustainable operations.
The guest journey must define registration, ownership, approval, duration and permitted resources. The portal must work on the intended devices, preserve accessibility and guide the user even before full internet access is available.
Authorization must be demonstrated on the device and in traffic. Accounting identifies the session; CoA, Disconnect or an equivalent mechanism must change or terminate the correct access. The pilot validates expiration, renewal, roaming and communication failures.
The guest enters through the network and portal experience intended for the actual device.
Self-registration, reception or a sponsor follow defined minimum-data, duration and accountability requirements.
The policy grants internet-only access or access to specifically approved resources.
Accounting and available identifiers correlate the user, device and NAS.
CoA, Disconnect or the agreed native mechanism changes or terminates the correct session.
PacketFence can combine device profiling with signals from security tools. Each signal must have a known origin, validity and trust level; automated actions need scope, remediation and reversal to avoid improper blocking.
High availability must be validated by service. The project measures new authentications, the portal, existing sessions, the database and dependencies under failure conditions. Capacity and retention are sized using observed data, headroom and representative tests.
Upgrades should follow supported versions, official notes, backups, testing and a planned rollback. Integrations should use documented mechanisms to avoid dependence on local changes that hinder support and evolution.
The documented architecture starts with at least three nodes and an odd number of servers.
Galera, HAProxy and Keepalived distribute functions according to the design and connectivity between sites.
When the cluster loses quorum, the database enters read-only mode; the portal and RADIUS authentications may be affected differently depending on the data and sources still accessible.
The portal, new authentications and existing sessions are checked separately.
Backup, restoration, upgrades and cross-vendor regression testing each have their own procedures and evidence.
Total cost includes infrastructure, deployment, operations, support, upgrades and growth. The self-hosted edition is distributed under GPL v2 or later; vendor support and Add Solution services have their own scopes, which must be explicit in the proposal.
The comparison should start with the environment's requirements. PacketFence favors infrastructure control and open flexibility; Cisco ISE, ClearPass and FortiNAC may be appropriate when their ecosystem integrations are decisive; NPS serves more limited RADIUS scenarios. Licensing, compatibility, operations and migration must be compared within the same scope.
The scope must document compatibility by model and firmware, native integrations, acceptance criteria, responsibilities and continuity targets. Limitations found in the pilot must be addressed before expansion.
The scope may include the following workstreams, according to the environment's needs:
Inventory of control points, identity sources, endpoint types and dependencies. Definition of policies, exceptions, deployment method and continuity criteria.
Validation on a representative set of equipment and clients. Testing of admission, denial, segmentation, expiration, revocation and failure. Recording of results and limitations before expansion.
Sequencing by site, SSID or group of ports, with communication to support and a rollback procedure. Each stage must have defined progression criteria and owners.
The deliverables document policies, integrations, certificates, tests, exceptions, and support and recovery procedures. Responsibilities and the service model are defined in the proposal.
The answer depends on the models, firmware and intended controls. The assessment must distinguish equipment that meets the design, equipment that requires restrictions and equipment that needs replacing. Compatibility must be checked by function against the official matrix.
Yes, that can be the project's initial scope. Even at this stage, it is important to validate isolation, the portal, duration, traceability and access termination. Expansion to corporate 802.1X is a subsequent architecture decision.
It should be treated as identification with limitations. The recommended design combines controlled registration, least privilege and exception tracking. Equipment capable of stronger authentication should be assessed for its use.
No. The project coordinates these controls. Admission and segmentation policies must coexist with traffic inspection, endpoint protection and incident response. Each layer must have its own function, owner and evidence.
Acceptance testing must include tests between guests, internal networks and infrastructure services. The outcome depends on the rules and communication paths actually configured, including IPv6 where present.
The project must separate certificate validation from access permission. Identity, association with the device or user, authorization validity and any restrictions must inform the decision.
Network authentication mechanisms can use the system supplicant or MAC-based identification. Posture checks and provisioning have their own dependencies, which must be confirmed for each integration and operating system.
This must be demonstrated for the chosen architecture. Existing sessions, new authentications and the portal may behave differently. The pilot must include node and dependency failures, with an explicit contingency policy.
Yes, the portal provides documented customization mechanisms. The project must preserve accessibility, clear states, mobile compatibility and the platform's upgrade path.
The project can contribute access controls and records. The organization must validate the purpose, data collected, retention and responsibilities with its privacy team. A portal or tool alone does not demonstrate compliance. ANPD guidance on information security.
It depends on fleet compatibility, identity and PKI maturity, the number of flows, redundancy needs and operational scope. The initial assessment should turn these variables into stages, acceptance criteria and a proposal.
Share device classes, networks, equipment, authentication methods, guest requirements and continuity requirements. Do not send credentials, RADIUS secrets or sensitive operational data.