No, sorry. Once again, captive portals are broken by design as you've observed. And no, pfsense will not force any OS to launch a browser.

ok :) the problem is that I don't how to program it. Which language? bash? another way…is it possibile to open the users db and insert it directly? it should be more simple if possible.

Just to follow up, it was not the captive portal blocking webmail but the hosting company blocking traffic from the IP attached to the pfsense machine. Weird. They claimed too many unsuccessful login attempts to an email account.

Check the system, dhcp, and portal auth logs to see if there are any messages/errors at the time of the redirect. Sometimes that can happen if you have the portal's hard timeout set longer than the DHCP lease time and it can't properly re-use the sessions.

You should not just "view source" of the portal page, edit it, and then upload it. In doing so, the page loses some important internal macros. You should edit the original modified source, or attempt to "fix" the tags that were lost. See the sample code for a default portal page to see what those are, things like <form method="post" action="$PORTAL_ACTION$"> and and other such things that may have been used.</form>

@ermal: It is better to use the php commands to do the disable rather than the not correct shell commands provided here. Take a look at what happens when you click enable/disable button on the CP configuration page. Another easy way to do it would be tojust leave captive portal running and insert/remove a rule (using the IPFW command) to skip the portal rules.

another thing to check: if your external database is on a hosted server, make sure that you are allowing connections from your pfsense IP address. e.g. in Control Panel (on your hosted server) go to Databases -> RemoteMySQL and enter the allowed host IP or domain name

If you want seamless authenticated access, use PPPoE to connect to pfSense instead of a captive portal.

sorry ,i don't found it !

Dude, your RADIUS server is just completely off-topic here. Start a new thread.

Yes, you have to manually edit the values in /etc/inc/radius.inc. They're easy enough to spot - if you're not comfortable with command-line just use Diagnostics > Edit file. Look for a line like the following… function addServer($servername = 'localhost', $port = 0, $sharedSecret = 'testing123', $timeout = 3, $maxtries = 2) I've not yet got to the bottom of my problem - increasing the timeouts has not fixed it for me. Unfortunately I've had little time to look into it further, and it's always in use so access is tricky.

This depends entirely on the client OS, not the firewall/captive portal.

Hello, We are currently running version pfSense-2.0.1-RELASE (which does have the "no authentication" radio button),,,,but more,,, wanted a "TOS" or "disclaimer"  to be displayed to our likeing, which wallabybob,,supplied. thanks, Barry

My initial thought is that, with some careful firewall rules, you might be able to use the same IP address for all your CP instances since they are differentiated by port numbers. I do know the ipfw rules initially fwd's CP traffic to 127.0.0.1:8XXX.  There would probably need to be some customization to make the httpd always use the same source address for all CP instances in its replies. That or forget about the DNS forwarder and put ISC BIND up instead.  You could easily make it return the correct A record based on the IP address of the resolver making the query. Or a wildcard cert. Or separate FQDNs/certificates for each CP instance.  Check out www.startssl.com.

Your pre-auth page needs a button or link to redirect -back to- the CP page, http://x.x.x.x:8000/index.php At that point they login to the CP auth page as normal.