Wrong captive portal login page redirection

oneohthree

Today I updated from 2.4.5 to 2.5.0 and captive portal service is not working properly. When some user requests a URL he/she receives a different IP as the login page. In this case I'm binding the LAN interface in a certain network to the portal, but what is offered is the WAN IP.

I tried removing and recreating the portal with no luck. I even deleted captive portal files manually in /var/db.

On this scenario everything is on VPNs and users can resolve names in a couple domains.

Gertjan

Hi,

@oneohthree said in Wrong captive portal login page redirection:

Today I updated from 2.4.5 to 2.5.0 and captive portal service is not working properly. When some user requests a URL he/she receives a different IP as the login page.

You are using the build in login page ?

@oneohthree said in Wrong captive portal login page redirection:

In this case I'm binding the LAN interface in a certain network to the portal, but what is offered is the WAN IP.

Portal users are non trusted users by default.
Best results will be obtained by placing a portal on a dedicated, OPTx, interface.
LAN stays for trusted only device.users.
This comes with another huge advantage : so easy to maintain, test and debug.

What do you mean by " LAN interface in a certain network" ?

@oneohthree said in Wrong captive portal login page redirection:

I tried removing and recreating the portal with no luck.

Shouldn't be needed.
I've upgraded myself 2.5.0, I use a captive portal for a hotel. No issue what so ever.

@oneohthree said in Wrong captive portal login page redirection:

I even deleted captive portal files manually in /var/db.

Files can deleted here (GUI) :

Why doing it different ?

@oneohthree said in Wrong captive portal login page redirection:

On this scenario everything is on VPNs and users can resolve names in a couple domains.

So two more possible issues :
VPN ... test your portal without VPN first. If all is well, portal ok, everything as expected, only then activate the VPN.

@oneohthree said in Wrong captive portal login page redirection:

users can resolve names in a couple domains

Your are using a DNSBL (pfBlockerNG-devel-latetest ?) ? Same thing applies : portal first. Then only with VPN. Then only with pfBlockerNG-devel-latetest. Then with both these options.

oneohthree

@gertjan said in Wrong captive portal login page redirection:

Hi,

Hi, and thanks for your reply.

You are using the build in login page ?

No, I'm using a custom HTML page, but I tried using the built-in one.

@oneohthree said in Wrong captive portal login page redirection:

In this case I'm binding the LAN interface in a certain network to the portal, but what is offered is the WAN IP.

Portal users are non trusted users by default.
Best results will be obtained by placing a portal on a dedicated, OPTx, interface.
LAN stays for trusted only device.users.
This comes with another huge advantage : so easy to maintain, test and debug.

What do you mean by " LAN interface in a certain network" ?

Answering the two previous questions. All the interfaces in my pfSense box are VLAN. The physical and only interface is used as the trunk. So, that "LAN" is a dedicated interface and another acts as the "WAN" interface to route the traffic.

So two more possible issues :
VPN ... test your portal without VPN first. If all is well, portal ok, everything as expected, only then activate the VPN.

By VPN I mean we are in a closed environment with no Internet access. The VPN is provided by our ISP.

Thanks!

Gertjan

@oneohthree said in Wrong captive portal login page redirection:

Answering the two previous questions. All the interfaces in my pfSense box are VLAN. The physical and only interface is used as the trunk. So, that "LAN" is a dedicated interface and another acts as the "WAN" interface to route the traffic.

Ok, got it.
As soon as that part works, you wind up using a classic WAN/LAN(s) setup.
VLAN us just an abstraction.

@oneohthree said in Wrong captive portal login page redirection:

By VPN I mean we are in a closed environment with no Internet access

Keep this in mind : Troubleshooting Captive Portal.

Some of them :
"DNS resolution not functioning" is the most known issue.
Lately, Apple devices using 14.x iOS have some logging issues as the iOS uses a RFC captive portal based method - and pfSense is still 'redircting web requests'. Opening a browser using a 'http' site will sort things out.
"The client has an HTTPS home page" That will never work, as no one want to break "https". The aforementioned RFC will solve that ones and for all.

Btw :

closed environment with no Internet access

So I guess yo have a limited number of users who understand this situation.
You could consider using a http (not https) direct link using a IPv4 address to your pfSense portal interface. And the correct port number, like 800x (see your pfSense for the number). This way you mitigate any DNS issues as DNS isn't needed for the portal to work.

