Captive portal - what am i missing

stephenw10

@michmoor said in Captive portal - what am i missing:

No internet connectivity is possible.

But do you see any connections from that client passing the firewall? And states that are not redirected?

The only way the client should try to connect without detecting the CP is if the test connection is being passed.
Do you have anything in the bypass captive portal list?

michmoor

@stephenw10
I see NO connections passing through the firewall. Once i attempt to connect to the network with CP enabled, i see the states redirected to the gateway and thats it. Clients do not get the portal sign in page at all.

Below you see the redirects to 8002/8003. NGINX (pfSense process) isnt serving the page. Normally on an iphone the portal page loads up and i enter credentials. Works without issues. Im half way tempted to load up 22.05 in my boot environment and test this out because i did have this working on multiple interfaces without issues. Then again this could be my fault entirely. I just dont see how it is right now.

michmoor

@stephenw10
https://docs.netgate.com/pfsense/en/latest/troubleshooting/captiveportal.html#captive-portal-does-not-redirect

I have triple checked this piece of documentation. DNS does work. I remove CP off the interface and normal web browsing can function again. When i re-enable CP on the interface thats when things stop.
I even have a DNS Redirect rule just in case....

stephenw10

I assume if you try to visit an http site you get correctly redirected to the portal in the traditional manner?

I just can't see how the portal detection in the browser/OS wouldn't be triggered unless the test site was being passed.

michmoor

@stephenw10
I think i may have found the potential issue within CP.

I created a new VLAN for lab purposes.
Ubuntu 22.04 is the client.
CP enabled for an interface called LAB
** disregard previous notes**
I re-created the CP config but as i suspected on a new interface , NGINX is not displaying the page.

eventually it times out.

Just help me understand one point. If i make my portal address of 192.168.99.1 DOES that mean that if i enabled CP on another network say 192.168.15.0/24 that network needs a firewall rule to connect to the captive portal of 192.168.99.1 ?
Based on the states i never see a connection made to the specific CaptivePortal DNS IP record.

stephenw10

Yes it would need to be able to access that. By default it redirects to the interface IP address.

michmoor

@stephenw10 said in Captive portal - what am i missing:

Yes it would need to be able to access that. By default it redirects to the interface IP address.

I suppose thats the part where im not understanding.
If i have portal.example.com at 192.168.11.1 and attached to my GuestNetwork-1.
I now want to set up another CaptivePortal network for GuestNetwork-2. What would my firewall rules look like for GuestNetwork-2 ? I assume I need DNS but if traffic gets redirected to the interface IP do i need firewall rules to allow GuestNetwork-2 to hit portal.example.com which has a different IP? What ports would I even allow?

stephenw10

Only if you're hosting the portal login page there somehow. Normally the page is hosted at the interface IP address. The client gets redirected to https://192.168.11.1:8003 or http://192.168.11.1:8002 and sees the login.

michmoor

@stephenw10
So whats best practice if you have multiple interfaces that need to be behind a captive portal?
If i create a portal address what IP do i give it?
edit -- pfSense is hosting the portal.

stephenw10

Where are you actually using that FQDN? Normally I would not expect to have anything other than the interface IP which then works fine on multiple interfaces.

Otherwise anything that is on the portal login page must be added the CP pass-through list so clients can access it.

michmoor

@stephenw10

I think the problem at the end of the day is that Captive Portal doesnt work with multiple interfaces.
If i have GUEST1 and GUEST2 what IP do i give for HTTPS server name? If i give the portal address an IP for GUEST1 that works fine but GUEST2 will not be able to access the page. Same for the other way around.
That seems to be the limitation that ive been able to recognize but the documentation isnt clear on. The WebUI indicates you can select multiple interfaces which in theory should be true but in reality, you cant.
Should i submit a redmine for an update in documentation?

@stephenw10 said in Captive portal - what am i missing:

Where are you actually using that FQDN?

Not sure I understand the question. portal.example.com is an A record that points to pfsense IP. In the example above, i have the IP pointed to GUEST1 interface IP of pfsense.

michmoor

@stephenw10
Did i just need sleep?
Maybe staring at a problem fixed itself
I swear I dont know what i did but everything is working as i expected. CP is enabled on multiple interfaces and regardless if its a iPhone or a laptop running Windows or an Ubuntu desktop lab VM, they all detect the portal and i can see the landing page from Netgate. Sign in and all is well.
I..............really dont get it but i will take the L
It was my fault.

Gertjan

@michmoor said in Captive portal - what am i missing:

Based on the states i never see a connection made to the specific CaptivePortal DNS IP record.

I presume you want to use the https login page usage.

So you have a wild card certificate, or you have these certificates :
portal.your-portal-domain.tld and portal2.your-portal-domain.tld etc

You should have a DNS override on the resolver page that says

...
portal     your-portal-domain.tld     192.168.15.1   Some description / zone1
portal2   your-portal-domain.tld     192.168.99.1   Some description / zone1
...

