Todo #7024
closedReplace copy of radius.inc by pear-Auth_RADIUS
100%
Description
Replace copy of radius.inc, with a good number of modifications, by pear-Auth_RADIUS provided by ports
Updated by Jim Pingle about 7 years ago
- Target version changed from 2.4.1 to 2.4.2
Updated by Jim Pingle about 7 years ago
- Target version changed from 2.4.2 to 2.4.3
Updated by Renato Botelho over 6 years ago
- Target version changed from 2.4.3 to 2.4.4
Push for 2.4.4
Updated by Renato Botelho over 6 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset e26b805c92d2454629a8f63ca491c2c3c812d9dc.
Updated by James Webb over 6 years ago
I believe the change applied in commit: e26b805 may have caused errors; specifically those referenced in issue #8617. Can I please have further clarification as to whether the pear-Auth_RADIUS package provided by ports is actually included in the current development snapshots?
Updated by Renato Botelho over 6 years ago
James Webb wrote:
I believe the change applied in commit: e26b805 may have caused errors; specifically those referenced in issue #8617. Can I please have further clarification as to whether the pear-Auth_RADIUS package provided by ports is actually included in the current development snapshots?
pear-Auth_RADIUS port is part of pfSense for a long time. It was not being used. You can check if it's present in your system running `pkg info | grep RADIUS`
Updated by Vladimir Lind about 6 years ago
On 2.4.4 Fri Aug 17 21:29:09 EDT 2018:
Shell Output - pkg info | grep RADIUS
freeradius3-3.0.17 Free RADIUS server implementation
hostapd-2.6_1 IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator
pfSense-pkg-freeradius3-0.15.5_3 FreeRADIUS 3.x package for pfSense
php72-pear-Auth_RADIUS-1.1.0_4 PEAR wrapper classes for the RADIUS PECL
squid_radius_auth-1.10 RADIUS authenticator for squid proxy 2.5 and later
Updated by Chris Macmahon about 6 years ago
root: pkg info | grep RADIUS
hostapd-2.6_1 IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator
php72-pear-Auth_RADIUS-1.1.0_4 PEAR wrapper classes for the RADIUS PECL
[2.4.4-DEVELOPMENT][root@pfSense.localdomain]/root:
Updated by Constantine Kormashev about 6 years ago
It seems ok on latest 244
php72-pear-Auth_RADIUS-1.1.0_4 PEAR wrapper classes for the RADIUS PECL
Updated by Jim Pingle about 6 years ago
The package is there, but what we need is more functional testing. We need to make sure not only that RADIUS authentication works but also accounting (where supported) as well as values passed back from RADIUS like certain configurations for OpenVPN, IPsec, Captive Portal, etc.
See https://netgate.slack.com/files/U0PFG0Z2B/FBFMBHQFJ/radius_tests_txt.txt :
- Basic RADIUS auth (Diag > Auth test)
-- https://www.netgate.com/docs/pfsense/book/usermanager/authentication-servers.html
- GUI RADIUS auth
-- Primary concern is fetching groups from RADIUS
-- https://www.netgate.com/docs/pfsense/book/usermanager/authentication-servers.html
- IPsec RA RADIUS auth
-- values passed back from server: IP addr
-- https://www.netgate.com/docs/pfsense/vpn/ipsec/ikev2-with-eap-radius.html
- OpenVPN RA RADIUS auth
-- values passed back from server: IP addr, routes, rules (inacl/outacl), DNS servers
-- https://www.netgate.com/docs/pfsense/book/openvpn/controlling-client-parameters-via-radius.html
- Captive Portal RADIUS auth
-- values passed back from server: bw limits, session timeout, idle time, time/data limits, URL redirection
-- https://www.netgate.com/docs/pfsense/book/captiveportal/zone-configuration-options.html#passing-back-configuration-from-radius-servers
- PPPoE Server RADIUS auth
-- https://www.netgate.com/docs/pfsense/book/services/pppoe-server.html
- L2TP Server RADIUS auth
-- https://www.netgate.com/docs/pfsense/book/l2tp/l2tp-server-configuration.html#authentication
- Wireless 802.1x auth
-- https://www.netgate.com/docs/pfsense/book/wireless/pfsense-as-an-access-point.html#ieee-802-1x-authentication-wpa-enterprise
Updated by A FL about 6 years ago
Well, I made some tests :
Basic RADIUS auth (Diag > Auth test)¶
-> Good (working correctly)
GUI RADIUS auth¶
-> Good (working correctly).
Groups are correctly fetched from the RADIUS server & group rights are correctly applied to the logged user. Local database fallback is also working as expected
Captive Portal RADIUS auth¶
- bw limits (using pfSense-Bandwidth-Max-Up and pfSense-Bandwidth-Max-Down) -> Working correctly
I carefully verified that these RADIUS attributes do override pfSense's settings if any (and if they are enabled).
I also verified that these RADIUS attributes are not fetched when unchecking "Use RADIUS pfSense-Bandwidth-Max-Up and pfSense-Bandwidth-Max-Down attributes". Everything is working as expected
I found a small issue with RADIUS bw limits however : pfsense-Bandwidth-Max-Up/Down have to be written in bits per seconds in the RADIUS reply, and are converted in kbps internally by pfSense when applying the ipfw rules.
However, the conversion assumes 1000 bits = 1kb. Shoudn't it be 1024 bits = 1kb?
(Anyway, it's a small issue and it's not a regression so...I don't think it needs to be fixed before 2.4.4 is released)
- data limit/traffic quota (using pfSense-Max-Total-Octets) -> Working correctly
I also verified that the RADIUS attribute does override pfSense's "traffic quota" if set.
- time limit (Using Session-Timeout) => Working correcty
The time has to be given in seconds in the RADIUS reply (as specified in RFC2865)
I carefully verified that this RADIUS attribute does override pfSense's session timeout if any.
Also, i verified that this RADIUS attribute is not fetched when unchecking "Use RADIUS Session-Timeout attributes".
- idle time timeout (using Idle-Timeout) => Working correctly
As for Session-Timeout, the time has to be given in seconds
I carefully verified that this RADIUS attribute does override pfSense's idle timeout if any.
- url redirection (using WISPr-Redirection-URL): Working correctly
I carefully verified that RADIUS attribute does override pfSense's redirect URL if set.
I'm not sure if i missed something, would it be possible to request access to the full https://netgate.slack.com/files/U0PFG0Z2B/FBFMBHQFJ/radius_tests_txt.txt file ?
Updated by Jim Pingle about 6 years ago
A FL wrote:
I found a small issue with RADIUS bw limits however : pfsense-Bandwidth-Max-Up/Down have to be written in bits per seconds in the RADIUS reply, and are converted in kbps internally by pfSense when applying the ipfw rules.
However, the conversion assumes 1000 bits = 1kb. Shoudn't it be 1024 bits = 1kb?
(Anyway, it's a small issue and it's not a regression so...I don't think it needs to be fixed before 2.4.4 is released)
We've gone back and forth on kilobits vs kibibits there in the past. It's more important that Captive Portal and FreeRADIUS match since limiters will blow up with non-integer bandwidth values (See #8097). I can't find it now but I remember a lengthy debate on it somewhere.
I'm not sure if i missed something, would it be possible to request access to the full https://netgate.slack.com/files/U0PFG0Z2B/FBFMBHQFJ/radius_tests_txt.txt file ?
Sure, here is the list:
- Basic RADIUS auth (Diag > Auth test)
- GUI RADIUS auth
- Primary concern is fetching groups from RADIUS
- https://www.netgate.com/docs/pfsense/book/usermanager/authentication-servers.html
- IPsec RA RADIUS auth
- values passed back from server: IP addr
- https://www.netgate.com/docs/pfsense/vpn/ipsec/ikev2-with-eap-radius.html
- OpenVPN RA RADIUS auth
- values passed back from server: IP addr, routes, rules (inacl/outacl), DNS servers
- https://www.netgate.com/docs/pfsense/book/openvpn/controlling-client-parameters-via-radius.html
- Captive Portal RADIUS auth
- values passed back from server: bw limits, session timeout, idle time, time/data limits, URL redirection
- https://www.netgate.com/docs/pfsense/book/captiveportal/zone-configuration-options.html#passing-back-configuration-from-radius-servers
- PPPoE Server RADIUS auth
- L2TP Server RADIUS auth
- Wireless 802.1x auth
Updated by Renato Botelho about 6 years ago
- Status changed from Feedback to Resolved
The main move is done. Specific possible bugs found should have new tickets