Zero Trust for the Home Lab - Radius and 802.1x (Part 3)

The Road to the World's Most Secure Home Lab....

So far in the pursuit of the World's most secure home lab, the following have been implemented:

Part 1 - Zero Trust Introduction

Part 2 - VLAN Tagging and Firewalls with pfSense

What's Covered in this Blog

This post explains how to implement EAP-TLS 802.1X authentication using FreeRADIUS alongside a Windows Enterprise CA for domain joined clients.

What Is 802.1X and What Authentication Types Can Be Used?

IEEE 802.1X is a network access control standard that enforces authentication before allowing devices to connect to a wired or wireless network, preventing unauthorized access to network resources.

• 802.1X works by involving three components:

  • Supplicant: The device trying to connect (e.g., a laptop)

  • Authenticator: The network device (e.g., switch or wireless access point)

  • Authentication Server: Typically a RADIUS server that verifies credentials (pfSense)

What Is Zero Trust - Recap

Zero Trust is a security framework that assumes no user, device, or network segment is inherently trustworthy, regardless of where it sits in the network. The core principles include:

• Verify explicitly – Always authenticate and authorize access.

• Use least privilege access – Limit access to only what's needed.

• Assume breach – Design as if attackers are already in the network.

How 802.1x Addresses Zero Trust Security

Device and User Authentication at the Network Edge:

• 802.1x enforces authentication before a device can even communicate on the network. By validating the identity of both users and devices before granting access, it ensures that only trusted entities can join the network.

Dynamic Access Based on Identity:

• After successful authentication, network access can be dynamically assigned based on user roles or device attributes, such as through VLAN tagging or access control lists. This supports Zero Trust’s principle of least-privilege access and helps isolate systems by trust level.

Continuous Monitoring and Enforcement:

• When integrated with a Network Access Control (NAC) system, 802.1X allows ongoing assessment of device posture and compliance, with the ability to quarantine or restrict access if the device falls out of policy.

  • Microsoft’s native NAC solution, Network Access Protection (NAP), has been deprecated and is no longer available.

  • pfSense does not support full NAC functionality,

  • Third-party solutions such as PacketFence, Aruba ClearPass, or Cisco ISE are required to fulfill this role.

Segmentation and Isolation:

• 802.1x pairs well with network segmentation strategies. Devices that fail authentication or are unknown can be automatically placed into restricted VLANs, such as guest or quarantine zones. This limits exposure and aligns with Zero Trust’s goal of minimizing lateral movement.

Authentication Options

MAC Address Authentication

• For devices that can't run 802.1X (like printers or IP phones), the switch can authenticate based on the device's MAC address. This is the least secure and is typically used as a fallback method.

PEAP with Active Directory (Username/Password-Based Authentication)

• PEAP (Protected Extensible Authentication Protocol) creates a secure TLS tunnel to protect the authentication exchange. Inside that tunnel, it commonly uses MSCHAPv2, which authenticates users via their Active Directory username and password.

• While this provides a basic layer of security, MSCHAPv2 has known vulnerabilities. If an attacker manages to capture the encrypted challenge, they can potentially crack it using brute-force or dictionary attacks.

• The effectiveness of this method ultimately depends on strong password hygiene and the security of your Active Directory environment, which can be a weak link in many setups.

EAP-TLS with Certificates (Certificate-Based Mutual Authentication)

• EAP-TLS, on the other hand, uses digital certificates for both the client and the server to perform mutual authentication. Both sides must present valid certificates, creating a highly secure, trust-based environment.

• Since no passwords are exchanged, this method is immune to common credential-based attacks like brute-force, phishing, or credential stuffing.

• It also offers strong cryptographic protections, making it highly resistant to replay and man-in-the-middle (MiTM) attacks.

  
  

Why I'm Choosing EAP-TLS

Given the significantly stronger security model and elimination of password-based vulnerabilities, the obvious choice for my environment is EAP-TLS. It provides robust, certificate-based authentication.

802.1X and RADIUS Configuration

Okay, let's set up 802.1X authentication on the pfSense using FreeRADIUS and an Enterprise Certificate Authority (CA). This is a long one, better grab that coffee now...

Configure the Microsoft Enterprise CA

On the CA server, open the Certification Authority console (certsrv.msc).

Create a RADIUS Server Certificate Template: 

• Right-click Certificate Templates and select Manage.

• Right-click the RAS and IAS Server template (or Workstation Authentication as a base) and select Duplicate Template.  

