Captive Portal (too damn slow)

  • Hi All,

    A few years back I was a m0n0wall client but when I looked at pfSense, I get to be a fan of pfSense.

    In my corporate environment I installed a pfSense box (1.2-RC2, P4, 512MB RAM, 1 Intel NIC, 3 3Com NICs) that protects an Cable Internet connection, has a DMZ and a WLAN. This WLAN is used mainly by our visiting customers, the autentication is via RADIUS, and all works well except that loading the captive portal page and leaving it after auth is most of the times very slow, sometimes it seems that it will take forever.

    This box it's not on a heavy load (I can see it in the graphs) as I have about 150 users that only access the Internet trougth this box via a proxy, the machines use another default gateway.

    I've already searched this forums and found some similar problems, but it seems that this one keeps going on. I tested this with PCs, MACs, iPhone, whatever I could.

    Before I used another solution for this FW and I switched to pfSense mainly because of the Captive Portal thing, not to mention the other possibilities it offers.

    From your experience, should I try something diferent? 1.2-RC3? Try M0N0 instead?



  • Hi again,

    As no one seems to care or has any clue…

    Today I've upgraded my pfSense box to 1.2RC3, but the problem persist. Immediately after starting up with the new version everything seemed to work allwrigth, smoothly and quickly but now... everything back to where it was.

    I guess I'm going to test m0n0wall with the same configuration and see if it behaves well.




  • I also have had complaints about this from users. (portal login page slow to load)

    any Ideas

    please let me know if monowall has the same issue.


  • m0n0wall reportedly does not have the same slow page loads that some people run into. We haven't been able to duplicate it, even in some captive portal environments with hundreds of simultaneous users.

    If someone knows how to reliably replicate this, please let me know!

  • Hi All,

    Just a report back.

    My system is in production, so it means I can't do all the tests I would like to discover and help for a solution or debug the problem.

    What I can do is to add this information.

    I setup m0n0wall in the same way it was pfSense, same rules, captive portal with HTTPS. Both pfSense and m0n0wall had rules in the WLAN that didn't allow to reach in anyway both the DMZ and LAN. HTTPS Server Name was set to the name and domain of the firewall it self and certificate accordingly, m0n0wall was more responsive but it didn't do the job as expected. I also tried to use another name, that I configured in DNS Forwarder in hosts, but this didn't even work.

    One thing that I discovered in both pfSense and m0n0wall is that when you give to the HTTPS Server Name the name of your firewall itself, it resolves the IP by the one at the LAN interface.

    Another thing, I used the latest stable release of m0n0wall (1.231) and it seemed to me fastest performing in Internet access than pfSense, and in both I only have dnsmasq, lighttpd, dhcpd and bsnmpd services running.

    But then I tried a different approach and configured in Captive Portal, HTTPS Server Name, the IP of the WLAN interface, build a certificate accordingly and it seems to have solved the problem, it now is fast from all clients (PCs, MACs, iPhones).

    I didn't had the time to debug the problem so I'm not 100% sure this information is accurate, it worked for me, I hope it helps others, or helps to solve the problem, if it is one. Maybe is a configuration one? Not sure but it can be as m0n0wall didn't suit for me.

    Sorry for my english.

    If you do need some more information…



    PS: I'm now running pfSense 1.2 RC3

  • Yes, I have seen that as well.  Best practices is to enter the Ip address of the interface the captive portal is listening on.  I will commit a change to clarify this.

  • you means set the IP inside

    HTTPS server name?

  • @JAlexandre,
    You're using radius authentication right?.  Are you using the accounting?
    Try turning off the 'send radius accounting packets"

  • The original post mentions a 150 users. The web server in pfSense 1.2 lighttpd was optimized for a firewall and expectation of only 1 or 2 connections to the firewall.  Captive portal with 150 is needs more resources in order to work well with that number of users especially after the machine is rebooted and everyone tries to get back on all at once.

    Two things I have found that help it run much better.,8861.msg50280.html#msg50280,8878.msg51652.html#msg51652

    There have been changes to pfSense 1.3 that will make it account for the additional web server load when using captive portal.

  • I am having much problems with cp. I am unable to get it to load at all now.  I got it working ok a week or so ago but now nothing, the browser just times out.  Also when I click the link to view current page a new browser window pops up going to port 8000 but the page is blank.  I have uploaded over and over again but no change.

    Anyone have any ideas?

  • What version of pfsense are you using? Are you using RADIUS?  The more details the better.


  • Have you rebooted pfSense since you started having problems with captive portal? Or from the ''Restart webconfigurator" from the console.

  • @buraglio:

    What version of pfsense are you using? Are you using RADIUS?  The more details the better.


    Sorry bout that.

    Just figured it out though.  The page would not come up from the link because my mac was listed in the mac pass through.  The cp would not come up when trying to access the internet because I had not added any users yet to the user manager.

    Thanks for the response!  I appreciate it.

  • Cool.  Thanks for closing the loop.


Log in to reply