Network Access Control with 802.1X

Network Access Control with 802.1X is a standardized method for authenticating devices before granting them access to a network. It is essential in environments where wired or wireless endpoints—ranging from laptops and smartphones to IoT sensors and printers—must be verified before connecting to internal services. 802.1X is used when security, device identity, and dynamic policy enforcement are required, such as in enterprise campuses, cloud data centers, and guest-facing Wi-Fi networks.

Authenticating Devices at the Edge

To enforce access control using 802.1X, a network device (the *supplicant*) connects to a network switch or access point (the *authenticator*) and sends an authentication request to a central *authenticator server*, typically RADIUS-based. The process begins when the supplicant sends an EAP-Request/Identity message to the authenticator, which forwards it to the RADIUS server via the RADIUS protocol.

The RADIUS server responds with an EAP-Response/Identity, prompting the supplicant to send its credentials. The most common format is EAP-MD5, but EAP-TLS and EAP-PEAP are preferred for stronger security and mutual authentication.

EAP-TLS: Mutual Authentication with Certificates

EAP-TLS provides mutual authentication using X.509 certificates. The supplicant presents its client certificate to the RADIUS server, which validates the certificate chain and checks the identity.

The RADIUS server returns an EAP-Success message when authentication succeeds, and the authenticator enables the port for the supplicant. If authentication fails, the server sends EAP-Failure with a reason code (e.g., Invalid-Certificate, Certificate-Expired).

A typical RADIUS server configuration (e.g., FreeRADIUS) includes:

authorize {
    eap {
        default_eap_type = tls
        tls {
            private_key_file = /etc/ssl/private/radius.key
            certificate_file = /etc/ssl/certs/radius.crt
            ca_file = /etc/ssl/certs/ca.crt
            verify_server = yes
            verify_depth = 2
        }
    }
}

The supplicant must trust the RADIUS server’s CA certificate. On Linux, this is configured in /etc/wpa_supplicant/wpa_supplicant.conf:

network={
    ssid="Corporate-WiFi"
    key_mgmt=IEEE8021X
    eap=TLS
    identity="[email protected]"
    ca_cert="/etc/ssl/certs/ca.crt"
    client_cert="/etc/ssl/certs/client.crt"
    private_key="/etc/ssl/private/client.key"
    private_key_passwd="secret"
    phase1="peapver=1"
    phase2="auth=MSCHAPV2"
}

The phase1 and phase2 fields control the EAP tunnel and inner authentication. peapver=1 enables PEAP v1, and auth=MSCHAPV2 configures MS-CHAPv2 within the tunnel.

Dynamic VLAN Assignment and Policy Enforcement

Once authenticated, the RADIUS server can assign the supplicant to a VLAN using the VLAN-ID attribute. This attribute is part of the Access-Accept message and is sent to the authenticator.

In FreeRADIUS, VLAN assignment is configured via the radreply table in the database:

INSERT INTO radreply (username, attribute, op, value)
VALUES ('[email protected]', 'VLAN-ID', ':=', '201');

The authenticator (e.g., a Cisco switch or Aruba AP) receives this and configures the port to assign incoming traffic to VLAN 201. The VLAN is applied immediately upon authentication, so users can access department-specific resources without manual configuration.

For more granular control, the RADIUS server can return multiple attributes:

INSERT INTO radreply (username, attribute, op, value)
VALUES
    ('[email protected]', 'VLAN-ID', ':=', '201'),
    ('[email protected]', 'Filter-ID', ':=', 'Finance-Access'),
    ('[email protected]', 'Tunnel-Type', ':=', 'VLAN'),
    ('[email protected]', 'Tunnel-Medium-Type', ':=', '802'),
    ('[email protected]', 'Tunnel-Private-Group-ID', ':=', '201'),
    ('[email protected]', 'MS-RAS-Call-Id', ':=', '20210801-1423');

The Filter-ID attribute can be used to apply ACLs or QoS policies. The Tunnel-Type and Tunnel-Medium-Type fields enable VLAN tagging, and Tunnel-Private-Group-ID sets the VLAN ID for the tunnel.

Reauthentication and Session Management

802.1X supports reauthentication, where the supplicant periodically re-authenticates to maintain access. This is triggered by the RADIUS server sending an EAP-Request/ReAuth message to the authenticator.

The authenticator forwards the request to the supplicant, which responds with an EAP-Response/ReAuth. The RADIUS server checks if the session is still valid and may re-assign VLANs, update policies, or renew access.

Reauthentication intervals are controlled by the ReAuth-Period attribute. In FreeRADIUS, this is configured in sites-enabled/default:

authorize {
    eap {
        reauth_period = 3600  # 1 hour
        reauth_delay = 15     # 15 seconds
    }
}

If the supplicant fails reauthentication, the authenticator can move it to a fallback VLAN (e.g., Guest-VLAN) and log the event.

Silent Failures and Common Pitfalls

Certificate Validation

