[ previous ] [ next ] [ threads ]
 From:  "Tim Roberts" <pfsense at dsslink dot net>
 To:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Captive Portal Refresh issue
 Date:  Sun, 11 Feb 2007 14:50:20 -0500
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!