Freeradius VLAN fallback current implementation breaks EAP

[cguareschi]

I am not sure if this is the right place to post this.

In the current implementation of freeradius there is a big problem with VLAN fallback if freeradius is used for both MAC Based Authentication and other authentication methods like EAP-TLS that requires further handshake.

The problem with the current implementation is that when Fallback VLAN is enabled,
the generated FreeRADIUS users file contains:

DEFAULT Auth-Type := Accept

This fallback rule is not restricted to MAC authentication and can therefore
interfere with other authentication methods handled by the same FreeRADIUS
instance.

In particular, Auth-Type := Accept can prevent EAP authentication from
proceeding through its normal handshake.

The solution is a one-liner change in the freeradius user template.

Restrict the fallback rule to MAC authentication using the RADIUS
Service-Type = Call-Check semantic:

DEFAULT Service-Type == Call-Check, Auth-Type := Accept

This preserves the existing fallback behavior for MAC authentication while
preventing the fallback rule from matching unrelated authentication methods.

RFC 5080, section 2.1.1, specifically addresses this use case:

"Implementing MAC address checking without using a Service-Type of
Call Check is NOT RECOMMENDED."
https://www.rfc-editor.org/rfc/rfc5080.html#section-2.1.1

Tested with Fallback VLAN enabled:

Unknown MAC authentication -> fallback VLAN
Known MAC authentication -> configured VLAN
EAP-TLS -> authenticates normally
Captive portal authentication -> authenticates normally

I submitted an issue and a pull request to help with this quite some time ago but it still unanswered.
I was wondering if the freeradius maintainer or anybody else that can help hangs here and could kindly review this.

I think this would be useful to many.

Cheers


Claudio


PS the issue is:https://github.com/opnsense/plugins/issues/5734