You should be able to resolver these names :

C:\Users\Gauche>nslookup portal.your-portal-domain.tld
Server :   pfSense.your-portal-domain.tld
Address:  2a01:cb19:dead:beef:92ec:77ff:fe29:392c

Nom :    portal.your-portal-domain.tld
Address:  192.168.15.1
etc

Use the pfSense / Netgate default DNS resolver settings, and you'll be fine.
( so no 8.8.8.8, etc - no forward mode etc - not saying this might not work, I never tried it )

When the portal works, you can see these logs here :

and more important : here :

This trace mentions / shows an experimental rfc8910.php file, I'll keep that for later, works great.

Your iPhone screen shots - Safari complaining : these are certificate error messages - that's bad indeed.
Latest iOS, right ?

This is what I see when connected :

That's the classic "Bla bla wifi network isn't using an encrypted WPAx, please change your router so encryption is used ... bla bla" - No other message.

I also have this new message :

which you can point to a help page, introduction page, or the portal logout page, or whatever you want.
When your portal works, I'll show you what file (just one) to place where, and you have to add an option to the portal network DHCP server (so exit KEA, you'll be needing ISC DHCP).

@michmoor said in Captive portal - what am i missing:

Sign in and all is well.

Ok.
Now read this : captive portal is not working on mobiles where @EDaleH showed an implementation, based on "How to modernize your captive network" which is became an RFC. This will open up flawless, simple, IPv4 and IPv6 captive portal support.

All you need to do :

Not KEA comptabile (yet), use ISC.
Add ths option "114" :

This is the string :
"https://portal.your-portal-network.tld:8003/rfc8910.php?zone=cpzone1"

The 8003 is the link between your network, for example 192.168.99.1 , which is using 8002 for http, which you are not using, but is is there, and "8003" which is the https port of the "182.168.99.1" portal network.

Create a file called "rfc8910.php" :

<?php

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

header("Expires: 0");
header("Cache-Control: no-cache, no-store, must-revalidate");
header("Pragma: no-cache");
header("Connection: close");

global $g, $config, $cpzone, $cpzoneid, $cpzoneprefix;

$cpzone = strtolower($_REQUEST['zone']);
$cpcfg = config_get_path("captiveportal/{$cpzone}");

if (empty($cpcfg)) {
	log_error("rfc8910 - Submission to captiveportal with unknown parameter zone: " . htmlspecialchars($cpzone));
	portal_reply_page($redirurl, "error", gettext("Internal error"));
	ob_flush();
	return;
}

$cpzoneid = $cpcfg['zoneid'];
$clientip = $_SERVER['REMOTE_ADDR'];

if (!$clientip) {
	/* not good - bail out */
	log_error("Zone: {$cpzone} - rfc8910 - 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;
}

$cpsession = captiveportal_isip_logged($clientip);
$sessionid = $cpsession['sessionid'];
$rfc8910_url = 'https://' . $_SERVER['HTTP_HOST'] . '/index.php?zone=' . $cpzone;

ob_flush();
if (empty($cpsession)) {
//	captiveportal_logportalauth("rfc8910", "EMPTY SESSION : {$_SERVER['HTTP_HOST']}", $clientip, $cpzone);
	$json_post  = array (
		"captive" => true,
		"user-portal-url" => $rfc8910_url,
		"venue-info-url" => $rfc8910_url,
);

echo json_encode($json_post, JSON_PRETTY_PRINT);
} else {
//	captiveportal_logportalauth("rfc8910", "EXISTING SESSION : {$_SERVER['HTTP_HOST']}", $clientip, $cpzone);
	$json_post  = array (
		"captive" => false,
		"user-portal-url" => $rfc8910_url,
		"venue-info-url" => $rfc8910_url,
);
echo json_encode($json_post, JSON_PRETTY_PRINT);
}
ob_flush();

return;
?>

I'm using this file for a month now.
The portal has become even more faster - and I discovered that not every device support rfc8910 yet, but the more recent Samsung devices will a real, well maintained Android OS also make use of it.
The low bud phones (= low bud, non maintained OS) : that's a mess, and will always be a mess (and who cares).

But the nice thing is : if the device doesn't use DHCP option 114 then nothings happens, and everything works just as it did before.
For the devices that support 114 : it's beautiful, as the portal detection on the device's end isn't needed anymore. The device will known where to go to visit the portal's access page as soon as DHCP negotiation finished. A 100 % KIS solution.

Hey, @stephenw10 : this code is tested, I'm using it right now. It's just one independent PHP file. No patching of other files is needed, I presume I have to add a feature request here.
For the record, 99 % of the credits go to @EDaleH.

stephenw10

@michmoor said in Captive portal - what am i missing:

Did i just need sleep?
Maybe staring at a problem fixed itself

Ha, well that can happen. I'd love to know what changed though. I guess something expired somewhere. Though you would have thought anything that could apply here would have already expired during testing.