pfSense

WRT ##14093's rejection,
"The solution here is to set each portal to use the RADIUS server in a different way, either with a different NAS Identifier in the portal settings, or something along those lines (maybe separate definitions that send a different NAS IP), and then filter that as you want on the RADIUS server.

tl;dr the authentication server should be making the authentication decisions, not the portal."

We are already sending a different NAS ID (32) as in CaptivePortal-vlan50 and CaptivePortal-vlan60 for example. Both have an IP from different subnets 192.168.1.50.XX and 192.168.1.60.XX for example. freeRadius is authenticating every time, not rejecting; despite being in possession of that data so there is clearly a handshaking issue, independent upon whom is going to decide to approve or reject the authentication request. The typical pfSense user only has access to the freeRadius GUI built into pfSense to implement "something along those lines". What am I missing here?

If freeRadius was correctly parsing the attributes sent in the accounting communication to freeRadius, the following code inserted into function captiveportal_send_server_accounting( in captiveportal.inc 2411) at 2447 as shown below should have triggered a reject response from freeRadius and it does not.

$racct->putAttribute(RADIUS_NAS_IDENTIFIER, empty($cpcfg["radiusnasid"]) ? "CaptivePortal-{$cpzone}" : $cpcfg["radiusnasid"] );

/* --NEW CODE --------Constant Definitions added here for now ------------------ */

define("RADIUS_TUNNEL_TYPE", 64 );
    define("RADIUS_TUNNEL_MEDIUM_TYPE", 65 );
    define("RADIUS_TUNNEL_PRIVATE_GROUP_ID", 81 );

$racct->putAttribute(RADIUS_TUNNEL_TYPE, "VLAN");
    $racct->putAttribute(RADIUS_TUNNEL_MEDIUM_TYPE, "IEEE-802");
    $racct->putAttribute(RADIUS_TUNNEL_PRIVATE_GROUP_ID, empty($cpcfg["radiusnasid"]) ? "CaptivePortal-{$cpzone}" : $cpcfg["radiusnasid"] );

/* ----------------------------------------------------------------------------- */

if (is_int($ruleno)) {

I do achieve the desired result by testing for NAS ID in captiveportal.inc function captiveportal_authenticate_user( after line 1309 in captiveportal.inc with the following test:

/* ----------------------------------------------------- New Code ------------------------------------------- */

/* Check to see if this user is a monthly/router user (vlan60) and deny access to DATA (vlan50) and vice versa*/
/*
$user_file = "/var/log/radacct/datacounter/monthly/max-octets-";
$user_file .= $login;
if (file_exists($user_file) && ($cpzone == "vlan50")) {
$status = "FAILURE";
$result = false;
}
$user_file = "/var/log/radacct/datacounter/forever/max-octets-";
$user_file .= $login;
if (file_exists($user_file) && ($cpzone == "vlan60")) {
$status = "FAILURE";
$result = false;
}
/
/ --------------------------------------------------------------------------------------------------------------- */

The above is just a site specific kludge because a response from freeRadius containing the "RADIUS_TUNNEL_PRIVATE_GROUP_ID" is not available to assess in the $attributes array. If it was available, we could solve the issue in the captiveportal_authenticate_user( routine by simply testing the attribute for "RADIUS_TUNNEL_PRIVATE_GROUP_ID"(81) against the NAS ID (32). Obviously either of the above approaches would be a solution to this concern.