|
||||||||
Hi all, I am using PFSense 1.0.1 and the folks at PFSense suggested looking here for an answer to my Captive Portal problem. I have 3 PFSense gateways running Captive Portal with FreeRadius setup. We have one issue. It appears after about 15 users login, the rest of the users keep getting the portal page reloaded and not forward on to their origional URL nor anywhere manually tried after that. We see the user in our radius logs as "Login OK" and we see the "port #'s" climb up in the RADIUS server, but in the Status - Captive Portal - page, we see only around 9-10 IPs listed while the RADIUS server may show 30-40 recently authenticated. We can disable the portal, then the users flow through fine. Then quickly re-enable it and those same problem users will correctly authenticate and flow through while others that WERE working, start to have the refresh / trapped issue. Its almost like a maximum user limit but still random. Yesterday when testing we had around 28 logged in showing up in the status screen while the RADIUS server logs showed around 55 trying total. We have had this setup running on a test server with only 4 users running fine for 2 weeks.Also, to make it even worse to figure out, we cant duplicate this problem while the customer is on the phone having the issue. We can simulate a customer connection and flow out fine in almost every case. Here is the basics of our portal config: No Idle timeout No Hardtimeout Max Concurrent Connections (we have tried 0 for none, 16, and left blank) Authentication - Radius Re-Authenticate connected users every minute (then at someones suggestion, manually coded this to 360 seconds) All else defaults. On another note (in case this is a resource issue), we are using the re-auth feature because we are providing 24x7 service and dont want to restrict the users service. However, since we use DHCP, when the clients get a new IP, they are forced to login anyways again. Well, this will work for us fine if that is how it is to work by design. Can you confirm that please? If a user does not pay their bill, we wanted it to cut off their service asap. If that has to transpire 24 hours later (after a DHCP renew), that is fine by use and maybe will help this issue if its resource related. I ran a top on all the boxes and showed the CPU bored to death at 99% idle. These are p4-2.4GHZ / 512MB / 80GB SATA150 Dell boxes. Ugg help! Thanks Tim |