That little browser in an ios device isn't actually a "browser" as such. They call it the "Captive Portal Assistant" (CPA) and it exists only to help one log in to a captive portal. The problem with ios devices is that they all want to see a certain web page within Apple before they will tell the user they have an Internet connection. Even if they actually have a connection.  That web site is http://www.apple.com/library/test/success.html You can browse to it- it just says the word success.  The way to eliminate a lot of ios/captive portal problems is to white list http://www.apple.com/library/test/success.html Some people take the easy way out and just whitelist apple.com This may not be your problem, but I thought I would toss this out.

I think I have added a "nohttpsforwards" checkbox to my test system.  At least it seems to work here.  Here is my description: Disable HTTPS forwards If this option is set, attempts to connect to SSL/HTTPS (Port 443) sites will not be forwarded to the captive portal. This prevents certificate errors from being presented to the user even if HTTPS logins are enabled. Users must attempt a connecton to an HTTP (Port 80) site to get forwarded to the captive portal. If HTTPS logins are enabled, the user will be redirected to the HTTPS login page.

NVM its fix as Jimp suggested from this post http://forum.pfsense.org/index.php/topic,57632.msg307926.html#msg307926. I think the Nas is sending wrong time. or its the device (an old nokia cell phone). here is a log when it happen. php: rc.prunecaptiveportal: Radius accounting debug: Start: 1386328206 Stop: 1386298766 Session time: -29440 after fix adding + line in /usr/local/captiveportal/radius_accounting.inc **  $session_time = $stop_time - $start_time; $session_time = ($session_time >= 0) ? intval($session_time) : 0;** setting it tp zero when unsigned acctsessiontime in sql no have zero. dont know if it is the same in db counters have to test it yet with account having time limit.

Check your FW Rules on that interface…..

thanks for the advice i think its only Max-Forever-Time is the one using "never" for the %s parameter other limit has good reply like Max-Daily-Time is "daily" for the %s counter parameter. Though have not tested bandwidth limit yet. I will test it sometime.

That happens when the captiveportal.inc function captiveportal_get_next_dn_ruleno() returns empty or is_null (the test is different in two different places.  Strange.) Sounds like your ipfw was out of pipes.  Not sure what the limit is.  64K?  32K? If it does it again you can: ipfw -x cpname list to see what the portal was doing.  You can use: ipfw_context -l To get a list of cpnames and the interfaces to which they are attached.

I have had a problem with squidguard. A wrong filter. It's solved.

This server provide internet for wireless users in the campus of the university , so i don't need users to put login information every time they try to go online .

Any suggestions?

@bassmoore: Hi, We have setup a captive portal page but it will only display when you enter a HTTP address. For example the idea is when they connect to a Free Wifi service they open Google Chrome they are met with the Captive Portal Page and then they press continue and they can browse the web. This works but only with HTTP addresses. E.g. when you open Http://www.google.com it shows the captive portal page but when you open https://www.google.com nothing happens! running 2.0.3 no more updates available. Thanks in advance!!! Check enable HTTPS login then https browsing will be redirected also. You need to setup your cert.

Not all were disconnected, there are those that still can and have an internet connection, and there are cannot connect anymore stuck on the captive portal page.

I've found the problem, though not the solution. The tablets are configured to connect to a https site, and CP redirects only access to port 80, not port 443, as mentioned here: http://forum.pfsense.org/index.php?topic=53630.0 For the tabelts that do work, I guess there's some background process that's communicating with a site via port 80, this allows CP to authenticate the MAC, so https access then works as expected.

Don't worry. This is something related to your setup only. Normally, the MAC shows up - I can see them for my clients that are connected to the portal interface. pfSense can show the MAC of the clients IF the client connects to the portal interface NIC. Often, this isn't the case if you put a router between the client and the portal interface. So: don't. Mostly, this is related to an AP that is setup as "AP and router" ….