Unable to setup EAP-TLS using FreeRADIUS on OPNSense

Started by liner03_brogans, July 13, 2023, 06:30:08 PM

Previous topic - Next topic
hi, I am trying to set up EAP-TLS (802.1x certificate based authentication) on my OPNsense Box. As EAP-TLS uses cert, hence there should be no password. May I ask what should I type in the password box? Thank you~

I use pfsense FreeRADIUS plugin before, and I just leave it blank and it does authenticate users.

Versions OPNsense 23.1.11-amd64, FreeBSD 13.1-RELEASE-p8.

Plugin name: FreeRADIUS , Free Radius version 1.9.22.

screenshot link: https://imgur.com/a/Vt3AHVJ
Thanks all~

You dont need to set users, certificate is enough as you authenticate the device, not the user

Thank for your reply~ May I ask how to set a vlan for a EAP-TLS  device cert?

I think this is not possible via GUI. If you find a guide via CLI which you can reproduce I can have a look to implement it

Does this mean that it is not currently possible to configure OPNsense for EAP-TLS (802.1x certificate based authentication)?

I'd like to try to move from pfSense to OPNsense but lack of device certificate based 802.1x EAP-TLS authentication is a show stopper for us...  :-\

I wonder if there are any news concerning this feature ("how to set a vlan for a EAP-TLS  device cert") that was missing in 2023...

September 05, 2025, 10:09:49 AM #6 Last Edit: September 05, 2025, 11:00:57 AM by OPNenthu
Registering my interest also.  I'll check for and open a feature request on GH.

As a user with a private CA on OPNsense and no enterprise infrastructure for MDM, I'd still like to manually deploy my CA cert and the client certificates (as pkcs12 packages) to a small number of mobile clients and have FreeRADIUS assign the VLAN based on the client CN or OU.  That will also allow me to coalesce my broadcasting SSIDs and reduce airtime significantly while still using WPA3 security.  (Note: WPA3-SAE removed the option for multiple PPSKs per SSID)

Presently with the FreeRADIUS plugin in 25.7 we can only define Users with passwords, as for EAP-PEAP.  This doesn't work for Android 11+ clients because Google disallows private CAs for PEAP.  They are only allowed for EAP-TLS.

There is no GUI option presently to configure EAP-TLS VLAN assignment.

September 06, 2025, 03:55:21 AM #7 Last Edit: September 06, 2025, 04:16:43 AM by OPNenthu
Quote from: mimugmail on July 14, 2023, 09:51:18 AMI think this is not possible via GUI. If you find a guide via CLI which you can reproduce I can have a look to implement it

Hi @mimugmail, I'm looking currently at the file /usr/local/etc/raddb/sites-enabled/check-eap-tls.  It looks to be already matching the cert CN and maybe it just needs to be extended for VLAN assignment as well?

According to ChatGPT it could be something like below.  These examples match either on the CN or the OU for department-wide VLAN assignment.

post-auth {
    if ("%{TLS-Client-Cert-CN}" == "device01") {
        update reply {
            Tunnel-Type := VLAN
            Tunnel-Medium-Type := IEEE-802
            Tunnel-Private-Group-ID := "20"
        }
    }

    if ("%{TLS-Client-Cert-OU}" == "HR") {
        update reply {
            Tunnel-Type := VLAN
            Tunnel-Medium-Type := IEEE-802
            Tunnel-Private-Group-ID := "30"
        }
    }
}

Here, "device01" is a short name from the certificate CN, but this can also be device01.example.org.

It says that the Users files can also be used, as a second option (but not recommended):

device01
    Tunnel-Type := VLAN,
    Tunnel-Medium-Type := IEEE-802,
    Tunnel-Private-Group-ID := "20"

In that case this snippet still needs to be in sites-enabled/default to extract the CN. 

update request {
    User-Name := "%{TLS-Client-Cert-CN}"
}

I think the Users method could be harder to manage from the plugin since the config file is in conflict with the options needed for EAP-PEAP (for example Framed-Protocol = PPP),  but I'm not sure.  At least with this method the only thing that would be needed in the GUI is an option to disable the password requirement when EAP-TLS is enabled.

Can you guide me on how to test this on a live system so that the config changes don't get clobbered?  I have an Android 11 client and a Windows 10 laptop that I can try for now.   I can also try a wired Linux client.

September 07, 2025, 06:59:25 AM #8 Last Edit: September 07, 2025, 07:05:03 AM by OPNenthu
I tried to confirm that this would work before raising a feature request and unfortunately I hit a wall with my particular WiFi clients.  Maybe someone else can take it further.