The most common silent failure is certificate validation. A supplicant may authenticate using a certificate, but if the RADIUS server’s CA is not trusted, the connection succeeds but the certificate is not validated. This leads to unverified identity and potential man-in-the-middle attacks.

To verify certificate validation, the RADIUS server must be configured with verify_server = yes and verify_depth = 2. The client must also validate the server’s certificate chain.

Additionally, the subjectAltName field in the server certificate must match the RADIUS server’s hostname. A mismatch in this field causes Certificate-Subject-Mismatch errors.

VLAN Assignment Timing

VLAN assignment is not immediate. The authenticator applies the VLAN after receiving the Access-Accept message, but if the RADIUS server sends the message before the port is fully initialized, the VLAN may be assigned too late.

A common issue is that the supplicant sends an initial DHCP request before the port is open. The RADIUS server may assign a VLAN, but the DHCP request arrives before the VLAN is active, so the device receives an IP address in the wrong VLAN.

To mitigate this, the authenticator should use pre-authentication VLAN (also known as *Guest VLAN*). The port is assigned a VLAN (e.g., VLAN 100) before authentication, allowing the supplicant to perform DHCP and DNS resolution during the authentication process.

EAP-Response/Identity Timing

An EAP-Response/Identity message sent too early—before the RADIUS server has processed the EAP-Request/Identity—can cause the RADIUS server to fail to recognize the supplicant’s identity. This happens when the supplicant sends the identity in the same EAP packet as the initial request.

The correct sequence is:

1. Supplicant sends EAP-Request/Identity.
2. Authenticator forwards it to RADIUS server.
3. RADIUS server responds with EAP-Response/Identity.
4. Supplicant sends EAP-Response/Identity with its identity.

If the supplicant sends EAP-Response/Identity in the same frame as EAP-Request/Identity, the RADIUS server receives a packet with two EAP messages, but only the first is processed. The response is sent, but the identity is not recognized.

To fix this, the RADIUS server must use eap module with parse_request = yes and send_response = yes.

Interoperability and Troubleshooting

Capturing EAP Frames with tcpdump

To debug 802.1X issues, use tcpdump to capture EAP frames:

sudo tcpdump -i eth0 -s 0 -X -n -tttt -f 'eap or udp port 1812'

This captures EAP frames and RADIUS traffic. The -X flag displays both hex and ASCII output, and -tttt adds timestamps.

A typical trace shows:

12:34:56.789012 EAPOL: version=1, type=1, length=74
    EAP: code=1, id=1, length=68, type=1
        Identity: "[email protected]"
12:34:56.789013 RADIUS: code=1, id=1, length=210
    Attribute: 1 (User-Name), value="[email protected]"
    Attribute: 16 (VLAN-ID), value="201"
12:34:56.789020 EAPOL: version=1, type=2, length=62
    EAP: code=2, id=1, length=56, type=2
        Success

RADIUS Debugging with radtest

To test RADIUS authentication, use radtest from FreeRADIUS:

radtest [email protected] secret 192.168.1.100 0 radius-server 1812

This sends an Access-Request with the username [email protected] and password secret to radius-server on port 1812. The output includes the RADIUS response, including VLAN-ID and Filter-ID attributes.

Common Error Codes

• Invalid-Certificate: The client’s certificate is invalid, expired, or not trusted.
• Certificate-Expired: The certificate validity period has passed.
• Certificate-Subject-Mismatch: The subject name in the certificate does not match the expected identity.
• Invalid-Password: The user password is incorrect.
• Access-Denied: The user is not authorized to connect.
• Session-Terminated: The session was stopped by the server.

Extending 802.1X with Dynamic Policies

802.1X is not limited to authentication and VLAN assignment. It can be extended to enforce network policies dynamically.

For example, the RADIUS server can return MS-RAS-Call-Id to identify the session, NAS-IP-Address for the authenticator’s IP, and Called-Station-ID for the port or SSID.

These attributes can be used to:

• Populate a session database.
• Trigger audit logs.
• Configure QoS policies based on user role or device type.

A common pattern is to use Filter-ID to apply ACLs. The RADIUS server returns a Filter-ID value that maps to a named policy in the authenticator (e.g., a Cisco switch or a Juniper MX router).

The authenticator applies the policy using the Filter-ID as a reference, enabling traffic shaping, port security, or access lists.

Summary

802.1X is a robust, standards-based network access control mechanism that authenticates devices and enforces policies at the network edge. It is used when secure, dynamic, and policy-driven access is required. The core flow involves EAP exchange between supplicant and RADIUS server, with VLAN assignment and policy enforcement via RADIUS attributes. Key success factors include correct certificate validation, proper timing of VLAN assignment, and consistent handling of reauthentication. Common failures—such as unverified certificates, delayed VLANs, and mismatched identity—can be diagnosed using tcpdump, radtest, and RADIUS server logs. The protocol is extensible and well-suited for enterprise, campus, and cloud environments.

This page was rewritten on 18 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.