Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Captive Portal fails regularly after upgrading from 2.0.1 to 2.0.2

    Scheduled Pinned Locked Moved Captive Portal
    43 Posts 15 Posters 28.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D Offline
      debremarkos
      last edited by

      Hi I am having the same issue, upgraded from 2.0.1 (i386) to 2.0.2 in the services tap captive portal appears down. Interestingly I use radius and openldap for the username and passwords on a separate computer. When a user types in a username and password they get an error saying that page could not be reached, but then if they close the browser and open it they have been authenticated by captive portal and all is working. I am also using esx 4, I use squid (as transparent proxy) and squidguard and a wpad file to auto configure the browser. It all worked fine before the upgrade.

      1 Reply Last reply Reply Quote 0
      • E Offline
        eri--
        last edited by

        Please gitsync to latest changes i think the root cause of this has been fixed now.

        1 Reply Last reply Reply Quote 0
        • D Offline
          debremarkos
          last edited by

          yep did this and after a reboot everything works again, thanks for your help really appreciated.

          1 Reply Last reply Reply Quote 0
          • D Offline
            dgwilson
            last edited by

            @ermal:

            Please gitsync to latest changes i think the root cause of this has been fixed now.

            I updated (sync'd) again. Everything has remained stable over night.

            • David
            1 Reply Last reply Reply Quote 0
            • R Offline
              rhy7s
              last edited by

              I did a gitsync the other day and that fixed the captive portal being stopped issue. What I've noticed since though is that clients have to either renew their IP or turn WiFi Off/On to be redirected to the captive portal after the 1 hour time out. DHCP default and maximum lease times are not set in the configuration so I'm presuming they are 720 seconds and 86400 seconds respectively, both definitely longer than the time out.

              1 Reply Last reply Reply Quote 0
              • W Offline
                wwifi1944
                last edited by

                Same here >:(…upgraded and no more capitve po

                1 Reply Last reply Reply Quote 0
                • C Offline
                  cmb
                  last edited by

                  @wwifi1944:

                  Same here >:(…upgraded and no more capitve po

                  gitsync as described here and it will be fixed.

                  1 Reply Last reply Reply Quote 0
                  • M Offline
                    myke
                    last edited by

                    Hi everyone,

                    I confirm with the fix is working.

                    But i have some logs that i don't understand like :

                    lighttpd[34598]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'redirurl' (attacker '172.16.1.37', file '/usr/local/captiveportal/index.php')

                    lighttpd[34598]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'sessionkey' (attacker '172.16.1.141', file '/usr/local/captiveportal/index.php')

                    lighttpd[34598]: (connections.c.137) (warning) close: 73 Connection reset by peer

                    Best regards.
                    Myke.

                    1 Reply Last reply Reply Quote 0
                    • N Offline
                      niebla
                      last edited by

                      Using 2.02 in a production environment so I am reluctant to do a gitsync. I may come in this weekend and give it a try.

                      Interesting that although under service status the captiveportal service says Stopped captive portal is running and users are being asked to login.

                      1 Reply Last reply Reply Quote 0
                      • K Offline
                        kolomalo
                        last edited by

                        Hello.

                        I have the "same issue" Since I upgrade my installation, captive portal don't works as expected. I have had to disable it.

                        My problem is that the ip roules stop working suddenly.

                        f.e. my rule "both any->10.2.0.0/16" stop working and the only way to work around was enable certains IPs on the captive portal (so they have access to internet too, and i don't want this).

                        Thanks!

                        Now i'm gitsyncing.. I'll try after

                        1 Reply Last reply Reply Quote 0
                        • D Offline
                          debremarkos
                          last edited by

                          Hi after gitsyncing and going to 2.0.3 I had a number of other issues, such as under heavy load the firewall blocking everything with nothing entered into the syslog. we have 800 captive portal users and everything was working well in 2.0.1 . I have reverted back to 2.0.1 . The main reason was due to the crashing and the fact that the web gui became really slow, and crashed alot. I run 2 other pfsense devices and I have not gone back to 2.0.2 on them as they do not use captive portal. On all the devices that I have upgraded i have found the performance of the webgiu gets much worse after the upgrade with me having to remove the status widget from the dashboard to make some small improvements.

                          1 Reply Last reply Reply Quote 0
                          • N Offline
                            niebla
                            last edited by

                            Web GUI seems very fast with 2.02. Have not gitsynced yet. Is there a 2.0.3 release? I have not seen it.

                            1 Reply Last reply Reply Quote 0
                            • D Offline
                              debremarkos
                              last edited by

                              when you gitsync you will goto 2.0.3 pre release

                              1 Reply Last reply Reply Quote 0
                              • M Offline
                                m4st3rc1p0
                                last edited by

                                he is right is there any workaround, a lot of error message coming out. Also Captive portal is not working.

                                @debremarkos:

                                when you gitsync you will goto 2.0.3 pre release

                                1 Reply Last reply Reply Quote 0
                                • E Offline
                                  eri--
                                  last edited by

                                  The latest 2.0.3 is stable from our testing.
                                  Can you try because at the time there were some changes being done.
                                  Now it is marked as stable on our side!

                                  1 Reply Last reply Reply Quote 0
                                  • M Offline
                                    m4st3rc1p0
                                    last edited by

                                    heres the error i got

                                    Jan 31 19:57:20 	lighttpd[21213]: (connections.c.305) SSL: 1 error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
Jan 31 19:57:20 	lighttpd[21213]: (connections.c.305) SSL: 1 error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol

                                    @ermal:

                                    The latest 2.0.3 is stable from our testing.
                                    Can you try because at the time there were some changes being done.
                                    Now it is marked as stable on our side!

                                    1 Reply Last reply Reply Quote 0
                                    • H Offline
                                      heper
                                      last edited by

                                      yesterday i've deployed 2.0.3 with a ssl cert from startssl & Radius auth on a Win2K8r2

                                      i've seen that too:

                                      Jan 31 19:57:20 	lighttpd[21213]: (connections.c.305) SSL: 1 error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
Jan 31 19:57:20 	lighttpd[21213]: (connections.c.305) SSL: 1 error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol

                                      doesn't seem to affect the portal … i've had +40 portal users all day without complaints

                                      1 Reply Last reply Reply Quote 0
                                      • S Offline
                                        Slam
                                        last edited by

                                        Running latest snapshot of PRERELEASE-2.0.3 (31/01/2013)

                                        I can also confirm what the last 2 posters have reported, though it doesnt seem to affect the CP users.

                                        I am also seeing a lot of the following.

                                        Jan 31 20:23:57 lighttpd[18696]: (connections.c.137) (warning) close: 25 Connection reset by peer
                                        Jan 31 20:23:57 lighttpd[18696]: (connections.c.137) (warning) close: 25 Connection reset by peer

                                        Jan 31 20:02:55 lighttpd[18696]: (request.c.1133) GET/HEAD with content-length -> 400
                                        Jan 31 20:02:55 lighttpd[18696]: (request.c.1133) GET/HEAD with content-length -> 400

                                        Jan 31 19:56:03 lighttpd[18696]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'redirurl' (attacker '10.0.0.109', file '/usr/local/captiveportal/index.php')
                                        Jan 31 19:56:03 lighttpd[18696]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'redirurl' (attacker '10.0.0.109', file '/usr/local/captiveportal/index.php')

                                        Jan 31 17:55:50 lighttpd[18696]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'info_hash' (attacker '10.0.0.78', file '/usr/local/captiveportal/index.php')
                                        Jan 31 17:55:50 lighttpd[18696]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'info_hash' (attacker '10.0.0.78', file '/usr/local/captiveportal/index.php')

                                        Jan 31 17:35:49 lighttpd[18696]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'checklic' (attacker '10.0.0.74', file '/usr/local/captiveportal/index.php')
                                        Jan 31 17:35:49 lighttpd[18696]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'checklic' (attacker '10.0.0.74', file '/usr/local/captiveportal/index.php')

                                        1 Reply Last reply Reply Quote 0
                                        • E Offline
                                          eri--
                                          last edited by

                                          @heper:

                                          yesterday i've deployed 2.0.3 with a ssl cert from startssl & Radius auth on a Win2K8r2

                                          i've seen that too:

                                          Jan 31 19:57:20 	lighttpd[21213]: (connections.c.305) SSL: 1 error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
Jan 31 19:57:20 	lighttpd[21213]: (connections.c.305) SSL: 1 error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol

                                          doesn't seem to affect the portal … i've had +40 portal users all day without complaints

                                          That's just a warning because it tries to forward anything on tcp to port 80 which has been reduced only to tcp traffic on 2.1 version of pfSense.
                                          Since the client is trying an https://www.pfsense.org but the firewall redirection sends it to a simple HTTP talking webserver you get the warning.

                                          1 Reply Last reply Reply Quote 0
                                          • E Offline
                                            eri--
                                            last edited by

                                            @Abdsalem:

                                            Running latest snapshot of PRERELEASE-2.0.3 (31/01/2013)

                                            I can also confirm what the last 2 posters have reported, though it doesnt seem to affect the CP users.

                                            I am also seeing a lot of the following.

                                            Jan 31 20:23:57 lighttpd[18696]: (connections.c.137) (warning) close: 25 Connection reset by peer
                                            Jan 31 20:23:57 lighttpd[18696]: (connections.c.137) (warning) close: 25 Connection reset by peer

                                            Jan 31 20:02:55 lighttpd[18696]: (request.c.1133) GET/HEAD with content-length -> 400
                                            Jan 31 20:02:55 lighttpd[18696]: (request.c.1133) GET/HEAD with content-length -> 400

                                            Jan 31 19:56:03 lighttpd[18696]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'redirurl' (attacker '10.0.0.109', file '/usr/local/captiveportal/index.php')
                                            Jan 31 19:56:03 lighttpd[18696]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'redirurl' (attacker '10.0.0.109', file '/usr/local/captiveportal/index.php')

                                            Jan 31 17:55:50 lighttpd[18696]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'info_hash' (attacker '10.0.0.78', file '/usr/local/captiveportal/index.php')
                                            Jan 31 17:55:50 lighttpd[18696]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'info_hash' (attacker '10.0.0.78', file '/usr/local/captiveportal/index.php')

                                            Jan 31 17:35:49 lighttpd[18696]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'checklic' (attacker '10.0.0.74', file '/usr/local/captiveportal/index.php')
                                            Jan 31 17:35:49 lighttpd[18696]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'checklic' (attacker '10.0.0.74', file '/usr/local/captiveportal/index.php')

                                            There have been some more fixes after that specifically for this.
                                            Actually in general you will get better performance from 2.0.[2|3] than 2.0.1 since of a bug in php.

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.