This is the tutorial I followed: https://wiki.alpinelinux.org/wiki/FreeRadius_EAP-TLS_configuration

I made the edits to /usr/local/etc/raddb but I get either silent failures on the client-side, or error messages in FreeRADIUS logs:

Auth: (219) Login incorrect (eap_tls: (TLS) TLS - Alert read:fatal:internal error): [OnePlus-6T] (from client unifi port 1 cli <redacted>)
ERROR: (219) eap_tls: ERROR: (TLS) TLS - Alert read:fatal:internal error

...

Auth: (213) Login incorrect (eap_tls: (TLS) TLS - Alert write:fatal:illegal parameter): [lightbox] (from client unifi port 1 cli <redacted>)
ERROR: (213) eap_tls: ERROR: (TLS) TLS - Server : Error in error

Ideally this could be made to work simply in FreeRADIUS.

Having failed that, something like Smallstep (self-hosted) might be used and I found a prior effort to port that to OPNsense which seems to have stalled out: https://github.com/smallstep/certificates/discussions/2023

It would be easier if you can set up a running configuration on FR itself (without OPN) and then we can have a look at the configuration.

September 07, 2025, 11:55:57 AM #10 Last Edit: September 07, 2025, 12:19:05 PM by OPNenthu
I started to configure FR on Proxmox and had trouble configuring certificates so gave up on that.  Instead I went back to OPNsense and re-installed the FR plugin with all defaults and this time I did not configure any users, relying only on the cert and a WiFi SSID already set up on VLAN 70.  I noticed that I couldn't authenticate no matter what- same errors as before.  So even in the basic case EAP-TLS doesn't work for me.

I then tried again with EAP-PEAP and set up a user in the GUI with VLAN 70 and this time, I circumvented part of the security in the WiFi profile by choosing not to validate the server certificate.  Finally, that worked, and I was assigned to the correct VLAN.

So I think I jumped the gun a bit and need to first sort out some client capabilities and possible certificate issues. :-/

Hi @mimugmail - just wanted to update and confirm that I sort of got this working, so maybe there are no changes needed in the plugin.

My particular Android is too old and has an issue that it won't trust private CAs which are added manually outside of an MDM tool.  I managed to get it working on my Windows 10 laptop after fixing some errors on my end.  I'll switch back to regular WPA2-PPSK for now, however, I will lay out my notes below in case others need this.  I'm sorry I'm not able to test other OSes.

The main take-away is that User definitions work in EAP-TLS as well, if you ignore the password requirement in the plugin UI.  Just give a random password that you won't use anywhere and forget that it exists.

root@firewall:/usr/local/etc/raddb # cat users

lightbox Cleartext-Password := "unused_in_eap_tls"
       Tunnel-Type = VLAN,
       Tunnel-Medium-Type = IEEE-802,
       Tunnel-Private-Group-Id = 70,
       Framed-Protocol = PPP


DEFAULT Framed-Protocol == PPP
        Framed-Protocol = PPP,
        Framed-Compression = Van-Jacobson-TCP-IP

DEFAULT Hint == "CSLIP"
        Framed-Protocol = SLIP,
        Framed-Compression = Van-Jacobson-TCP-IP

DEFAULT Hint == "SLIP"
        Framed-Protocol = SLIP

This user name (e.g. "lightbox") should match the client certificate (CN=lightbox).  Emails and FQDNs might work here too; I didn't try.  Also, I could only connect if I specified this user for the outer TLS tunnel (I couldn't use "anonymous") which is kind of not great as it reveals identity, but it did work.

A few other notes / pitfalls that IT pros already know but home labbers like myself may stumble on:

1) The client and the radius server need to use or support the same key type (e.g. prime256v1).  You can't mix and match or they won't negotiate.

2) Dnsmasq users: your radius server needs to be an A/AAAA record if you want to use it as the CN in the server certificate.  If you use a CNAME record then the server FQDN (e.g. radius.home.arpa) needs to be in the certificate SAN list.

3) Windows clients that are not domain joined will need a manual tweak to allow EAP-TLS to prompt for user certificate in the WiFi profile.
   Add with regedit:

      [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates\SystemCertificates\Root\ProtectedRoots]
   "Flags"=dword:00000002
   

---

So overall the requested feature kind of already works as-is with the FreeRADIUS plugin in OPNsense 25.7.2.  At least, you can get VLAN assignment if you give up some anonymity in the TLS negotiation with FreeRADIUS.  I didn't try too hard to get it working otherwise but it might be possible.