|
||||||||
> We have 3 PFSense gateways running here performing NAT and really have no > firewall rules other then the defaults. They are P4-2.4GHZ machines with > 512MB of RAM. Currently they all issue DHCP and around 400 total broadband > clients flow through them evenly. It has been working flawless for many > months. We would like to enable captive portal to authenticate each user. Sounds good ;) > We use FreeRadius and Rodopi billing software. We setup a test gateway and > enabled captive portal using PFSense. We did not specify an idle timeout > or hard time. We enabled "re-authenticate user every 1 minute". We cannot > enable hard timeouts or idle timeouts for fear VOIP customers will get > sideways. So our only option is to re-authenticate every 1 minute in order > to terminate their service if they fail to pay their subscription. > Since the billing system only runs once per day to cut off users > (essentially just makes them absent in the RADIUS users file), is there a > way to change this 1 minute to 1 hour or 1 day? If so, would I be making > resource problems worse by forcing the gateway to track things longer? Yes, its a hidden option in the configuration (meaning you should backup your config, manually adapt it and restore the adapted config) <captiveportal> <croninterval>secondsblah</croninterval> othercaptiveportalblah </captiveportal> The minimum being 10seconds (everything less then 60seconds is not supported btw) and no upper maximum ;) > How many simultaneous connections do you think each box will handle? Good question, i've been wondering about this myself. It would be nice if people could sent there own experience. Offcourse it depends on the hardware itself and the re-authenticate interval. Without the 1minute re-authenticate interval quite alot i think. > Is there any set limit on how many connections can re-authenticate at one > time? I saw a post in October here that mentioned 50 but looked like > something was being added to "thread" the process it runs. Well, since threading is not that easy, its currently not implemented yet and I still would need to program code which splits up the tasks into various pieces. > > This setup in theory as well as the very small scale test we tried works > great. Were just worried what may happen shoving that many people out at > one time and don't really have a good way to find out other then "open the > gates". Unfortunately this will be the only way. Unless others can send in real-life based examples (they can sent it directly to me) > Any suggestions on how to set this up a better way? Not really, everything depends on your personal setup. > > Thanks in advance for any help! You welcome > J. -- Jonathan De Graeve M0n0wall Captive Portal Dev :) |