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

    Captive portal random deaths

    Scheduled Pinned Locked Moved Captive Portal
    15 Posts 4 Posters 3.7k 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.
    • GertjanG
      Gertjan
      last edited by

      This guy:
      @carzin:

      Oct 26 15:21:30 lighttpd[32515]: (mod_evasive.c.183) 172.18.8.102 turned away. Too many connections.

      is it a client on the captive portal ?

      If so, its probably a case of a lousy written 'app' that doesn't understand what a 'portal' is and hammering your your portal. The portal send over a 'login page', the client (172.18.8.102) doesn't want that page, and keeps asking again and again …. up until 'no more resources' and PHP breaks.

      But, hey, that's just a thought. Can't remember well these issues with ancient versions ;)

      No "help me" PM's please. Use the forum, the community will thank you.
      Edit : and where are the logs ??

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

        @Gertjan:

        This guy:
        @carzin:

        Oct 26 15:21:30 lighttpd[32515]: (mod_evasive.c.183) 172.18.8.102 turned away. Too many connections.

        is it a client on the captive portal ?

        If so, its probably a case of a lousy written 'app' that doesn't understand what a 'portal' is and hammering your your portal. The portal send over a 'login page', the client (172.18.8.102) doesn't want that page, and keeps asking again and again …. up until 'no more resources' and PHP breaks.

        Yes, that would be a client. The fact the client connections limit is being met should prevent it from exhausting the PHP resources. But, that is along the lines of what I was thinking, except that something it was doing repeatedly caused PHP to crash rather than just run out of resources.

        1 Reply Last reply Reply Quote 0
        • C
          carzin
          last edited by

          All:  this box was running 2.2.4.  So I'm on the latest and greatest.  I've had this problem since we started using pfsense years ago, across multiple builds.

          1 Reply Last reply Reply Quote 0
          • GertjanG
            Gertjan
            last edited by

            It's probably not PHP. On a lower level you have this:

            Oct 26 15:21:33  kernel: sonewconn: pcb 0xfffff8002c506e10: Listen queue overflow: 193 already in queue awaiting acceptance (63 occurrences)

            Google FreeBSD + sonewconn (so you know that you are not the only one), try what the first link proposes.

            Other links will help you nailing down the process - port - etc.

            No "help me" PM's please. Use the forum, the community will thank you.
            Edit : and where are the logs ??

            1 Reply Last reply Reply Quote 0
            • C
              carzin
              last edited by

              I need some spoon feeding.  I am not a Linux guru.  From the searches, I ran the following command (netstat -Lan) and saw a bunch of:

              tcpX 0/0/128  which should tell me the queue size is 128.

              The instructions tell you to issue the command:
              sysctl kern.ipc.somaxconn=2048 and I get a readout of:

              kern.ipc.somaxconn:128 -> 2048

              However, when I run the netstat -Lan command again, it still shows a queue value of 128.  What else do I need to do?

              1 Reply Last reply Reply Quote 0
              • GertjanG
                Gertjan
                last edited by

                @carzin:

                I need some spoon feeding.  I am not a Linux guru.  …..

                It even worse, Linux is not FreeBSD (at all).

                Anyway, without putting my hands on your system, I can not explain why your identical pfSense is behaving differently as mine.
                Adapting the queues is just a counter measure because
                -> Your system can't handle the load (the queues are filing up without pfSense being able to handle it)
                or
                -> (so) analyze this 'load' … whats coming into your pfSense ? Is it the WAN , LAN ? other interface that is flooding ?

                Can you limit the number of user ?

                Can tcpdump tell you something ?

                What did you change from the default setup ?

                Note that I'm not a network expert neither, but these are the steps that I would take to dig up the problem.

                No "help me" PM's please. Use the forum, the community will thank you.
                Edit : and where are the logs ??

                1 Reply Last reply Reply Quote 0
                • C
                  carzin
                  last edited by

                  Well, there isn't much I can do to limit the users.  The pfSense virtual machines (4 of them) are what I use to authenticate users when they connect to a setup SSID and funnel them to the appropriate configuration website.  I use the DNS forwarding functionality to limit what they have access to after they connect.  So, I have no control over how the users connect, or really, how many connect.

                  I suspect I see a lot more load on my boxes than most of you.  At peak, I can have 100s of users connecting through at a single instance.  And the box works just fine with that load.  The pfSense death happens for apparently no reason, and is not generally associated with load.  Which is why I liked the idea of a 'bad client' basically beating the hell outta the server until it dies.

                  1 Reply Last reply Reply Quote 0
                  • GertjanG
                    Gertjan
                    last edited by

                    Just a thought.

                    You said:

                    Well, there isn't much I can do to limit the users

                    but you really 'nag' them with this:

                    I use the DNS forwarding functionality to limit what they have access to after they connect.

                    What I make of it:
                    The users device knows it is connected (there is a DNS server, a gateway) : the link seems up.
                    But may DNS requests will not receive a reply - or a wrong reply.
                    What does the 'app' doing with this situation ?? A request to resolve i.e. facebook.com will yield many retries because it 'won't work'.

                    So: use tcpdump incoming port 53 - protocol UDP and TCP to see if your DNS resolver get swamped …

                    => This is just an idea ....

                    No "help me" PM's please. Use the forum, the community will thank you.
                    Edit : and where are the logs ??

                    1 Reply Last reply Reply Quote 0
                    • C
                      carzin
                      last edited by

                      This is fun.  Another zone, different from the last time, died.  And this is in the syslog:

                      Nov 1 10:58:17 lighttpd[34493]: (connections.c.305) SSL: 1 error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
                      Nov 1 10:58:17 lighttpd[34493]: (connections.c.305) SSL: 1 error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
                      Nov 1 11:08:19 lighttpd[34493]: (connections.c.305) SSL: 1 error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
                      Nov 1 11:08:19 lighttpd[34493]: (connections.c.305) SSL: 1 error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
                      Nov 1 11:18:21 lighttpd[34493]: (connections.c.305) SSL: 1 error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
                      Nov 1 11:18:21 lighttpd[34493]: (connections.c.305) SSL: 1 error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
                      Nov 1 11:28:23 lighttpd[34493]: (connections.c.305) SSL: 1 error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
                      Nov 1 11:28:23 lighttpd[34493]: (connections.c.305) SSL: 1 error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
                      Nov 1 11:38:25 lighttpd[34493]: (connections.c.305) SSL: 1 error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
                      Nov 1 11:38:25 lighttpd[34493]: (connections.c.305) SSL: 1 error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
                      Nov 1 11:48:27 lighttpd[34493]: (connections.c.305) SSL: 1 error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
                      Nov 1 11:48:27 lighttpd[34493]: (connections.c.305) SSL: 1 error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
                      Nov 1 11:51:04 lighttpd[34493]: (connections.c.305) SSL: 1 error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
                      Nov 1 11:54:23 lighttpd[34493]: (connections.c.305) SSL: 1 error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
                      Nov 1 11:58:29 lighttpd[34493]: (connections.c.305) SSL: 1 error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
                      Nov 1 11:58:29 lighttpd[34493]: (connections.c.305) SSL: 1 error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
                      Nov 1 12:02:27 lighttpd[34493]: (connections.c.305) SSL: 1 error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
                      Nov 1 12:05:33 lighttpd[34493]: (connections.c.305) SSL: 1 error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
                      Nov 1 12:08:31 lighttpd[34493]: (connections.c.305) SSL: 1 error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
                      Nov 1 12:08:31 lighttpd[34493]: (connections.c.305) SSL: 1 error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number

                      1 Reply Last reply Reply Quote 0
                      • GertjanG
                        Gertjan
                        last edited by

                        Probably a client connection to a '443' (https) not using a https 'talk'.

                        No "help me" PM's please. Use the forum, the community will thank you.
                        Edit : and where are the logs ??

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