No.

I just suggest that you shouldn't 'code' a solution that doesn't work an "any visitors device".
This means basically : keep it simple - and don't do what you self don't what to see elsewhere.

One other thing:

pfSense 2.3.1 i386

my CP custom login page no longer works unless I remove, the information that you said is needed -
$PORTAL_ACTION$
$PORTAL_REDIRURL$
$PORTAL_ZONE$

none of the above variables work.

eg:

<title>C-NAME Wireless Internet Access Point</title>  ## C-NAME Wireless Internet Access Point Welcome! Please supply **Either** your Username & Passowrd **Or** your Voucher Number below. <form method="post" action="$PORTAL_ACTION$"> | **Username:** | | | **Password:** | | | **Voucher Number:** | | |   | |     | </form>

this is the code that works:

<title>C-NAME Wireless Internet Access Point</title>  ## C-NAME Wireless Internet Access Point Welcome! Please supply **Either** your Username & Passowrd **Or** your Voucher Number below. <form method="post" action="http://10.10.1.1:8002/index.php?zone=C-NAME"> | **Username:** | | | **Password:** | | | **Voucher Number:** | | |   | |     | </form>

Please fix this problem.

@solidus:

Yes of course, I understand that this is a very serious issue

So, if someone has an https home page set and is not sufficiently smart to change the https into an http at the beginning of the URL, what could be a simple solution/workaround?

Well ….
A visitor that want to have the page https://www.google.com instructs his browser that he want to see https://www.google.com - and nothing else - no matter what.
That's what https (ssl) is known about. It guarantees this need.
It doesn't need much thinking that other destinations or ruled out. If the connections gets incercepted (redirected), the returned certificate will NOT say its "google.com" but "myportal.net" => the browser will jell.
So, the visitor will start to understand that something is up ...
He should know that he is behind a "captive portal" (more and more people are using this kind of Internet access more and more.
The captive portal login page isn't, of course "https://www.google.com" so ....

Basic rule : a connection should be build before secure connections are possible.
With others words : use http://..... first and if ok, use https://.....

@solidus:

How much is feasible to put in the DNS resolver configuration, maybe using the "domain override" option, a domain like "log.me" that triggers the captive page?
DOMAIN : log.me    –--  IP Address : pfsense LAN IP

It would be easy to say to someone that is blaming browsing issues to digit "log.me" in the browser address bar

;D
This has been done already. Search the forum (nad pfSEnse doc) for the examples.
Instruct the local DNS that log.me == the IP of the Captive portal and your close.

ah now thats service! TYVM i will look forward to the new release.

You're very welcome.  I love you guys!  Keep up being awesome.

:-[
Anyone having preauth page working so that users are force to see a splash page and then they can click a button on that splash page to continue to the captive portal login? Please share. Thanks a lot.

@Gertjan:

Also:
Read carefulle what's being idicated at the bottom of this page :
ServicesCaptive => Portal => => Configuration

It's something like:

Don't forget to enable the DHCP server on the captive portal interface! Make sure that the default/maximum DHCP lease time is higher than the hard timeout entered on this page. Also, the DNS Forwarder or Resolver must be enabled for DNS lookups by unauthenticated clients to work.

I've already checked, this is fine.

Instead of pay for it I can do it myself,

My intention was to do something like this as standard in further versions of pfSense, to give developers idea to improve Captive Portal.

Problem will be if I upgrade pfSense into next version probably I will lose my functionality and again and again with the next versions.

:D :D :D :D

great job as always by the  pfsense´s team

Looking at theese two log entries…. "attached below"

one of them says the voucher is alredy used and expired... and the other only says... invalid!!!, that followed by a session termination..

that made me think about the public and private keys...
I went there on the gui...

"-----BEGIN RSA PRIVATE KEY-----
MDECAQACBgDG9Vr4pQIDAQABAgYArr0AE+ECAw8vLQIDDRpZAgMJXYkCAwo8SQIDBnzA
-----END RSA PRIVATE KEY-----"

"-----BEGIN PUBLIC KEY-----
MCEwDQYJKoZIhvcNAQEBBQADEAAwDQIGAMb1WvilAgMBAAE=
-----END PUBLIC KEY-----"

"as you can see...  I have a shorter key.... that was no problem before"...

I found that there were spaces at the end of each key... I deleted them (spaces)
I also found that on the private key it was like this :

"-----BEGIN RSA PRIVATE KEY-----
MDECAQACBgDG9Vr4pQIDAQABAgYArr0AE+ECAw8vLQIDDRpZAgMJXYkCAwo8SQI
DBnzA
-----END RSA PRIVATE KEY-----"

there is a  "RETURN" difference with this private key... and the one above.... It was like this... and I deleted the "return" and saved voucher settings... vouchers are still working after the changes, I rebooted the firewall... it seems no session was expired other that the ones that were supposed to...

I have a good feeling about this being the problem.... what do you think?

I also want to mention Issue number two.... which I'll have to wait for another hard reboot to see if it's still happening (I don't want to cause a hard reboot manually) Id rather wait...
thanks again


Never heard that solution.
As far as I know (which ain't that much) : the captive portal part isn't written so it permit you to put in a 'load balancer' option.
Faster, easier scalable is : more pfSEnse boxes and thus more separated "hotspot" zones.

With some 'correct' hardware pfSense can handle several thousand of logged in users - that has been seen before. Ones logged in, the load is close to nothing, the only issue will be 'how big is your WAN'.
Keep your login html simple.

Another issue : very recently (a couple of weeks ago), pfSense started to use a new web server : nginx. Captive portal settings for this server are pretty basic, and not much is know (yet) about optimizing etc.

Tomhas - your original post also reveals the quality of the questions on this forum - namely that they're being posted by some people who haven't wit enough to provide even the most elementary information for anyone to help them. Saying "my firewall is broke" is going to get you nowhere in a hurry, nor will insulting anyone who even responds to ridiculous posts like these. My point was to highlight the fact that you have to provide at least a tiny amount of information if you want help. You now can count on at least one less person who might be able to offer you any assistance. Well done.

Hi!!!
What is your Captive portal set up___???

if you want all users to be disconnected after 120 minutes… I think you should go like this...

reauthenticate users every minute should be disabled (that's below radius options), and set the hard time out to 120 minutes...

120.JPG
120.JPG_thumb

No. The vouchers are generated mathematically based on a cryptographic algorithm.

You might be able to do what you want by rigging up something with RADIUS authentication pulled from a database like you want, but that's outside the scope of pfSense.

You can select 'Host name' from the drop-down list marked 'Display' in the traffic graph. User names, no.

Or 8.8.8.8 not being passed by the captive portal config.