Compatibility Tab: 

• Set compatibility levels to Windows Server 2016

General Tab: 

• Template display name: pfSense RADIUS Server.

• Validity period: 2 years

• Do not check 'Publish certificate in Active Directory.'

Request Handling Tab: 

• Purpose: Signature and encryption.

  • Do not allow the private key to be exported, ensure it is unchecked.

Cryptography Tab: 

• Provider Category: Key Storage Provider

• Algorithm Name: ECDH_P384

• Minimum key size: 384

• Request hash: SHA384

Subject Name Tab: 

• Select Supply in the request.

  • pfSense will generate the necessary information based on your inputs.

• Click OK on the warning popup.

Extensions Tab: 

• Select Application Policies and click Edit....

• Remove Client Authentication, if present.

• Make sure the Server Authentication is present > Click OK.

  

• Select Key Usage and click Edit....

• Ensure the Digital signature is checked.

• Allow key exchange only with key encipherment (key encipherment) is checked.

• Ensure 'Make' this extension critical is unchecked.

Security Tab: 

• Ensure Authenticated Users have Read permission.

• Create an AD Group and assign 'FULL Control'.

  • Group name is 'RG_CA_pfSense_Radius_Req'

• Add the account that will be used to create and enroll the Radius certificates

• Click Apply and OK.

Publish the New Template: 

In the Certification Authority console

• Right click Certificate Templates, select New, then Certificate Template to Issue.  

• Select your newly created pfSense RADIUS Server Template. 

Configure pfSense & Generate CSR

Install FreeRADIUS Package:

Log in to your pfSense web interface.

• Navigate to System > Package Manager > Available Packages.

• Search for 'radius'.

• Click Install and confirm.

• The installation will take a while.

Import the CA Certificate:

From the CA, export the Root CA certificate:

• Right-click your CA name > Properties.

• On the General tab, click View Certificate.

• Go to the Details tab, click Copy to File....

• Export Next > Select Base-64 encoded X.509

• Next > Choose a filename > pfSenseRootCA.cer

On pfSense:

• Navigate to System > Certificates > Authorities

• Click Add.

• Descriptive name: Enter something meaningful

• Method:

  • Import an existing Certificate Authority.

• Certificate data:

  • Paste the entire content of pfSenseRootCA.cer

• Click Save.

Generate Certificate Signing Request (CSR) on pfSense: 

• Navigate to System > Certificates > Certificates.

• Click Add/Sign.

Add/Sign a New Certificate:

• Method: Create a Certificate Signing Request.

• Descriptive name: Toyo pfSense Radius Server.

External Signing Request

• Key type: ECDSA

• Key length: secp384r1 [HTTPS] - match the template

• Digest Algorithm: sha384 - match the template

• Common Name (CN):  radius.toyo.loc

  • Crucial! This MUST be the Fully Qualified Domain Name (FQDN) or IP address of the RADIUS server.

• From DNS console on the DC:

  • Create an 'A Record' to the LAN interface - pfsense.toyo.loc @ 192.168.0.1

  • Create an ALIAS (CNAME) named 'radius' that resolves to pfsense.toyo.loc

• Country Code: GB

• State or Province: Hook

• City or Locality: Hants

• Organization: Tenaka.net

• Organizational Unit: IT Department. Home Lab

Certificate Attributes: 

• Certificate Type: Server Certificate

• Alternative Names: The IP of the pfSense LAN address 192.168.0.1

• Add SAN Row

  • FQDN or Hostname: radius.toyo.loc

• Add SAN Row

  • FQDN or Hostname: radius

  • IP Address: 192.168.0.1

  • FQDN or Hostname: pfsense FQDN or Hostname: pfsense.toyo.loc

Export the CSR

Export the newly created CSR by clicking on the arrow with the door icon.

Issue the Certificate using the CSR

Ensure your account has admin rights and is a member of the 'RG_CA_pfSense_Radius_Req' Group open CMD or PowerShell.

• Run command:

certreq -submit -attrib "CertificateTemplate:pfSenseRADIUSServer" "C:\cert\pfSense+CSR.req"

• pfSense+CSR.req is the csr previously downloaded

• CertificiateTemplate:pfSenseRADIUSServer is the Template Name and not the Display Name

• A dialog will pop up asking you to select the CA; choose your issuing CA and click OK.

• Another dialog will ask where to save the issued certificate (.cer).

