Blocked MAC Address redirect URL not working

h2professor

@gertjan said in Blocked MAC Address redirect URL not working:

What happens now is that users that are MAC blocked have to authenticate first. That shouldn't be a problem, as they are blocked, which means they had an access, thus user/password, so they can authenticate .
Right ?

No!!! Because most users are visiting public with mobile hardware that will never be given a user ID and password. When a system is blocked, it needs to display the "this hardware has been blocked from access" message. Once again, it has been working this way since Captive Portal was introduced years and years ago. And now it's not. And I'm not going to ask my client to change their business model just because pfSense changed the way they do things.

This is a bug.

I'll look into modifying the files.

Gertjan

@h2professor said in Blocked MAC Address redirect URL not working:

I'll look into modifying the files.

I've cooked up something for you.

No need to modify pfSense files.
You need to make your own portal login page.

In this page, you have to include these lines :

<?php

require_once("auth.inc");
require_once("functions.inc");
require_once("captiveportal.inc");

global $cpzone, $cpzoneid;

$orig_host = $_SERVER['HTTP_HOST'];
$clientip = $_SERVER['REMOTE_ADDR'];

$cpzone = strtolower($_REQUEST['zone']);
$cpcfg = $config['captiveportal'][$cpzone];
if (empty($cpcfg)) {
	log_error("Submission to captiveportal with unknown parameter zone: " . htmlspecialchars($cpzone));
	portal_reply_page($redirurl, "error", gettext("Internal error"));
	ob_flush();
	return;
}

$cpzoneid = $cpcfg['zoneid'];

$macfilter = !isset($cpcfg['nomacfilter']);

/* find MAC address for client */
if ($macfilter || isset($cpcfg['passthrumacadd'])) {
	$tmpres = pfSense_ip_to_mac($clientip);
	if (!is_array($tmpres)) {
		/* unable to find MAC address - shouldn't happen! - bail out */
		captiveportal_logportalauth("unauthenticated", "noclientmac", $clientip, "ERROR");
		echo "An error occurred.  Please check the system logs for more information.";
		log_error("Zone: {$cpzone} - Captive portal could not determine client's MAC address.  Disable MAC address filtering in captive portal if you do not need this functionality.");
		ob_flush();
		return;
	}
	$clientmac = $tmpres['macaddr'];
	unset($tmpres);
}


if (!$clientip) {
	/* not good - bail out */
	log_error("Zone: {$cpzone} - Captive portal could not determine client's IP address.");
	$errormsg = gettext("An error occurred.  Please check the system logs for more information.");
	portal_reply_page($redirurl, "error", $errormsg);
	ob_flush();
	return;
}

if ($macfilter && $clientmac && captiveportal_blocked_mac($clientmac)) {
	if (!empty($cpcfg['blockedmacsurl'])) {
		captiveportal_logportalauth($clientmac, $clientmac, $clientip, "Blocked MAC address : will redirect");
		portal_reply_page($cpcfg['blockedmacsurl'], "redir");
	} 
}

?>

These 'php' lines should be in the <body> part of your login page.

Now you have your old behavior back : as soon as a device's MAC is listed on the MAC tab as being blocked, the user will be redirected straight away to the "Blocked MAC address redirect URL" without any need to login first.

The only thing I did was importing some logic from the main index.php file into my own captive portal "html" page.

free4

redmine issue : https://redmine.pfsense.org/issues/9114

h2professor

Now you have your old behavior back : as soon as a device's MAC is listed on the MAC tab as being blocked, the user will be redirected straight away to the "Blocked MAC address redirect URL" without any need to login first.

The only thing I did was importing some logic from the main index.php file into my own captive portal "html" page.

Thank you for the workaround. It's still not the point.

Consider this: if a MAC address is listed in the MACs tab, regardless of whether it's set to "allow" or "block" it is supposed to bypass the login prompt. That's the point of the MACs tab: to bypass login.

Gertjan

@h2professor said in Blocked MAC Address redirect URL not working:

It's still not the point.

I understand.
You saw that you received already an answer here : https://redmine.pfsense.org/issues/9114
pfSense doesn't have - as far as I know - a system where every line of code is motivated.
I do agree with you that "pass" == "pass" without any captive portal login page activity - then "block" (even without a message) should block (and if you want, as proposed : redirect somewhere else).

In your case, it easy :
Change

} elseif (($_POST['accept'] || $cpcfg['auth_method'] === 'radmac') && $macfilter && $clientmac && captiveportal_blocked_mac($clientmac)) {

for

} elseif ($macfilter && $clientmac && captiveportal_blocked_mac($clientmac)) {

and your done.

This is the line that is responsible for the new situation.
Why it changed ... dono.

Still, I advise you to change your own portal login file to get the old situation back. I tested these (see above) lines : it works.

Also : never ever accept new versions without testing .... and do not trust free software more then software you pay for ^^

h2professor

Still, I advise you to change your own portal login file to get the old situation back. I tested these (see above) lines : it works.

Also : never ever accept new versions without testing .... and do not trust free software more then software you pay for ^^

Thank you very much. That's very helpful.

h2professor

It looks like it has been added as a bug to be fixed in the next release.
Thank you

Gertjan

If you want to test-drive : here it is : https://github.com/pfsense/pfsense/commit/83a6f504d6eb4d1925c4745a6457805fbbe308d9

free4

@h2professor Would it be possible for you to test the patch on your side and give feedback on the redmine issue? I'd like to to confirm that the bug is fixed

h2professor

This post is deleted!

h2professor

@free4 said in Blocked MAC Address redirect URL not working:

@h2professor Would it be possible for you to test the patch on your side and give feedback on the redmine issue? I'd like to to confirm that the bug is fixed

I can confirm that the code change solves this problem.
Thank you