@valnar:

Google 'thin clients'

Ok, I merited that one :)

I figured it out. The accounting interface under FreeRADIUS was missing.

Just updating this thread in case it helps someone else

Removed adjusted DNS Settings in DHCP Server for that interface

Entered Norton ConnectSafe IP in System ->General Setup under DNS Servers
Doesn't matter the order of DNS Servers

DNS Resolver -> under DNS Query Forwarding, check 'Enable Forwarding Mode'

BTW, I'm running PF 2.3.4 and using Norton because OpenDNS does not support DNSSEC

Cheers and thanks
Stinkfly

If you have the same error, as someone did 3 years ago:

Update to the latest stable. The webserver 'lighttpd' hasn't been in use for some time now.

@sluggo:

I notice that your https enabled portal's subdomain "portal.brit-hotel-fumel.net" DNS does not resolve to an IP - maybe this indicates the misunderstanding on my part.

That's one of the good side effects when using certificats.
Certificates have to have a "DNS" or host + qualified domain name - at least, those from Encrypt have.
When visiting my portal, there can't be an IP like the 'http' access. The settings impose a "HTTPS server name" and this name must be part of the certificate.

@sluggo:

Our server's WAN IP is pointed to by a subdomain using a valid wildcard certificate (CN = *.domain.com) for both GUI and portal.  I assumed PFsense host name (subdomain.domain.com) had to be a valid, internet accessible FQDN and had to be same as captive portal's "https server name" when using https portal.  Maybe the wildcard cert is the problem?

Remember : cert validation is done by the browser you use.
I chose to use a cert for my portal for my clients  portal living on OPT1 or 192.168.2.1 and one for pfsense (192.168.1.1). Pfsense is handling the renewing

@sluggo:

Strange that iOS devices "think" that they have internet (as shown by WiFi icon) when they do not.  This would suggest that they are able to receive the CNA's GET request (from cached DNS?) while un-authenticated behind captive portal.

Never have equipment think for you  ;)

Apple devices throw out a GET "http;//captive.apple.com/hotspot-detect.htm" and this should return a "200" status code. Also known as "all is well - here is the page", and the page will be returned by the server at "apple.com". Then the device knows it has an connection- at least, using a 'random' WAN destination with the "80" port.

You can see if your device is listed in the captive's portal firewall - which means: it can go through. See here : https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting
Your device will be listed when you correctly identified yourself first. https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting is a bit technical, but very instructive.

VERY IMPORTANT : many people break the functioning of the captive portal because DNS isn't working.
Even when the captive portal blocks all communication, DNS should work for every device. Identified, or not.
because, before even trying to hit "apple.com" (in this case) the "apple.com" has to be resolved to an IP. Then the GET is executed. If Apple.com isn't resolved, everything stops.
This means that you probably should have a pass rule on the captiv's portal fGUI firewall that let DNS requests coming in - and that a DNS server is running on pfsense - the same interface. Normally, your DHCP server running on pfSense hands over the address of the DNS server your clients / visitors should use.

Btw : the wifi icon on a iDevice doesn't mean you have a connection to the net.
It means that there is a "radio connection" (== also called wifi connection) activated to an access point - and the iDevice obtained an IP. It doesn't mean at all that this AP gives you a connection to the net. Upstream the connection can be blocked, like a captive portal does at first.

These explanations aren't just valid for apple device, but for all devices.

So just checked a few more things, definitely only works remotely with FQDN, certs, https enabled in CP, appropriate firewall rules and no NAT to CP client interface address (as we were used to in past).  Captive portal is now secure after clearing browser cache in Chrome.

Perhaps this should be noted in captive portal form notes in GUI, as anyone working with portals typically needs to test them from the internet, not just from client LAN.

"Concurrent user logins" set to 1 (one) isn't working for you ?

@jimp:

@cyberlocc:

I am aware of that. Not really what I am trying to do however.

It's exactly what you're trying to do.

@cyberlocc:

Okay so atm, I am doing that, and that works. However, that leads them to a PFsense login screen, where normals get confused, and a bunch of nav for things they cant access anyway.

I dont want all that, its not needed, and it just confuses less techie people.

If you only assign them the permission for the password change page, they get that page when they login, and nothing else. The menus are irrelevant and they're empty anyhow, if not hidden.

@cyberlocc:

They now see the PFsense logo, and now I am running PFsense and can begin trying to break in, with that somewhat helpful knowledge.

So? If you follow proper practices, that gives them nothing.

@cyberlocc:

They are allowed Full GUI access on the Guest Lan, so they can begin to try and brute force into the networks admin account.

The GUI has anti-brute force protection. If they try 15 times unsuccessfully, they are locked out of the GUI for an hour (minimum).

@cyberlocc:

So what I am wanting to do, is deny access to the GUI from the Guest Lan, and have the 1 Password change screen, be added through some type of Iframe, or even just a data entry method from Captive portal screens would actually be better. So once they are logged in, they have the ability to edit their account on the logout page.

You can't deny access to the GUI and then allow access to the GUI through an iframe. That is not possible, since their browser must reach the GUI to access any pages served by the GUI.

What you're describing would involve setting up a second web server on the firewall for just that one task, and would likely have less security than just using the firewall directly.

If you don't like how it's already handled in the GUI, then use RADIUS authentication off the firewall and then use whatever user/password management pages are provided by the authentication server software.

If your users are confused by the pfSense logo, then you need to give them better instructions.

Well using the PHP commands, they wouldn't need access to the GUI would they?

Also, you said if they are not hidden. That would be a very good start for me right there, I have read that is possible still trying to locate how. It was said in other threads it was doable, but the links to how are broken.

@mdes:

….
Image is not showing. Why? Image is stored in /var/db/cpelements/
What's the document root of web server running captive portal at 8002 port?

Run this one :

cat nginx-*-CaptivePortal.conf | grep 'root '

Over there (btw : /usr/local/captiveportal  ;) ) you should find stuff like this :

[2.3.4-RELEASE][admin@pfsense.brit-hotel-fumel.net]/var/etc: ls -al /usr/local/captiveportal total 40 drwxr-xr-x  2 root  wheel    512 Jul 21 10:42 . drwxr-xr-x  14 root  wheel    512 Aug  2 14:59 .. lrwxr-xr-x  1 root  wheel    43 Jul  4 12:32 captiveportal-2style.css -> /var/db/cpelements/captiveportal-2style.css lrwxr-xr-x  1 root  wheel    45 Jul  4 12:05 captiveportal-nvx-logo.png -> /var/db/cpelements/captiveportal-nvx-logo.png -rw-r--r--  1 root  wheel  11603 May  3 19:07 index.php -rw-r--r--  1 root  wheel  10434 May  3 19:07 radius_accounting.inc -rw-r--r--  1 root  wheel  6862 May  3 19:07 radius_authentication.inc

As you can see, I have two sym-links, they are generated when you upload a file - like your image.
I have an image to, called "captiveportal-nvx-logo.png", shows up just fine in my home made 'html' portal login page, using come html code like this :

[](http://www.brit-hotel-fumel.fr/)

@mdes:

HTML img tag contains src=captiveportal-logo.png.

I didn't know the quotes "" were optional  ;D ;D

Take a look at this look at this : https://forum.pfsense.org/index.php?topic=83155.0
Other thread exists about blocking specific web sites

Hi,

You are telling nothing about your setup, so I'll explain using mine as an example.

First of all, it's impossible to get rid of IP's. They will always exists  ;)

My captive portal lives on OPT1 - I'm using LAN for my own needs.
I'm using the DNS Resolver.
On the setup page of the DNS Resolver, I added a Host "Override". My OPT1 interface address is 192.168.2.1/24 (LAN is 192.168.1.1/24).
I added :
Host : portal
Domaine : my-domain.net
IP 192.168.2.1
Description : Whatever you want.

Know that declaring a host for a domain will not force your clients to use the this name … The captive portal is hard coded to use the interface address IP when working with "http mode". https mode will (have to !) change that.

Now, the funny part : you have to switch to HTTPS login on the captive portal page.
As a domain name you chose your "portal.my-domain.net".
And ... you have to chose a certificate that your clients will accept (the Let encrypt acme package can help you here).

@beerten:

Is it possible to import the vouchers into the external database? Generate vouchers, import them into the external database into a seperate table. Select on when required and mark it as used.
Just a thought

You saw https://forum.pfsense.org/index.php?topic=133872.msg736484#msg736484 ?

has this been done?

@Gertjan:

See here : Captive Portal Troubleshooting : Issue : Captive portal not redirecting : first answer :)

Yep, I did read that one. It might even have triggered the solution. To me it is not clear it says one should define a local dns server. Could have to do with me, not being an english native speaker. Or my knowledge about DNS resolving is not what it should be. I posted my solution for the sake of the search function. I so a lot of topics on similar problems I had. But I could not find the solution.

Would appreciate some help!