Captive portal stuck at login page
-
An idea? anyone? :-\
-
Last image, last line.
In the URL I see the variable "/$PORTAL_ACTION$". This isn't normal at all, using (PHP) variables like this in an URL, that won't work. Check why it isn't replaced it actual value. -
What version of pfSense are you running ?
Does the logged in user appear in the captive-portal status and in the FreeRADIUS user database ? -
Last image, last line.
In the URL I see the variable "/$PORTAL_ACTIONS$". This isn't normal at all, using (PHP) variables like this in an URL, that won't work. Check why it isn't replaced it actual value.Yeah there's a broken custom portal page on the box. It's PORTAL_ACTION not ACTIONS.
-
What version of pfSense are you running ?
Does the logged in user appear in the captive-portal status and in the FreeRADIUS user database ?pfSense version 2.2.6 (last one), did happen with 2.2.5 and 2.2.4 though.
Users appears as logged at captive portal and RADIUS log file. -
@cmb:
Last image, last line.
In the URL I see the variable "/$PORTAL_ACTIONS$". This isn't normal at all, using (PHP) variables like this in an URL, that won't work. Check why it isn't replaced it actual value.Yeah there's a broken custom portal page on the box. It's PORTAL_ACTION not ACTIONS.
The image show $PORTAL_ACTION$ no $PORTAL_ACTIONS$ (custom portal page have been working fine since 2 years and haven't been changed). Don't know how this is treated by pfSense, but it seems that this is the normal behavior, at least for what is seen when everything works fine, client POST to /$PORTAL_ACTION$ and is redirected to the $PORTAL_REDIRURL$
-
Dude. Look at your TCP Stream captures:
POST /$PORTAL_ACTION$ HTTP/1.1
Host: 172.21.0.1:8004
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://172.21.0.1:8004/captiveportal-func_desktop.html
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 91
auth_user=XXXXXXXauth_pass=XXXXXXXXX&redirurl=%24PORTAL_REDIRURL%24&accept=LoginWhat is the user's browser supposed to do with POST /$PORTAL_ACTION$ HTTP/1.1 That should be referring to the portal IP address and port URL, not the text $PORTAL_ACTION$.
As has been said, your portal html is broken.
This is from view source of one of mine:
<form class="form-signin" method="POST" action="http://172.21.199.4:8004/">
You probably will see something like:
Which will never work because lighttpd has no clue WTF $PORTAL_ACTION$ URL is.
The POST should look like this:
POST / HTTP/1.1
Host: 172.21.0.1:8004</form> -
Dude. Look at your TCP Stream captures:
POST /$PORTAL_ACTION$ HTTP/1.1
Host: 172.21.0.1:8004
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://172.21.0.1:8004/captiveportal-func_desktop.html
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 91
auth_user=XXXXXXXauth_pass=XXXXXXXXX&redirurl=%24PORTAL_REDIRURL%24&accept=LoginWhat is the user's browser supposed to do with POST /$PORTAL_ACTION$ HTTP/1.1 That should be referring to the portal IP address and port URL, not the text $PORTAL_ACTION$.
As has been said, your portal html is broken.
Sorry but I disagree with you. URL and port is mentioned on "Host: 172.21.0.1:8004" and /$PORTAL_ACTION$/ is the web resource that is in the host. As far as I know $PORTAL_ACTION$ is a pfSense internal variable to handle some captive portal function. I really don't know how pfSense handle this kind of request (not a programmer) but I do know that under normal condition IT DOES WORK. You can check it with the screeenshot captive_portal-normal_condition01.PNG where client do a POST request to http://172.20.0.1:8004/$PORTAL_ACTION$ which is processed by pfSense and reply with a HTTP 302 Found status indicating the "Location" where web browser should be redirected.
As I can see, the problem comes after that, when client do a HTTP GET to http://www.example.com/~generalidades/utilidades/bridge_v2.php (of course this is just an example URL, at least the host part) and web server reply with a HTTP 302 Found status (redirecting again to captive portal page) instead of a HTTP 200 Ok.
I really don't think that custom captive portal page is the problem, as it been working ok for 2 years and it still does, and as I can see, pfSense doesn't seems to have problem to handle a POST request to /$PORTAL_ACTION$ web resource.
Pleas, point me out if I'm wrong with this (and where). -
The image show $PORTAL_ACTION$ no $PORTAL_ACTIONS$ (custom portal page have been working fine since 2 years and haven't been changed). Don't know how this is treated by pfSense, but it seems that this is the normal behavior, at least for what is seen when everything works fine, client POST to /$PORTAL_ACTION$ and is redirected to the $PORTAL_REDIRURL$
I could have sworn it was typoed in one of those screenshots, but on second look, apparently not. It is still a problem that it's in there that way though, what are the contents of your portal page?
-
Dude. Look at your TCP Stream captures:
POST /$PORTAL_ACTION$ HTTP/1.1
Host: 172.21.0.1:8004
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://172.21.0.1:8004/captiveportal-func_desktop.html
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 91
auth_user=XXXXXXXauth_pass=XXXXXXXXX&redirurl=%24PORTAL_REDIRURL%24&accept=LoginWhat is the user's browser supposed to do with POST /$PORTAL_ACTION$ HTTP/1.1 That should be referring to the portal IP address and port URL, not the text $PORTAL_ACTION$.
As has been said, your portal html is broken.
Sorry but I disagree with you. URL and port is mentioned on "Host: 172.21.0.1:8004" and /$PORTAL_ACTION$/ is the web resource that is in the host. As far as I know $PORTAL_ACTION$ is a pfSense internal variable to handle some captive portal function. I really don't know how pfSense handle this kind of request (not a programmer) but I do know that under normal condition IT DOES WORK. You can check it with the screeenshot captive_portal-normal_condition01.PNG where client do a POST request to http://172.20.0.1:8004/$PORTAL_ACTION$ which is processed by pfSense and reply with a HTTP 302 Found status indicating the "Location" where web browser should be redirected.
As I can see, the problem comes after that, when client do a HTTP GET to http://www.example.com/~generalidades/utilidades/bridge_v2.php (of course this is just an example URL, at least the host part) and web server reply with a HTTP 302 Found status (redirecting again to captive portal page) instead of a HTTP 200 Ok.
I really don't think that custom captive portal page is the problem, as it been working ok for 2 years and it still does, and as I can see, pfSense doesn't seems to have problem to handle a POST request to /$PORTAL_ACTION$ web resource.
Pleas, point me out if I'm wrong with this (and where).Fine. Disagree. Good luck. At best the $PORTAL_ACTION$ is tossed by lightppd and it serves up / instead. Regardless it doesn't belong there. When index.php is processing your HTML it is supposed to be replaced by the captive portal url:port and THAT sent to the user.
-
Dude. Look at your TCP Stream captures:
POST /$PORTAL_ACTION$ HTTP/1.1
Host: 172.21.0.1:8004
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://172.21.0.1:8004/captiveportal-func_desktop.html
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 91
auth_user=XXXXXXXauth_pass=XXXXXXXXX&redirurl=%24PORTAL_REDIRURL%24&accept=LoginWhat is the user's browser supposed to do with POST /$PORTAL_ACTION$ HTTP/1.1 That should be referring to the portal IP address and port URL, not the text $PORTAL_ACTION$.
As has been said, your portal html is broken.
Sorry but I disagree with you. URL and port is mentioned on "Host: 172.21.0.1:8004" and /$PORTAL_ACTION$/ is the web resource that is in the host. As far as I know $PORTAL_ACTION$ is a pfSense internal variable to handle some captive portal function. I really don't know how pfSense handle this kind of request (not a programmer) but I do know that under normal condition IT DOES WORK. You can check it with the screeenshot captive_portal-normal_condition01.PNG where client do a POST request to http://172.20.0.1:8004/$PORTAL_ACTION$ which is processed by pfSense and reply with a HTTP 302 Found status indicating the "Location" where web browser should be redirected.
As I can see, the problem comes after that, when client do a HTTP GET to http://www.example.com/~generalidades/utilidades/bridge_v2.php (of course this is just an example URL, at least the host part) and web server reply with a HTTP 302 Found status (redirecting again to captive portal page) instead of a HTTP 200 Ok.
I really don't think that custom captive portal page is the problem, as it been working ok for 2 years and it still does, and as I can see, pfSense doesn't seems to have problem to handle a POST request to /$PORTAL_ACTION$ web resource.
Pleas, point me out if I'm wrong with this (and where).Fine. Disagree. Good luck. At best the $PORTAL_ACTION$ is tossed by lightppd and it serves up / instead. Regardless it doesn't belong there. When index.php is processing your HTML it is supposed to be replaced by the captive portal url:port and THAT sent to the user.
I won't argue you as how pfSense handle this request, but how would be wrong if normally does work this way?
By the way, sorry if it bother you that I disagree with you, but isn't it that something that would be expected when discussing a solution for something? I mean, I thank you for your help, but it doesn't mean that I must agree with everything you say just as it is. Please, don't take it the bad way. -
@cmb:
The image show $PORTAL_ACTION$ no $PORTAL_ACTIONS$ (custom portal page have been working fine since 2 years and haven't been changed). Don't know how this is treated by pfSense, but it seems that this is the normal behavior, at least for what is seen when everything works fine, client POST to /$PORTAL_ACTION$ and is redirected to the $PORTAL_REDIRURL$
I could have sworn it was typoed in one of those screenshots, but on second look, apparently not. It is still a problem that it's in there that way though, what are the contents of your portal page?
Ok. The actual login page is a PHP file that detects if browser is a desktop or mobile one and redirect to a HTML file, which is uploaded directly on pfsense box by the file manager tab.
func_desktop.html.txt
func_index.php.txt
func_movil.html.txt