• Choose a location and filename of 'pfSense Radius Cert.cer'

• Click Save.

Import Issued Certificate into pfSense

• Navigate to System > Cert. Manager > Certificates

• Find the CSR entry you created earlier (Toyo pfSense RADIUS Server CSR).

• Click the Edit icon (pencil).

• Open the issued certificate file 'Toyo pfSense RADIUS Server.cer' with Notepad.

• Copy the entire content (including BEGIN/END lines).

• Paste this content into the Final Certificate data field.

• Add a description

• Click Update.

• The entry should now change from a CSR to a valid certificate, showing its issuer and validity dates.

Certificate Revocation List (CRL)

You have 7 days...

Crucial!  When certificate revocation checking is enabled, a valid CRL must be configured to verify whether certificates have been revoked. If revocation checking is enabled but the CRL is unavailable, clients will be unable to confirm their certificate status and authentication will fail.

Crucial!  In EAP-TLS, both the client and pfSense validate certificates. A critical part of this validation is checking whether a certificate has been revoked, which it does using the CRL.

If the CRL has expired or is not available, pfSense will consequently fail authentication for the client. The default expiry is 7 days.

With the current pfSense configuration, CRL updates are handled manually, and the CRL expires every 7 days. This is sub-optimal if the CRL isn’t updated on time, client authentication will fail across the board, locking users out of the Wi-Fi. Automating this is on the backlog... honest.

The CRL validity is being extended to 6 months, which isn’t ideal. The key caveat is that any time a certificate is revoked, the CRL on pfSense must also be updated to reflect the change.

CRL Publishing Parameters:

• On the CA, right click Revoked Certificates > Properties.

• Update the CRL publication interval to 6 Months.

• Update Publish Delta CRLs to weekly.

Publish the CRL with the new expiry date.

• Right click Revoked Certificates > All Tasks > Publish

CRL Export\Import

The CRL will require exporting to a Base64 file and then pasting into pfSense.

• Copy the latest crl from C:\Windows\System32\CertSrv\CertEnroll\ to C:\Certs and then convert it to Base64.

certutil -encode "c:\certs\TOYO-TOYO01-CA(3)+.crl" c:\certs\crl_base64.txt

• Navigate to System > Cert. Manager > Certificates > Revocation

• On the drop-down, select CA (Toyo CA) and Add

• Select 'Import an existing Certificate Revocation List'

• Add a Descriptive name

• Copy and paste the crl_base64.txt content.

• Save

• There should now be a CRL entry.

Configure FreeRADIUS on pfSense

Navigate to Services > FreeRADIUS.

Interfaces Tab: 

• Click Add.

  • Interface IP Address: Select the pfSense LAN IP address 192.168.0.1

  • Port: 1812 (standard RADIUS Authentication port).

  • Interface Type: Authentication.

  • IP Version: IPv4.

  • Description: LAN Radius Authentication

• Click Save.

• Click Add again.

  • Interface IP Address: Select the same pfSense IP address.

  • Port: 1813 (standard RADIUS Accounting port).

  • Interface Type: Accounting.

  • IP Version: IPv4.

  • Description: LAN Radius Accounting

Click Save.

NAS / Clients Tab: 

This is where you define your switches or wireless access points that will forward authentication requests to pfSense.

• Click Add.

  • Client IP Address: Zyxel Wifi AP is @ 192.168.0.253

  • Client IP Version: IPv4.

  • Client Shared Secret: Some ridiculously long password

    • You must configure the same secret on your switch/AP. (Zyxel Wifi AP)

    • Ensure the secret conforms to best practice

  • Client Shortname: Enter the hostname of the AP

• Add other switches, routers, and AP devices as needed.

Click Save.

EAP Tab: 

The EAP tab configures authentication methods like EAP-TLS or PEAP used for secure 802.1X network access.

EAP:

• Check the Disable weak EAP types: MD5, and GTC

• Default EAP Type: TLS.

• Disable Weak EAP Types: Checked.

• Minimum TLS version: 1.2

Certificates for TLS:

• On each of the drop-downs, select the relevant CA settings

  • Note: If the SSL Revocation List option is set and misconfigured, clients will fail to validate their certificates and won't be able to connect to the 802.1x SSID.

  • It's possible to select None for testing purposes, but this is not a suitable option for production.

EAP-TLS:

• Include Length: Yes

• Fragment Size: 1024

• Check Cert Issuer: Enable

• CA Subject: Blank

• Check Client Certificate:

