Captive Portal redirect after 2.4.5 update

brcisna

Hello All,

(Edit: realized I had posted this in Installation and upgrades forums . Sorry. Re-posting where this should have been posted initially.)

Netgate XG-7100 x 2

After upgrading both of our Netgate XG-7100 from 2.4.x to 2.4.5-RELEASE about two weeks ago the Captive Portal after clicking the 'continue' button does not redirection the the post authenticated URL that has always been used in the past. This is happening at two different physical buildings .
What happens is clicking on Continue button it just sticks there when you hit refresh you get the "You are already connected to internet" dialogue.
You have to close web browser and re-open web browser and internet is working fine. It simply does not proceed to the redirect URL. Have tried changing the redirect URL to something different and same results.

Adding. We are using a custom Captive Portal page and syntax looks very different than what is suggested in the Netgate documentation example for a custom captive portal page. This format is from about 10 years ago pfsense install. Is it possible a change in 2.4.5 may have killed this?

Thank You

Hope explained this well enough.

Gertjan

@brcisna said in Captive Portal redirect after 2.4.5 update:

You have to close web browser

A simple solution might be : and never use it any more. There are browser that are captive portal aware and do not want to get redirected. You "have to have" to see the browser home page.

That said, check if you see the same issue with the build in 'default' html page.
If the issue doesn't show up using the default 'pfSense' page, you have to repair your own page.

Make sure that at any time these lines exist in your file :

<form method="post" action="$PORTAL_ACTION$">
   <input name="auth_user" type="text">
   <input name="auth_pass" type="password">
   <input name="auth_voucher" type="text">
   <input name="redirurl" type="hidden" value="$PORTAL_REDIRURL$">
   <input name="zone" type="hidden" value="$PORTAL_ZONE$">
   <input name="accept" type="submit" value="Continue">
</form>

If you still have issue - also with the default page, do what I proposed in the other thread.
That will take care of things.

I'm not sure about what really happens, but as I insinuated above : browsers replace the redirect URL themselves, actually loosing the URL the browser was launched with.
In such a case, setting like :

doesn't matter any more : the browser goes where it wants to go, whatever you set for this settings in pfSense.

When you activate a connection, like plugging in a RJ45, or you select a SSID if your using Wifi, the (default) DHCP process takes place.
As soon as IP, mask, gateway and DNS are known, the OS launches a http (not https !!!!) request to a known URL. For Applle devices, this URL is http://captive.apple.com/hotspot-detect.html
Click on this link please and see what happens.

If you have a working connection, there answer will be a 'page' mentioning one text word : "Success". If the OS finds this one word on the return page, it knows it has a Internet connections and no more actions are needed. At least, it knows it can connect to other servers using port 80 - no other ports are probably tested.

If the page return isn't the word "Success" but something like :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> 
<html lang="fr-FR">
	<head>
		<title>My Captive Portal Demol</title> 
		.......
		......

it knows it's NOT connected to the net, and it warns the users. The exact behaviour is OS depended. It could launch a mini 'build in' browser - or shows a warning on the screen (Windows 7) etc;

As soon as you understood this, you understand that the captive portal facility isn't really a pfSense thing, but a thing of the an OS of your device.

This explains why, when I connect to the Wifi SSID of a pfSense captive portal, my phone shows the login page.
My phone (OS - right after finishing the DHCP stuff) didn't find the "Success" word-page, but something else, which is actually my pfSense login page.
It will launch a thing that looks like a "browser", or a real browser like Chrome, FF, using a http URL, like the one I mentioned above.

When you activate the captive portal fonctionality of pfSense, you actiavte :

a bung of firewall rules. Not to be mistaken with the firewall rules you see in the GUI, but another firewall, called ipfw.
One of its rules is

fwd 127.0.0.1,8002 tcp from any to any 80 in

this means : any traffic that want to go to any destination using port number 80 (a http web server port !) will redirected to 127.0.0.1, port 8002.
And guess who is listing at 127.0.0.1 (= localhost on pfSense) port 8002 ? The web server that shows the captive portal's login page.
This pfSense captive web server has a configuration settings that replaces the file part (after the third / in a http://www.somewhere.there.tld/page ) so 'page' will get replaced by

/index.php?zone=cpzone1&redirurl=$request_uri

where &cpzone is the captive portal instance - because more then one interface can be set up with a captive portal - and &redirurl will get set to the original $request_uri.
In my example, $request_uri will get set to "http://www.somewhere.there.tld/page" so that after successfully authentication, the browser get redirected (ones more ^^) to the final - initial "http://www.somewhere.there.tld/page" which now succeeds.

pfSense captive web server spits out the login page, that contains also your hand main html file. After posting to this page back, by filling in the user and password, and hitting "Continue" (I'm not going to detail html <form> stuff here) the html variables auth_user and auth_pass will be used to look for a match with an permitted pair. If found, the IP and MAC of your device are added to ipfw firewall rules, placed just before (!) the ipfw redirect rule shown above.
Any further traffic from your device at this point will pass through the ipfw firewall 'as if it didn't even existed'.

The last action, after it validated your user/password pair, and addng your device to the firewall, will be : it sends a redirect to your browser, so it goes to the $request_uri or "http://www.somewhere.there.tld/page"

Or : see my other post for what can happen with the 'redirect' info.

brcisna

Hi Gertjan,

Thank You for the good detailed explanation. With your advice i simply changed the 'post-authentication url' ,which has worked for several years,, to the 'pre-authentication url' clicked SAVE and all the clients are redirected to the correct specified URL.
Usually these things aren't this simple.

Thanks again

Gertjan

@brcisna said in Captive Portal redirect after 2.4.5 update:

With your advice i simply changed the 'post-authentication url' ,which has worked for several years,, to the 'pre-authentication url' clicked SAVE and all the clients are redirected to the correct specified URL.

Smart move.
Although you are using this as a feature it's actually, what I think, a bug.
What the "pre-authentication url" stands for and how it should be set up is shown in the manual.

I'll get back to this and/or find some old forum posts to detail out the situation.

jimp

It used to be that the post-auth URL was forced, no matter what the user entered. If the user tried to reach url A, they would instead be redirected to the post-auth URL. In 2.4.5 that appears to have changed to where the post-auth URL is only used if the user hits the portal URL directly and not via redirect.

What probably needs to happen is an option (on for upgrades, off by default) which forces the redirect URL to be used instead of the new behavior. That way both behaviors are possible. Some users required the old behavior, particularly hotels seem to need that.

The pre-auth redirect shouldn't be used for that kind of thing, and it may be a bug that it's working that way.

brcisna

@jimp Hi Jimp,

Thank You for the explanation. All I know is I am glad this is back to working transparently. This is ina production/school setting so very dynamic users as there are as many 'visitors' that were getting 'stuck' at the 'continue' button. You don't realize how many phone calls happen once this isnt working,even with the COVID-19 thing a school is like grand central station even in small town USA. Used to really enjoy figuring this kind of stuff out,,now,, i just like to do some clicks,,and it works. :)

Thanks again.