An example from Google… [image: tp-link-bandwidth-control-1.jpg] [image: tp-link-bandwidth-control-1.jpg_thumb]

Ok i fixed it. The problem was depending from the fact that i thought the only firewall was "Selinux" (which i disabled), but there was another default firewall still on, so as soon i realize that, i disabled it and now it works, good job OOPF, thank you for helping yourself…. ;D

Maybe you misunderstood me: The captiveportal works fine with the css, if someone connect via interface. It just not load the css files if i watch the portal page over the pfsense webconfigurator. attached file: That "view" button i press. Files on pfsense: [2.3.1-RELEASE][root@fw.int]/root: ls -la /usr/local/captiveportal/ total 40 drwxr-xr-x  2 root  wheel  1024 Jun 30 13:42 . drwxr-xr-x  15 root  wheel    512 May 20 12:01 .. lrwxr-xr-x  1 root  wheel    39 Jun 29 15:23 captiveportal-bg.jpg -> /var/db/cpelements/captiveportal-bg.jpg lrwxr-xr-x  1 root  wheel    43 Jun 29 15:28 captiveportal-custom.css -> /var/db/cpelements/captiveportal-custom.css lrwxr-xr-x  1 root  wheel    44 Jun 29 15:24 captiveportal-fitlogo.png -> /var/db/cpelements/captiveportal-fitlogo.png lrwxr-xr-x  1 root  wheel    56 Jun 29 15:24 captiveportal-fontawesome-webfont.ttf -> /var/db/cpelements/captiveportal-fontawesome-webfont.ttf lrwxr-xr-x  1 root  wheel    57 Jun 29 15:24 captiveportal-fontawesome-webfont.woff -> /var/db/cpelements/captiveportal-fontawesome-webfont.woff lrwxr-xr-x  1 root  wheel    53 Jun 29 15:24 captiveportal-jquery-1.11.1.min.js -> /var/db/cpelements/captiveportal-jquery-1.11.1.min.js lrwxr-xr-x  1 root  wheel    45 Jun 30 13:42 captiveportal-success.html -> /var/db/cpelements/captiveportal-success.html lrwxr-xr-x  1 root  wheel    41 Jun 30 13:05 captiveportal-test.css -> /var/db/cpelements/captiveportal-test.css lrwxr-xr-x  1 root  wheel    49 Jun 29 15:27 captiveportal-uikit.active.css -> /var/db/cpelements/captiveportal-uikit.active.css lrwxr-xr-x  1 root  wheel    42 Jun 29 15:25 captiveportal-uikit.css -> /var/db/cpelements/captiveportal-uikit.css lrwxr-xr-x  1 root  wheel    45 Jun 29 15:25 captiveportal-uikit.min.js -> /var/db/cpelements/captiveportal-uikit.min.js lrwxr-xr-x  1 root  wheel    44 Jun 29 15:25 captiveportal-wa_logo.png -> /var/db/cpelements/captiveportal-wa_logo.png -rw-r--r--  1 root  wheel  10454 May 16 23:22 index.php -rw-r--r--  1 root  wheel  10434 May 16 23:22 radius_accounting.inc -rw-r--r--  1 root  wheel  6862 May 16 23:22 radius_authentication.inc  

Can you mention : The IP the "CP" of pfsense is using. The mask The DHCP range activated on the CP NIC. The IP your AP is using. The IP / Gateway / DNS the visitor(s) device(s) got from the DHCP server on pfsense (running on CP). Did you saw the DHCP log entries for this lease on pfsense (you should recognize the MAC).

Your login page is sane. The error page is just another login page though, so you'll go back to the login upon an authentication failure. Status>System logs, Portal Auth should show why authentication is failing.

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.