Btw : exception for some voucher based functionalities, and an stupid old bug, the portal didn't really change in 2.5.0.

oneohthree

Hi agian, @gertjan

IMHO I don’t thinks it’s a DNS issue. Before updating users could use the form IP:8002 for authentication, or if they requested any other resource in their browsers without being authenticated, they were prompted for login using the right page.

Right now captive portal is not even showing logos or in my case not using CSS, JS or PNG files.

Gertjan

@oneohthree said in Wrong captive portal login page redirection:

use the form IP:8002 for authentication

That should always work , surely well if you do not use TLS (https).

pfSense uses the same test when you use :

Does that button work for you ?

@oneohthree said in Wrong captive portal login page redirection:

or if they requested any other resource in their browsers without being authenticated, they were prompted for login using the right page

Be carefull.
"http" (old port 80) web traffic is redirected.
No other traffic.
https traffic (port 443) can be redirected ..... with no-bad-no-good results. This is normal.

oneohthree

When I press "Live View" I can see the login page but with no images or CSS. Even using the default Netgate login page I can't see the logo.

So I decided to go back to 2.4.5 restoring my VM backup and everything is working as before.

Gertjan

@oneohthree said in Wrong captive portal login page redirection:

Then I press "Live View" I can see the login page but with no images or CSS.

That error description is not valid ;)
Why not using your browser to show you the source of the page, the 'htm' view of that page, so you can see the URL path of the CSS file and images.
You can see right away what wrong ....

I know my CSS is loaded, and the images show up.

ciidfrance

Hello All

I have same problem with captive portal.
I have create 1 usergroup with assigned privileges "user-services-captive portal login"
And add https://www.google.com url redirection after login but no redirection appear after login, just login page ok and blank page where is write "you are connected"

Any help appreciate

Gertjan

@ciidfrance said in Wrong captive portal login page redirection:

And add https://www.google.com url redirection after login but no redirection appear after login

pfSense 2.5.0 - right ??

Strange, as I'm using :

for years now.

It works

Btw : you uploaded your own "captive portal login page" ?
If so, what happens when you use the default, build in page ?

edit : oops.
I'm not using the build in User manager, but FreeRadius to identify users.
Using the local user manager, I'm not seeing "You are connected".
But "Succes".

Because (the logs tells a lot : Status > System Logs > System > GUI Service) I'm using a iPhone, and when connected to a Wifi network, it (the iPhone OS) throws out a test request over http (not https) to : http://captive.apple.com/hotspot-detect.htm

192.168.2.102 - - [10/Mar/2021:09:06:55 +0100] "POST /index.php?zone=cpzone1 HTTP/2.0" 302 0 "https://portal.local.net:8003/index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html" "Mozilla/5.0 (iPhone; CPU iPhone OS 14_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148"

I'll inspect this situation somewhat later on.

It does remind me of an identical issue that happens a year (or so ,) ago.
You'll find references - and a possible solution for it - in the forum.

edit :

The message

You are connected.

Is shown when, according the code :

	  /* If client try to access captive portal page while already connected, 
               but no custom logout page does exist and logout popup is disabled */

edit 2 :

At this line :
https://github.com/pfsense/pfsense/blob/0d8a927099acaa50479c2616265541bdeb6c27a9/src/usr/local/captiveportal/index.php#L110

Line 110 :
Paste this :

if (!empty($cpcfg['redirurl'])) {
		/* 2021-03-11 https://forum.netgate.com/topic/161673/wrong-captive-portal-login-page-redirection/10
		 According the GUI : 
		"After authentication Redirection URL - Set a forced redirection URL.
		Clients will be redirected to this URL instead of the one they initially
		tried to access after they've authenticated. */
		log_error("Zone: {$cpzone} - Captive portal : redirurl = {$orig_request}");
	$redirurl = $cpcfg['redirurl'];
}

It's a workaround.

The test is taken just a couple of lines above.
It's the third one that assigns the $redirurl in the GUI.
But if your browser was using a 'test http request' to detect the portal, it's this one that takes precedence : the second test - and that one nearly always 'wins'.
At least, for the Apple family, it does.
Sorry, can get my hand s on a samsung