EAP-TLS Cache: 

• Leave the defaults

PEAP and TTLS:

• Leave other EAP types like PEAP, TTLS settings at their default values.

• Click Save.

Settings Tab: 

Select the Settings Tab.

General Configuration:

• Leave the General Configuration settings at their default values.

Logging Configuration:

• This is a personal preference, the Radius Logging Destination is updated to output to the radius.log

• All other settings remain default.

• Click Save.

Configure Switch/AP (Zyxel Wifi)

The original Zyxel NWA50AX is another casualty of implementing Zero Trust, it turns out it doesn’t support 802.1X or WPA2 Enterprise. So, after discovering that fun fact the hard way, I swapped it for an NWA130BE. £160 later, we finally have proper 802.1X support.

SSID Profile Wizard:

A new SSID was created, subtly named, of course, and initially configured with VLAN ID 1. While this configuration allowed clients to connect, it failed to automatically switch them to VLAN 40 and the Client interface. However, since automatic VLAN switching wasn’t functioning as expected, the VLAN ID was explicitly set to 40 within the SSID configuration. I guess I was asking too much for £160.

Security Profile Wizard:

• Select WPA2 and Enterprise

• Primary Radius Server Activated: Enable

• Radius Server IP Address: 192.168.0.1

• Radius Server Port: 1812 (authentication port, to match the port assigned on the pfSense)

• It's time to pull out that shared secret set in the NAS/Clients section of the pfSense earlier.

• Save

Configure Windows Clients

The pfSense firewall will require a tweak to allow Clients on VLAN 40 to access the Switch/AP

• Navigate to the Firewall > Rules > VLAN40_Clients.

• Add an 'allow' rule between the Zyxel Wifi alias on 192.168.0.253 and the alias for clients.

Basic CA and GPO Configuration: 

• Ensure every Windows Domain client trusts the Windows Root CA, and deploy it using GPO if necessary.

• Enable auto-enrollment of certificates in Group Policy, certificate templates with the Autoenroll permission will do just that, and enroll automatically.

Deploy Workstation Authentication Client Certificate - TPM Supported:

It would almost feel wrong not to deploy more certificates. This time, the clients are getting the full treatment.

Not all of my Windows clients and servers are blessed with a TPM, case in point, the Intel Skull Canyon and the Gen 6 Hyper-V host, they still cling to life with retirement being long overdue. Without the TPM there's no support for the Microsoft Platform Crypto Provider.

The fallback option when a TPM isn't available is to use the Microsoft Software Key Storage Provider, which is managed through Active Directory groups that control certificate enrollment.

Create the following AD Groups:

For Computer objects that do not support TPM

• RG_CA_WksAuthCert_Deny_TPM_Supt

For Computer objects that do support TPM

• RG_CA_WksAuthCert_Allow_TPM_Supt

Workstation Authentication Template:

• Right-click Certificate Templates and select Manage.

• Right-click the Workstation Authentication template and select Duplicate Template.  

• Will assume that the Workstation Authentication or Computer templates are NOT deployed.

General Tab:

• Template display name: Toyo Workstation Authentication

• Validity period: 1 years

• Renewal period: 6 weeks

• Check 'Publish certificate in Active Directory.'

Compatibility Tab: 

• Set compatibility levels to Windows Server 2016

Cryptography Tab: 

• Provider Category: Key Storage Provider

• Algorithm Name: RSA

  • RSA is supported for key generation and storage in the TPM.

  • ECC (Elliptic Curve Cryptography) isn't generally supported for TPM storage of certificates.

• Minimum key size: 2048

• Request hash: SHA256

• Requests must use one of the following providers:

  • Microsoft Platform Crypto Provider

    • Microsoft Platform Crypto Provider is the Key Storage Provider (KSP) that allows certificates and their private keys to be stored in the Trusted Platform Module (TPM).

    • If no TPM is accessible, the certificate will fail to enroll.

Subject Name Tab:

Under 'Build from this Active Directory Information'

• Subject name format: Common Name is selected

• Include this information in alt sub name: Check DNS  

Extensions Tab: 

• Select Application Policies and click Edit....

  Ensure that the Client Authentication is present.

Security Tab: 

• Ensure Domain Computers is removed

• Add RG_CA_WksAuthCert_Allow_TPM_Supt

  • Allow Read, Enroll, and AutoEnroll.

• Click Apply and OK.

Deploy Workstation Authentication Client Certificate - TPM is Not Supported:

Toyo Workstation Authentication Template:

• Right-click Certificate Templates and select Manage.

• Right-click the Toyo Workstation Authentication template and select Duplicate Template.

General Tab:

• Update the name to show TPM arent supported

Cryptography Tab: 

• Provider Category: Key Storage Provider

• Algorithm Name: RSA

• Minimum key size: 2048

• Request hash: SHA256

• Requests can use any provider available on the subject's computer.

Security Tab: 

• Ensure 'Domain Computers' is removed

• Add RG_CA_WksAuthCert_Deny_TPM_Supt

  • Allow Read, Enroll, and AutoEnroll.

• Click Apply and OK.

Publish the New Templates: 

In the Certification Authority console

• Right click Certificate Templates, select New, then Certificate Template to Issue.  

• Select your newly created Toyo Workstation Authentication Templates. 

• Restart the clients to automatically enroll the certificate or gpupdate /force

The Final Step (Honest) - Connect the Client to the Wifi

Confirm that the Toyo Workstation Authentication certificate has been enrolled on the clients:

• As an Administrator, run certlm.msc.

• Confirm the certificate is present.

After all that effort, the final step feels a bit anticlimactic, just select the 'Toyo-802.1X' Wi-Fi network and connect. No passwords required.

Review the connection settings:

GPO Settings

For the Home Lab environment, these GPO settings may be somewhat excessive given there are only four domain joined laptops. However, the GPO will enforce connection to the specified Wi-Fi access point and hide all other SSIDs from view

• Create a new GPO and link it to the Domain workstations OU.

• Edit Computer Configuration > Policies > Windows Settings > Security Settings > Wireless Network (IEEE 802.11) Policies.

• Right-click and Create A New Wireless Network Policy for Windows Vista and Later Releases.

General Tab:

• Update the Policy Name: 802.1x Toyo Wifi

• Add a description.

• Click Add.

• Select Infrastrucuture.

Connection Tab:

• Update the Profile Name: Toyo 802.1X

• Enter the Network Name(s)(SSID): Toyo-802.1X

• Ensure that only 'Connect automatically when this network is in range' is selected.

Security Tab:

• Authentication: WPA2-Enterprise

• Encryption: AES-CCMP

• Select a network authentication method: Microsoft Smartcard or other certificate

• Authentication Method: Computer Authentication

• Click OK

Network Permissions Tab:

The following settings will hide all other SSID's except those named in this GPO:

• Select Prevent connections to ad-hoc networks

• Select Prevent connections to infrastructure networks

• Uncheck Allow user to view denied networks

• Select Only Group Policy profiles for allowed networks

Support Stuff

Given the complexity that is now building within the network, it's not unexpected that there's going to be a few bumps along the way. The following section should help point you in the right direction.

pfSense Logs

• Enable the FreeRadius logs by navigating to Services > FreeRadius > Settings

• Personal choice, I prefer the radius.log output.

• Enable temporary SSH access by navigating to System > Advanced > Secure Shell

• Enable Secure Shell Server

• Add a Firewall rule to allow TCP port 22

• Secure Shell into the pfSense.

ssh admin@pfsense.toyo.loc

• cat /var/log/radius.log

• When you're done, shut the door behind you, disable SSH and kill the firewall rule."

Windows Client Logs

When it comes to troubleshooting 802.1X on Windows, the built-in logging and diagnostic tools are:

• As an Admin, run the following netsh command

netsh wlan show wlanreport

The netsh wlan show wlanreport command generates an HTML report that provides a detailed overview of recent Wi-Fi connection history, including connection successes, failures, signal quality, and reasons for disconnects.

The following event logs offer a more traditional, readable output for analyzing connection issues.

A Step to Zero Trust

We made it...eventually, what a long post and a whole lot of certificates. I’ll keep it short from here. Thanks for sticking with it. Next up: IPsec. Don’t miss it... Everyone loves IPSec

Related Posts:

Part 1 - Zero Trust Introduction

Part 2 - VLAN Tagging and Firewalls with pfSense

Part 3 - pfSense and 802.1x

Part 4 - IPSec for the Windows Domain

Part 5 - AD Delegation and Separation of Duties

Part 6 - Yubikey and Domain Smartcard Authentication Setup

Part 7 - IPSec between Windows Domain and Linux using Certs

Yet to complete

Part 8 - Monitoring, IPS and IDS

Part 9 - DNS-over-HTTPS