Blocked MAC Address redirect URL not working

h2professor

We have a configuration where devices listed in Captive Portal's MAC list are allowed out to the Internet, and everyone else is prompted for a UserID and password. When someone in the organization misbehaves, the MAC is set to Block, which is then redirected to a URL configured in "Blocked MAC address redirect URL" which provides instructions for getting their access back. The instruction page is an IP address on the same subnet as the device, so it doesn't go through pfSense. It has been working this way for years.

Today we (finally) upgraded from 2.4.3_1 to 2.4.4, and now the "Block" MAC addresses are getting prompted for a password instead of redirecting to the URL. The user has to enter a valid user ID and password, and only then does pfSense forward them to the instruction page. Regardless of pfSense, the blocked user can still access the instruction page by typing the URL into the address bar on their browser, but until then they are prompted for a user ID and password for all other attempts to browse.

Obviously something has changed in this version. Is anyone aware of a workaround for this? Is this a bug, or was it intentional?

I have tried putting the IP address of the instruction page in Allowed IP addresses and Allowed Hostnames.

Thank you for your help.

Gertjan

When a MAC is marked as blocked, I can still try to login.
Which means : I could login in to portal very well, and ones logged in, the page shows again, with a message.

I'm curious about this one :

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

the MAC is set to Block, which is then redirected to a URL configured in "Blocked MAC address redirect URL" which provides instructions for getting their access back.

Such a mechanism isn't present in pfSense - not in 2.4.4 or other recent versions.
If a MAC is on the block list, it will not redirect the visitor an any IP : it just show the login page again (probably the error login page) showing a message "...... This MAC address has been blocked".

h2professor

You stated: "Such a mechanism isn't present in pfSense - not in 2.4.4 or other recent versions"

You are incorrect. In the Captive Portal Configuration, one of the Configuration fields is "Blocked MAC address redirect URL" which states "Blocked MAC addresses will be redirected to this URL when attempting access."

It has worked on every version for years until the most recent upgrade, v2.4.4

Screen clip

Gertjan

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

You stated: "Such a mechanism isn't present in pfSense - not in 2.4.4 or other recent versions"

You are incorrect. In the Captive Portal Configuration, one of the Configuration fields is "Blocked MAC address redirect URL" which states "Blocked MAC addresses will be redirected to this URL when attempting access."

It has worked on every version for years until the most recent upgrade, v2.4.4

You're right !!
I stand corrected.

NO URL means : the error-login page wil be shown with a message.
I tried with an URL.

The problem was, for me, that I have no web servers on my captive portal network, except for pfSense itself. I treat the captive portal network as an "Internet access facility only" - No printers etc.

So, I added a URL https://www.my-site.tld (an URL to our company's Internet site, a sites that lives somewhere on the Internet - I also added this URL to the "Allowed hostnames tab" (captive portal settings)).

When I logged in using with my MAC Blocked device, after authentication, I was redirected to my site/URL https://www.my-site.tld

h2professor

You're right !!
I stand corrected.

You're awesome.

So, I added a URL https://www.my-site.tld (an URL to our company's Internet site, a sites that lives somewhere on the Internet - I also added this URL to the "Allowed hostnames tab" (captive portal settings)).

When I logged in using with my MAC Blocked device, after authentication, I was redirected to my site/URL https://www.my-site.tld

And that's where we're running into a problem. As you can see in my configuration above, I'm redirecting the user to an IP address on their own subnet-- 10.55.1.2-- so they don't need to get outside the firewall to see that page. And if they enter that URL directly into their browser, they can see it just fine. But in version 2.4.4 they are suddenly required to enter a user/password before they are redirected. This feels like a bug.

Help!!!

Gertjan

If a URL is local, on the same "captive portal network" network, then it's normal a visitor could access it directly. The pfSense portal will be completely bypassed anyway - isn't needed.
But, the visitor should point it browser directly to the Ip/URL ... somewhat inconvenient.

I confirm that the redirection takes place after the authentication phase. That's what I saw also.

I ran over the code that decides to redirect to a blocked MAC URL :
https://github.com/pfsense/pfsense/blob/dfbf0d5f3417c78025cafabadb47c2dae43954f4/src/usr/local/captiveportal/index.php#L142
Change the first "&&" for "||" and test.

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

Should become :

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

h2professor

Change the first "&&" for "||" and test.

Thank you. I'll give this a try.
(It might be a good idea to fix this in future releases.)
Cheers

Gertjan

Maybe my proposed "patch" works for you, but after reading the related code again, I think there is no bug. My patch isn't a solution.
pfSense 2.4.4 wants you to identify first - the login page has to show up.

Then - when you hit "Enter" after inputting a user and password,

($_POST['accept'] || $cpcfg['auth_method'] === 'radmac')

becomes true.

This part also become TRUE :

$macfilter && $clientmac && captiveportal_blocked_mac($clientmac)

(if the MAC is on the block list)

Without the patch I suggested above, I was redirected to the "blockedmacsurl" URL after validating my login and my MAC was on the Block list (I blocked my MAC). The URL showed up.

I advise you not to change the code, but building your own "html" captive login portal page.
You will have to add some PHP code, that executes something like this :

....
<?php
if ($macfilter && $clientmac && captiveportal_blocked_mac($clientmac)) {
	captiveportal_logportalauth($clientmac, $clientmac, $clientip, "Blocked MAC address - show message");
?>
p>Warning : you will get redirected after login to our local server, to receive special instructions.</p>
<?php
}
?>
.....

When the user is blocked a message in the logs shows up : "Blocked MAC address - show message"
And the line "Warning : you will get redirected after login to our local server, to receive special instructions." will show up on the login page.

So, again, the user HAS to login first. If he is MAC blocked, he will be pointed to the "blockedmacsurl" page.

Images :
My MAC is blocked :
0_1542012714628_339c61b0-899d-45ab-b381-b73194ee7cbe-image.png

I have an MAC Block URL :
0_1542012776410_46754ddc-81de-401a-98ae-92840d34392d-image.png

This URL, because it's on the net, exists on the Allowed hostnames tab :
0_1542012823189_96b5cb08-4ff4-472d-91c3-2764907d684d-image.png
(this shouldn't be needed for you)

When I login, I see this in my log file :
0_1542012889072_e8209226-47cf-4103-ab3d-7c045acc90a2-image.png

and I'm redirected to my "MAC Block URL" site.

All this without the patch above - I didn't tried to modify my html login page - as I mentioned above.

h2professor

I advise you not to change the code, but building your own "html" captive login portal page.
You will have to add some PHP code, that executes something like this :

I really don't want to write any custom code, because the next upgrade might change the behavior again.

It has been working for years, and this upgrade caused it to stop working. Doesn't this meant the problem is with pfSense?

Gertjan

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 ?

What I proposed is rewriting your local html captive portal login file - this file is meant to be personalized. Everybody changes this file, it just some style sheet info, some html and even some PHP if needed.
This file will survive upgrades. Your own branded captive portal login file stays yours.
With some added code, you could inform the user that he will get redirected after login because he is MAC blocked.

You will have to modify the "pfSense" code (a line in the index.php file, as said ) if you want a direct redirection, as before.

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!