"
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
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
