Any Change And Save Update Captive Portal Bug
-
When you change anything in CaptivePortal and save it, all users are hanging and bounced back to the login page. When logout is done, Failed gives setsockopt message. Is there a solution?
by the way; i applied https://redmine.pfsense.org/projects/pfsense/repository/revisions/8228ea91f44c3d9280e15306f00e0ebe8d0f5aa9
-
Hi,
Yep, probably true. I see the same thing.
This time the ipfw firewall rules are (still) destroyed, but the session stays present in captive portal SQLITE database : the user seems to be logged in but without ipfw rules they're hitting into the wall.Temporarily solution : Finish up you config, and don't change settings when users are connected ;)
-
Hi,
Yep, probably true. I see the same thing.
This time the ipfw firewall rules are (still) destroyed, but the session stays present in captive portal SQLITE database : the user seems to be logged in but without ipfw rules they're hitting into the wall.Temporarily solution : Finish up you config, and don't change settings when users are connected ;)
yeah I am doing it right now. I can not even touch it. a very annoying situation
-
Is there any update?
A lot of people who use the captive portal with pfsense running version 2.4.4 on my network are getting "auth success" and can not connect. They have a valid voucher. I have to disconnect all of them and then they can reconnect by typing in the voucher on more time. This procedure repeats every day. I would appreciate any solution or workaround. -
@streetsfinest said in Any Change And Save Update Captive Portal Bug:
are getting "auth success" and can not connect.
That's another 'bug'.
The issue you mention is already resolved. Do the 3 lines edit yourself, or better, use the patch package.
https://github.com/pfsense/pfsense/commit/c857583bb95d6d787b3334e5775cfd7921d547fb#diff-71474409c847a22d74a82a536ceaa04d -
Thank you very much for your fast response!
We have another issue with version 2.4.4-p1.
We use the voucher function to allow employees to connect to the guest wifi with private cellphones.Every employee has a voucher which is valid for 1 month. After one or two days or so, the employees getting the message below named "You are connected" and can not connect anymore:
I have to logout all the captive portal users to make the connection work again.
Is there any workaround available?Thanks in advance!!
-
We use the voucher function to allow employees to connect to the guest wifi with private cellphones.
Every employee has a voucher which is valid for 1 month. After one or two days or so, the employees getting the message below named "You are connected" and *can not connect anymore
This happens because something (manual action or automatic one) triggered a captive portal restart. As mentionned earlier in this thread, there is an issue when changing the settings of a captive portal while users are connected to it. The issue itself is located in how the captive portal does restart.
Did you updated your captive portal settings in the meantime? If no, did you updated other settings?
I am asking because i would lik to check why and when did the "captive portal restart" happened. It is not supposed to happens unless some settings are updated. I want to verify if you discovered a bug
-
Well i think this could be a bug because the only thing i did was to click the „disconnect all users“ button after getting this message above on the wifi devices. After clicking the disconnect button every user can join the wifi again by typing in the voucher one more time and will be redirected to the startpage. After some time they got the same message again and are not able to get access to the internet. Maybe i have to check the captive portal service if it is running all the time?
-
Problem still exists.
The only thing if have done is to change the default loginpage with a customized logo and i have removed the „user“ and „password“ field, because we only want to use vouchers.
Any ideas or workarounds? -
Could you post here anonymized captive portal logs?
-
Sure, there are some nginx issues on the system log page:
Dec 12 00:01:48 firewall01 nginx: 2018/12/12 00:01:48 [error] 97989#100444: *91840 limiting connections by zone "addr", client: 172.16.4.21, server: , request: "GET /generate_204 HTTP/1.1", host: "connectivitycheck.android.com"
Here are the captive portal logs:
Dec 12 11:33:54 check_reload_status Synching vouchers
Dec 12 11:33:54 logportalauth 83793 Zone: company_guest - Voucher login good for 486714 min.: fHwDGUrqxXr, ac:5f:3e:e0:7f:34, 172.16.4.23
Dec 12 11:33:54 logportalauth 83793 Zone: company_guest - CONCURRENT LOGIN - TERMINATING OLD SESSION: fHwDGUrqxXr, ac:5f:3e:e0:7f:34, 172.16.4.20
Dec 11 23:12:09 logportalauth 16935 Zone: company_guest - FAILURE: , dc:74:a8:4e:8d:b2, 172.16.4.17, Invalid credentials specified.
Dec 11 23:12:08 logportalauth 16935 Zone: company_guest - FAILURE: , dc:74:a8:4e:8d:b2, 172.16.4.17, Invalid credentials specified.
Dec 11 11:52:27 logportalauth 21468 Zone: company_guest - Voucher login good for 486999 min.: de2SdfsZB2p, fc:db:b3:d1:99:3b, 172.16.4.16
Dec 11 11:52:27 logportalauth 21468 Zone: company_guest - CONCURRENT LOGIN - TERMINATING OLD SESSION: de2SdfsZB2p, fc:db:b3:d1:99:3b, 172.16.4.10
Dec 11 10:58:22 logportalauth 61598 Zone: company_guest - Voucher login good for 489477 min.: bEYtpEZBvtX, 8c:f5:a3:1c:ab:7c, 172.16.4.18
Dec 11 10:58:22 logportalauth 61598 Zone: company_guest - CONCURRENT LOGIN - TERMINATING OLD SESSION: bEYtpEZBvtX, 8c:f5:a3:1c:ab:7c, 172.16.4.26
Dec 8 09:44:36 logportalauth 765 Zone: company_guest - Voucher login good for 491446 min.: de2SdfsZB2p, fc:db:b3:d1:99:3b, 172.16.4.10
Dec 8 09:44:36 logportalauth 765 Zone: company_guest - CONCURRENT LOGIN - TERMINATING OLD SESSION: de2SdfsZB2p, fc:db:b3:d1:99:3b, 172.16.4.23
Dec 8 00:30:20 logportalauth 764 Zone: company_guest - FAILURE: , dc:74:a8:4e:8d:b2, 172.16.4.12, Invalid credentials specified.
Dec 8 00:30:18 logportalauth 765 Zone: company_guest - FAILURE: , dc:74:a8:4e:8d:b2, 172.16.4.12, Invalid credentials specified.
Dec 6 23:04:31 logportalauth 765 Zone: company_guest - FAILURE: , b4:f7:a12c:4b, 172.16.4.27, Invalid credentials specified.
Dec 6 23:04:31 logportalauth 764 Zone: company_guest - FAILURE: , b4:f7:a12c:4b, 172.16.4.27, Invalid credentials specified.
Dec 6 19:23:00 logportalauth 764 Zone: company_guest - FAILURE: 0000, 60:1d:91:d7:1b:3c, 172.16.4.21
Dec 6 19:23:00 logportalauth 764 Zone: company_guest - 0000 invalid: Too short!
Dec 6 19:22:42 logportalauth 765 Zone: company_guest - FAILURE: 1234, 60:1d:91:d7:1b:3c, 172.16.4.21
Dec 6 19:22:42 logportalauth 765 Zone: company_guest - 1234 invalid: Too short!
Dec 6 19:21:54 logportalauth 764 Zone: company_guest - FAILURE: , 60:1d:91:d7:1b:3c, 172.16.4.21, Invalid credentials specified.
Dec 6 08:03:56 logportalauth 764 Zone: company_guest - FAILURE: , 00:ae:fa:52:83:f8, 172.16.4.12, Invalid credentials specified.
Dec 6 08:03:55 logportalauth 765 Zone: company_guest - FAILURE: , 00:ae:fa:52:83:f8, 172.16.4.12, Invalid credentials specified.
Dec 6 07:35:38 logportalauth 764 Zone: company_guest - Voucher login good for 496880 min.: bEYtpEZBvtX, 8c:f5:a3:1c:ab:7c, 172.16.4.26
Dec 5 15:26:13 logportalauth 764 Zone: company_guest - FAILURE: , 4c:4e:03:9d:f6:b9, 172.16.4.29, Invalid credentials specified.
Dec 5 14:55:09 php-fpm 764 /rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. ''
Dec 5 14:54:33 php-fpm 765 /rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. ''
Dec 5 08:21:38 logportalauth 765 Zone: company_guest - Voucher login good for 503958 min.: MZPM3AetRDm, 08:c5:e1:9c:dd:61, 172.16.4.15
Dec 5 08:21:38 logportalauth 765 Zone: company_guest - CONCURRENT LOGIN - TERMINATING OLD SESSION: MZPM3AetRDm, 08:c5:e1:9c:dd:61, 172.16.4.17
Dec 5 08:18:03 logportalauth 765 Zone: company_guest - Voucher login good for 496990 min.: fHwDGUrqxXr, ac:5f:3e:e0:7f:34, 172.16.4.20
Dec 5 08:18:03 logportalauth 765 Zone: company_guest - CONCURRENT LOGIN - TERMINATING OLD SESSION: fHwDGUrqxXr, ac:5f:3e:e0:7f:34, 172.16.4.15
Dec 4 11:22:42 logportalauth 765 Zone: company_guest - Voucher login good for 497108 min.: de2SdfsZB2p, fc:db:b3:d1:99:3b, 172.16.4.23
Dec 4 10:21:23 logportalauth 765 Zone: company_guest - FAILURE: , 04:1b:6d:a0:45:b6, 172.16.4.12, Invalid credentials specified.
Dec 4 08:22:51 logportalauth 765 Zone: company_guest - Voucher login good for 498443 min.: ePJmntaUt2X, e4:e4:ab:2f:07:60, 172.16.4.14
Dec 4 07:37:51 logportalauth 765 Zone: company_guest - Voucher login good for 497330 min.: tmujXFpT8sZ, c4:61:8b:24:51:65, 172.16.4.19
Dec 4 07:08:53 logportalauth 764 Zone: company_guest - Voucher login good for 498499 min.: fHwDGUrqxXr, ac:5f:3e:e0:7f:34, 172.16.4.15
Dec 4 07:08:43 logportalauth 765 Zone: company_guest - Voucher login good for 505471 min.: MZPM3AetRDm, 08:c5:e1:9c:dd:61, 172.16.4.17
Dec 4 07:07:07 logportalauth 764 Zone: company_guest - DISCONNECT: k8BZr7A7sEV, 8c:8e:f2:07:7d:fb, 172.16.4.20
Dec 4 07:07:07 logportalauth 764 Zone: company_guest - DISCONNECT: GU6GLUFjwNM, 8c:8e:f2:aa:db:c3, 172.16.4.21
Dec 4 07:07:07 logportalauth 764 Zone: company_guest - DISCONNECT: fHwDGUrqxXr, ac:5f:3e:e0:7f:34, 172.16.4.15
Dec 4 07:07:07 logportalauth 764 Zone: company_guest - DISCONNECT: KennQBNcSqb3, b8:76:3f:fc:b2:03, 172.16.4.25
Dec 4 07:07:07 logportalauth 764 Zone: company_guest - DISCONNECT: MZPM3AetRDm, 08:c5:e1:9c:dd:61, 172.16.4.22
Dec 4 07:07:07 logportalauth 764 Zone: company_guest - DISCONNECT: tmujXFpT8sZ, c4:61:8b:24:51:65, 172.16.4.19
Dec 4 04:41:31 php-fpm 69146 /rc.start_packages: Restarting/Starting all packages.
Dec 4 04:33:02 php-fpm 50501 /index.php: Session timed out for user 'admin' from: 10.10.11.45 (Local Database)
Dec 4 02:48:30 logportalauth 50501 Zone: company_guest - FAILURE: , b0:c1:9e:c2:9b:d0, 172.16.4.13, Invalid credentials specified.
Dec 4 02:48:28 logportalauth 50501 Zone: company_guest - FAILURE: , b0:c1:9e:c2:9b:d0, 172.16.4.13, Invalid credentials specified.
Dec 3 21:55:16 logportalauth 50501 Zone: company_guest - FAILURE: , 60:1d:91:d7:1b:3c, 172.16.4.11, Invalid credentials specified.
Dec 3 21:52:46 logportalauth 50501 Zone: company_guest - FAILURE: , 60:1d:91:d7:1b:3c, 172.16.4.11, Invalid credentials specified.
Dec 3 20:38:54 php-fpm 69146 /rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. ''
Dec 3 20:35:18 php-fpm 43420 /rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. ''
Dec 3 16:18:51 logportalauth 43420 Zone: company_guest - Voucher login good for 499344 min.: k8BZr7A7sEV, 8c:8e:f2:07:7d:fb, 172.16.4.20
Dec 3 15:46:28 logportalauth 69146 Zone: company_guest - Voucher login good for 515100 min.: GU6GLUFjwNM, 8c:8e:f2:aa:db:c3, 172.16.4.21
Dec 3 13:34:49 logportalauth 5945 Zone: company_guest - Voucher login good for 499553 min.: fHwDGUrqxXr, ac:5f:3e:e0:7f:34, 172.16.4.15
Dec 3 13:21:08 logportalauth 5945 Zone: company_guest - Voucher login good for 525317 min.: KennQBNcSqb3, b8:76:3f:fc:b2:03, 172.16.4.25
Dec 3 12:43:45 logportalauth 87218 Zone: company_guest - Voucher login good for 506576 min.: MZPM3AetRDm, 08:c5:e1:9c:dd:61, 172.16.4.22
Dec 3 12:35:29 logportalauth 87218 Zone: company_guest - Voucher login good for 498472 min.: tmujXFpT8sZ, c4:61:8b:24:51:65, 172.16.4.19
Dec 3 12:31:40 logportalauth 5945 Zone: company_guest - DISCONNECT: KennQBNcSqb3, b8:76:3f:fc:b2:03, 172.16.4.25
Dec 3 12:31:40 logportalauth 5945 Zone: company_guest - DISCONNECT: MZPM3AetRDm, 08:c5:e1:9c:dd:61, 172.16.4.22
Dec 3 12:31:40 logportalauth 5945 Zone: company_guest - DISCONNECT: fHwDGUrqxXr, ac:5f:3e:e0:7f:34, 172.16.4.15
Dec 3 12:31:40 logportalauth 5945 Zone: company_guest - DISCONNECT: GU6GLUFjwNM, 8c:8e:f2:aa:db:c3, 172.16.4.21
Dec 3 12:31:40 logportalauth 5945 Zone: company_guest - DISCONNECT: tmujXFpT8sZ, c4:61:8b:24:51:65, 172.16.4.19
Dec 3 11:08:24 php-fpm 5945 /index.php: Submission to captiveportal with unknown parameter zone: prod.nowplaying
Dec 3 11:08:14 php-fpm 69146 /index.php: Submission to captiveportal with unknown parameter zone: prod.nowplaying
Dec 3 11:07:01 logportalauth 69146 Zone: company_guest - FAILURE: company, 10:f1:f2:46:33:8b, 172.16.4.12
Dec 3 11:07:01 logportalauth 69146 Zone: company_guest - company invalid: TYPO illegal character (l) found in company !!
Dec 3 08:39:07 logportalauth 69146 Zone: company_guest - Voucher login good for 525600 min.: KennQBNcSqb3, b8:76:3f:fc:b2:03, 172.16.4.25
Dec 3 08:37:32 logportalauth 5945 Zone: company_guest - Voucher login good for 506822 min.: MZPM3AetRDm, 08:c5:e1:9c:dd:61, 172.16.4.22
Dec 3 08:36:26 logportalauth 69146 Zone: company_guest - Voucher login good for 499852 min.: fHwDGUrqxXr, ac:5f:3e:e0:7f:34, 172.16.4.15
Dec 3 08:36:21 logportalauth 5945 Zone: company_guest - Voucher login good for 515530 min.: GU6GLUFjwNM, 8c:8e:f2:aa:db:c3, 172.16.4.21
Dec 3 08:36:19 logportalauth 69146 Zone: company_guest - Voucher login good for 498712 min.: tmujXFpT8sZ, c4:61:8b:24:51:65, 172.16.4.19
Dec 3 08:28:23 logportalauth 69146 Zone: company_guest - Reconfiguring captive portal(Company_Guest). -
After one or t wo days or so, the employees getting the message below named "You are connected" and can not connect anymore:
When this happens :
- Are the users present in the Captive Portal status list of that zone ?
- Are the IP's of these user present in the two ipfw tables ?
-
@streetsfinest said in Any Change And Save Update Captive Portal Bug:
Sure, there are some nginx issues on the system log page:
Thanks ! When did the failure happened? I guess it was about today on the afternoon, right?
If yes, then i guess i got the idea of what happened
-
The failure happened today and actually every single day in the past. Whats your idea?
-
@streetsfinest said in Any Change And Save Update Captive Portal Bug:
The failure happened today and actually every single day in the past. Whats your idea?
I was thinking that the problem could come from check_reload_status
But i was apparently wrong -
@streetsfinest : any news on my questions ?
-
Sorry for the delay!
These are the users who are currently marked as active in the webconfig:172.16.2.19 c4:61:8b:24:51:65 tmujXFpT8sZ 12/04/2018 07:37:51
172.16.2.14 e4:e4:ab:2f:07:60 ePJmntaUt2X 12/04/2018 08:22:51
172.16.2.15 08:c5:e1:9c:dd:61 MZPM3AetRDm 12/05/2018 08:21:38
172.16.2.18 8c:f5:a3:1c:ab:7c bEYtpEZBvtX 12/11/2018 10:58:22
172.16.2.16 fc:db:b3:d1:99:3b de2SdfsZB2p 12/11/2018 11:52:27
172.16.2.23 ac:5f:3e:e0:7f:34 fHwDGUrqxXr 12/12/2018 11:33:54These are the entries on the shell:
[2.4.4-RELEASE][root@firewall01]/root: ipfw table all list
--- table(cp_ifaces), set(0) ---
em0.24 2100 6431485 3910816564 1544694662
--- table(company_guest_auth_up), set(0) ---
172.16.2.14/32 e4:e4:ab:2f:07:60 2006 82251 12132714 1544029688
172.16.2.15/32 08:c5:e1:9c:dd:61 2000 456811 105345127 1544204452
172.16.2.16/32 fc:db:b3:d1:99:3b 2008 110792 15084931 1544650234
172.16.2.18/32 8c:f5:a3:1c:ab:7c 2010 158374 17991642 1544565826
172.16.2.19/32 c4:61:8b:24:51:65 2004 266827 103579459 1544130687
172.16.2.23/32 ac:5f:3e:e0:7f:34 2002 56379 4834459 1544649475
--- table(company_guest_host_ips), set(0) ---
172.16.2.2/32 0 369100 92909044 1544694660
--- table(company_guest_pipe_mac), set(0) ---
--- table(company_guest_auth_down), set(0) ---
172.16.2.14/32 2007 118970 110192748 1544678486
172.16.2.15/32 2001 702015 859258240 1544639803
172.16.2.16/32 2009 168581 191962139 1544651420
172.16.2.18/32 2011 252903 328096547 1544629175
172.16.2.19/32 2005 265407 238158210 1544666548
172.16.2.23/32 2003 92898 127969742 1544650439
--- table(company_guest_allowed_up), set(0) ---
--- table(company_guest_allowed_down), set(0) ---[2.4.4-RELEASE][root@firewall01]/root: ipfw table company_guest_auth_up list
--- table(company_guest_auth_up), set(0) ---
172.16.2.14/32 e4:e4:ab:2f:07:60 2006 82251 12132714 1544029688
172.16.2.15/32 08:c5:e1:9c:dd:61 2000 456811 105345127 1544204452
172.16.2.16/32 fc:db:b3:d1:99:3b 2008 110792 15084931 1544650234
172.16.2.18/32 8c:f5:a3:1c:ab:7c 2010 158374 17991642 1544565826
172.16.2.19/32 c4:61:8b:24:51:65 2004 266827 103579459 1544130687
172.16.2.23/32 ac:5f:3e:e0:7f:34 2002 56379 4834459 1544649475
[2.4.4-RELEASE][root@firewall01]/root: ipfw table company_guest_auth_down list
--- table(company_guest_auth_down), set(0) ---
172.16.2.14/32 2007 118970 110192748 1544678486
172.16.2.15/32 2001 702015 859258240 1544639803
172.16.2.16/32 2009 168581 191962139 1544651420
172.16.2.18/32 2011 252903 328096547 1544629175
172.16.2.19/32 2005 265407 238158210 1544666548
172.16.2.23/32 2003 92898 127969742 1544650439 -
Thank you for trying to help me!
-
What the webconfig shows, is nothing more as the content of a local database with connected users :
They are :
172.16.2.14
172.16.2.15
172.16.2.16
172.16.2.18
172.16.2.19
172.16.2.23Both tables company_guest_auth_up and table company_guest_auth_down should also contain these same IP's. And they do.
There is another firewall, pf, which is fed with the GUI firewall rules for your portal interface.
Check out
ipfw list :01000 skipto tablearg ip from any to any via table(cp_ifaces) 01100 allow ip from any to any 02100 pipe tablearg ip from any to any MAC table(cpzone1_pipe_mac) 02101 allow pfsync from any to any 02102 allow carp from any to any 02103 allow ip from any to any layer2 mac-type 0x0806,0x8035 02104 allow ip from any to any layer2 mac-type 0x888e,0x88c7 02105 allow ip from any to any layer2 mac-type 0x8863,0x8864 02106 deny ip from any to any layer2 not mac-type 0x0800,0x86dd 02107 allow ip from any to table(cpzone1_host_ips) in 02108 allow ip from table(cpzone1_host_ips) to any out 02109 allow ip from any to 255.255.255.255 in 02110 allow ip from 255.255.255.255 to any out 02111 pipe tablearg ip from table(cpzone1_allowed_up) to any in 02112 pipe tablearg ip from any to table(cpzone1_allowed_down) in 02113 pipe tablearg ip from table(cpzone1_allowed_up) to any out 02114 pipe tablearg ip from any to table(cpzone1_allowed_down) out 02115 pipe tablearg ip from table(cpzone1_auth_up) to any layer2 in 02116 pipe tablearg ip from any to table(cpzone1_auth_down) layer2 out 02117 fwd 127.0.0.1,8003 tcp from any to any 443 in 02118 fwd 127.0.0.1,8002 tcp from any to any 80 in 02119 allow tcp from any to any out 02120 skipto 65534 ip from any to any 65534 deny ip from any to any 65535 allow ip from any to any
All these lines are actually easy to read :
Line 02118 (and 02117) will get hit if the the network connected user has no IP/MAC into one (or two) of the tables 02111 -> 02116.The login code places the IP/MAC into the tables company_guest_auth_down and company_guest_auth_up.
As long as these IP/MAC's are there, clients are not redirected to the captive portal by these firewall rules 02117/02118, except if they use the URL of the portal, something like
https://your.portal.net:800x?zone=company_guestCheck your logged in database and ipfw ones more, do an edit on the captive portal config page, and check both again.
You see what happens : tables company_guest_auth_down and company_guest_auth_up will be empty : people get redirected to the login portal (and can't login, because the database (== GUI Status => Captive Portal) considers them as logged in again.So, the get back to your issue : if both ipfw tables tables company_guest_auth_down and company_guest_auth_up contain teh IP/MAC of visitors, these visitors are not redirected to the login page. At least, not on behalf of pfSense.
Your issue is not related to the "config save => connected visitors logged out and can't re login" bug.
Show you "html login page" please.
-
There should not be another firewall in the network.
This is the current html login page:
<!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta http-equiv="content-type" content="text/html; charset=UTF-8" /> <title>Company Guest WLAN</title> <style> #content,.login,.login-card a,.login-card h1,.login-help{text-align:center}body,html{margin:0;padding:0;width:100%;height:100%;display:table}#content{font-family:'Source Sans Pro',sans-serif;background-color:#1C1275;background:linear-gradient(135deg, #1475CF, #2B40B5, #1C1275);-webkit-background-size:cover;-moz-background-size:cover;-o-background-size:cover;background-size:cover;display:table-cell;vertical-align:middle}.login-card{padding:40px;width:280px;background-color:#F7F7F7;margin:100px auto 10px;border-radius:2px;box-shadow:0 2px 2px rgba(0,0,0,.3);overflow:hidden}.login-card h1{font-weight:400;font-size:2.3em;color:#1383c6}.login-card h1 span{color:#f26721}.login-card img{width:70%;height:70%}.login-card input[type=submit]{width:100%;display:block;margin-bottom:10px;position:relative}.login-card input[type=text],input[type=password]{height:44px;font-size:16px;width:100%;margin-bottom:10px;-webkit-appearance:none;background:#fff;border:1px solid #d9d9d9;border-top:1px solid silver;padding:0 8px;box-sizing:border-box;-moz-box-sizing:border-box}.login-card input[type=text]:hover,input[type=password]:hover{border:1px solid #b9b9b9;border-top:1px solid #a0a0a0;-moz-box-shadow:inset 0 1px 2px rgba(0,0,0,.1);-webkit-box-shadow:inset 0 1px 2px rgba(0,0,0,.1);box-shadow:inset 0 1px 2px rgba(0,0,0,.1)}.login{font-size:14px;font-family:Arial,sans-serif;font-weight:700;height:36px;padding:0 8px}.login-submit{-webkit-appearance:none;-moz-appearance:none;appearance:none;border:0;color:#fff;text-shadow:0 1px rgba(0,0,0,.1);background-color:#4d90fe}.login-submit:disabled{opacity:.6}.login-submit:hover{border:0;text-shadow:0 1px rgba(0,0,0,.3);background-color:#357ae8}.login-card a{text-decoration:none;color:#222;font-weight:400;display:inline-block;opacity:.6;transition:opacity ease .5s}.login-card a:hover{opacity:1}.login-help{width:100%;font-size:12px}.list{list-style-type:none;padding:0}.list__item{margin:0 0 .7rem;padding:0}label{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-box-align:center;-webkit-align-items:center;-ms-flex-align:center;align-items:center;text-align:left;font-size:14px;}input[type=checkbox]{-webkit-box-flex:0;-webkit-flex:none;-ms-flex:none;flex:none;margin-right:10px;float:left}@media screen and (max-width:450px){.login-card{width:70%!important}.login-card img{width:30%;height:30%}}textarea{width:66%;margin:auto;height:120px;max-height:120px;background-color:#f7f7f7;padding:20px}#terms{display:none;padding-top:100px;padding-bottom:300px;}.auth_source{border: 1px solid lightgray; padding:20px 8px 0px 8px; margin-top: -2em; border-radius: 2px; }.auth_head{background-color:#f7f7f7;display:inline-block;}.auth_head_div{text-align:left;}#error-message{text-align:left;color:#ff3e3e;font-style:italic;} </style> </head> <body> <div id="content"> <div class="login-card"> <img src="captiveportal-logo.png"/><br> <h1></h1> <div id="error-message"> #PORTAL_MESSAGE# </div> <form name="login_form" method="post" action="#PORTAL_ACTION#"> <input name="auth_voucher" type="text" placeholder="Voucher Code"> <div class="login-help"> <ul class="list"> <li class="list__item"> <label class="label--checkbox"> <input type="checkbox" class="checkbox" onchange="document.getElementById('login').disabled = !this.checked;"> <span>I agree with the <a rel="noopener" href="#terms" onclick="document.getElementById('terms').style.display = 'block';">terms & conditions</a></span> </label> </li> </ul> </div> <input name="redirurl" type="hidden" value="#PORTAL_REDIRURL#"> <input type="submit" name="accept" class="login login-submit" value="Login" id="login" disabled> </form> </div> <div id="terms"> <textarea readonly>TERMS</textarea> </div> </div> </body> </html>
These are the current captive portal settings:
-
According to your settings you use the default, build in login page.
Check : "Use custom captive portal page" and compare the code html shown with your html .
The extremely important line :<input name="zone" type="hidden" value="$PORTAL_ZONE$" />
is missing in your html ....
-
Ah i got it!
I changed the settings like you write to me now:The new login page has the missing line now:
<body> <div id="content"> <div class="login-card"> <img src="captiveportal-logo.png"/><br> <h1></h1> <div id="error-message"> #PORTAL_MESSAGE# </div> <form name="login_form" method="post" action="#PORTAL_ACTION#"> <input name="auth_voucher" type="text" placeholder="Voucher Code"> <div class="login-help"> <ul class="list"> <li class="list__item"> <label class="label--checkbox"> <input type="checkbox" class="checkbox" onchange="document.getElementById('login').disabled = !this.checked;"> <span>I agree with the <a rel="noopener" href="#terms" onclick="document.getElementById('terms').style.display = 'block';">terms & conditions</a></span> </label> </li> </ul> </div> <input name="redirurl" type="hidden" value="#PORTAL_REDIRURL#"> <input type="submit" name="accept" class="login login-submit" value="Login" id="login" disabled> **<input name="zone" type="hidden" value="#PORTAL_ZONE#" />** </form> </div> <div id="terms">
I have disconnected all users and will test the new configuration!
Thank you very much! I will give you all a feedback if it works now. -
Wish you all a happy new year!
I would like to give you a short feedback:After adding the code:
<input name="zone" type="hidden" value="$PORTAL_ZONE$" />
in the custom login page it seems to work!
Thank you very much for your help.I have another question!
All of the employees use the vouchers for connecting to the guest wifi with private devices, but they have to type in the voucher every single day. This is very annoying for them. Is there any possibility to "save" the vouchers entries in the captive portal so that they do not need to type it in every single day? -
@streetsfinest said in Any Change And Save Update Captive Portal Bug:
but they have to type in the voucher every single day
Check your idle and hard time out values.
Visitors are thrown of the portal after "idle" time - and "hard" time.
They can reconnect, of course, if the credentials are valid. -
@streetsfinest said in Any Change And Save Update Captive Portal Bug:
Wish you all a happy new year!
I would like to give you a short feedback:After adding the code:
<input name="zone" type="hidden" value="$PORTAL_ZONE$" />
in the custom login page it seems to work!
Thank you very much for your help.That's actually super strange
I checked everywhere in the code, there is no references to
$_POST['zone']
.
This hidden input should have absolutely no effect on pfSense's Captive Portal in 2.4.XThis hidden input was used long time ago, but it's now an outdated string. Or at least it's supposed to be....
Maybe you spotted a new bug? -
@free4 said in Any Change And Save Update Captive Portal Bug:
This hidden input was used long time ago,
@free4 : He, ho -> time out ^^ : check out the very first line of the index.php file.
If the "zone" isn't defined, everything stops right away.
It's the mandatory parameter that makes it possible to support multiple captive portals on pfSense. -
@gertjan said in Any Change And Save Update Captive Portal Bug:
@free4 said in Any Change And Save Update Captive Portal Bug:
This hidden input was used long time ago,
@free4 : He, ho -> time out ^^ : check out the very first line of the index.php file.
If the "zone" isn't defined, everything stops right away.
It's the mandatory parameter that makes it ppfSenseossible to support multiple captive portals on .I know, but it's a
$_REQUEST
(so it can contain both GET and POST data)The problem is, that the first browser request to display the captive portal login form is a GET one, so if
cpzone=....
was missing in the URL, the login form woudn't even display. So i am sure that a GET parametercpzone
exists all the time during login process (if it didn't a blank page would be displayed instead, and an error message would appear clearly in the logs)anyway, doesn't really matter. Case closed, i guess.
-
@gertjan thanks for your answer!
In my opinion, if there is no value in the hard and idle timeout, it means that the users will not be disconnected. Is that right? I mean, what is the default time for those two options, if i leave it blank? I have not set those two options for now:
Should i set those options?
-
@streetsfinest check the validity time of your vouchers. You probably set up 1 day, so after 1 day all your users are disconnected. You can create vouchers with a much, much bigger validity time
If you need multiple validity times (1 day for guests and 30 for employees for instance), well you could create multiple rolls
-
-
Not setting an idle time and hard time out is "not recommended".
And remember the subject of this thread : if you re save the portal settings, your users will have troubles re connecting (firewall rule are flushed ...).
When using user/password or vouchers or then it is normal hat user have to retype their access credentials.
That's what happens what you give access to "untrusted users" on an trusted network (the portal).
If you trust your employees, consider using this :
on a seperate portal instance. -
@magokbas said in Any Change And Save Update Captive Portal Bug:
Hi,
Yep, probably true. I see the same thing.
This time the ipfw firewall rules are (still) destroyed, but the session stays present in captive portal SQLITE database : the user seems to be logged in but without ipfw rules they're hitting into the wall.Temporarily solution : Finish up you config, and don't change settings when users are connected ;)
yeah I am doing it right now. I can not even touch it. a very annoying situation
There is now a fix avaliable for this issue: https://forum.netgate.com/topic/137824/pfsense-no-internet-when-it-is-said-you-are-connected/13
-
Thank you for creating this patch!
Could you please explain how to install the patch?
I have tried to install via the patch installer: -
@streetsfinest said in Any Change And Save Update Captive Portal Bug:
Thank you for creating this patch!
Could you please explain how to install the patch?
I have tried to install via the patch installer:You need to add ".diff" at the end of the patch URL.
https://github.com/pfsense/pfsense/pull/4031.diff
Otherwise your settings seems good -
@free4
Ah okay!
Now i get the following information after testing:/usr/bin/patch --directory=/ -t -p2 -i /var/patches/5c32f2a9d342c.patch --check --forward --ignore-whitespace Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/src/etc/inc/captiveportal.inc b/src/etc/inc/captiveportal.inc |index 9b4856f774..b08bd350e0 100644 |--- a/src/etc/inc/captiveportal.inc |+++ b/src/etc/inc/captiveportal.inc -------------------------- Patching file etc/inc/captiveportal.inc using Plan A... Hunk #1 succeeded at 225. Hunk #2 succeeded at 233. Hunk #3 succeeded at 371. Hunk #4 succeeded at 391. Hunk #5 succeeded at 415. Hunk #6 succeeded at 563. Hunk #7 succeeded at 605. Hunk #8 succeeded at 698. Hunk #9 succeeded at 911. Hunk #10 succeeded at 967. Hunk #11 succeeded at 1101. Hunk #12 succeeded at 1219. Hunk #13 succeeded at 1234. Hunk #14 succeeded at 1683. Hunk #15 succeeded at 1706. Hunk #16 succeeded at 2208. Hunk #17 succeeded at 2431. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/src/etc/inc/globals.inc b/src/etc/inc/globals.inc |index 6d082a01d7..f1cc340192 100644 |--- a/src/etc/inc/globals.inc |+++ b/src/etc/inc/globals.inc -------------------------- Patching file etc/inc/globals.inc using Plan A... Hunk #1 failed at 69. 1 out of 1 hunks failed while patching etc/inc/globals.inc Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/src/etc/inc/upgrade_config.inc b/src/etc/inc/upgrade_config.inc |index 97fb3d6a3e..51398ca6cb 100644 |--- a/src/etc/inc/upgrade_config.inc |+++ b/src/etc/inc/upgrade_config.inc -------------------------- Patching file etc/inc/upgrade_config.inc using Plan A... Hunk #1 succeeded at 5921 (offset -13 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/src/usr/local/www/status_captiveportal.php b/src/usr/local/www/status_captiveportal.php |index bdfd441f5a..3963fd2ed5 100644 |--- a/src/usr/local/www/status_captiveportal.php |+++ b/src/usr/local/www/status_captiveportal.php -------------------------- Patching file usr/local/www/status_captiveportal.php using Plan A... Hunk #1 succeeded at 268. done ```java /usr/bin/patch --directory=/ -f -p2 -i /var/patches/5c32f2a9d342c.patch --check --reverse --ignore-whitespace Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/src/etc/inc/captiveportal.inc b/src/etc/inc/captiveportal.inc |index 9b4856f774..b08bd350e0 100644 |--- a/src/etc/inc/captiveportal.inc |+++ b/src/etc/inc/captiveportal.inc -------------------------- Patching file etc/inc/captiveportal.inc using Plan A... Hunk #1 succeeded at 227 with fuzz 2 (offset 2 lines). Hunk #2 failed at 237. Hunk #3 succeeded at 376 with fuzz 2 (offset 3 lines). Hunk #4 failed at 399. Hunk #5 succeeded at 1513 (offset 1091 lines). Hunk #6 failed at 1663. Hunk #7 failed at 1709. Hunk #8 failed at 1806. Hunk #9 failed at 1991. Hunk #10 failed at 2047. Hunk #11 failed at 2181. Hunk #12 failed at 2299. Hunk #13 failed at 2321. No such line 2773 in input file, ignoring Hunk #14 failed at 2770. Hunk #15 failed at 2793. Hunk #16 failed at 3295. Hunk #17 failed at 3505. 14 out of 17 hunks failed while patching etc/inc/captiveportal.inc Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/src/etc/inc/globals.inc b/src/etc/inc/globals.inc |index 6d082a01d7..f1cc340192 100644 |--- a/src/etc/inc/globals.inc |+++ b/src/etc/inc/globals.inc -------------------------- Patching file etc/inc/globals.inc using Plan A... Hunk #1 failed at 69. 1 out of 1 hunks failed while patching etc/inc/globals.inc Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/src/etc/inc/upgrade_config.inc b/src/etc/inc/upgrade_config.inc |index 97fb3d6a3e..51398ca6cb 100644 |--- a/src/etc/inc/upgrade_config.inc |+++ b/src/etc/inc/upgrade_config.inc -------------------------- Patching file etc/inc/upgrade_config.inc using Plan A... Hunk #1 failed at 5934. 1 out of 1 hunks failed while patching etc/inc/upgrade_config.inc Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/src/usr/local/www/status_captiveportal.php b/src/usr/local/www/status_captiveportal.php |index bdfd441f5a..3963fd2ed5 100644 |--- a/src/usr/local/www/status_captiveportal.php |+++ b/src/usr/local/www/status_captiveportal.php -------------------------- Patching file usr/local/www/status_captiveportal.php using Plan A... Hunk #1 failed at 268. 1 out of 1 hunks failed while patching usr/local/www/status_captiveportal.php done
-
@streetsfinest remove what's inside "patch content"
Then re-fetch your patch (i don't know wtf happened with your patch x) )
-
@free4
Done!
After that i got the same issue as i had before.
Could it be an issue with custom portal page? -
I'm seeing the same thing here.
I guess because @free4 is patching against pfsense:master (a futur "dev" version) and we are using 2.4.4-P1 ?
Thus files like
/etc/inc//etc/captiveportal.inc
/etc/inc/globals.inc
/etc/inc/upgrade_config.inc
/usr/local/www/status_captiveportal.php
are different. -
When you take
/etc/inc//etc/captiveportal.inc
/etc/inc/globals.inc
/etc/inc/upgrade_config.inc
/usr/local/www/status_captiveportal.php
from master (here it is : https://github.com/pfsense/pfsense )then all goes well : I can apply :But : updating these file can have 'nasty' side effects.
Make local copies of the original files, so you can go back if needed.edit : I did this : downloading master files from here : (example) : https://raw.githubusercontent.com/pfsense/pfsense/master/src/etc/inc/globals.inc
Before overwriting the original /etc/inc/globals.inc make a copie like cp /etc/inc/globals.inc /etc/inc/globals.inc.old
Do this for the other 3 files also.Then Fetch the patch.
Test the patch (should mark all ok in green : can patch and can revert).
Apply.Going back : Revert.
Delete /etc/inc/globals.inc
And move /etc/inc/globals.inc.old to /etc/inc/globals.incmv /etc/inc/globals.inc.old to /etc/inc/globals.inc
Same for the other 3 files.
Disable the portal.
Enable the portal
(last 2 steps are need for database re creation)For myself : i'm applying right now ^^
-
@gertjan said in Any Change And Save Update Captive Portal Bug:
I guess because @free4 is patching against pfsense:master (a futur "dev" version) and we are using 2.4.4-P1 ?
You are probably right
I'll have a look into it later