Hi !

Google : pfsense vouchers shorter
Have a look at the first link.

I have the same issue.
I want to make pfsense can be used which1 username able to connect in 2 devices.
If I enable Concurrent user logins, it will open to many devices. How to make it only limit for 2 devices with same radius server?

Thanks.

You need Radius support.
A reply - somewhat - starts here : https://forum.pfsense.org/index.php?topic=108493.0

The app it's only for print the vouchers.
You need to create a .csv file in pfsense, then import it to the app.

@stinkfly:

…
Any other considerations like supported number of users, security etc;  Have others gone through this thought process?

Checkout this thread - in the very same forum where you posted : [HOWTO] Captive portal + FreeRADIUS + local MySQL user friendly single step  « 1 2 3 4 5 … 9 »

There is no such limit as "supported users" : your bandwidth will be depleted way before user authentication starts to crawl. Captive Portals with thousands of users online have been seen already.
Security : well, depends how you set it up ;)

Could be anything, not enough detail. Basically the error message means that it tried to send a RADIUS request but it got nothing back.

So it could be pointed at the wrong RADIUS server or port, it could have an incorrect NAS secret set, could be something on the RADIUS server (no entry for the firewall as a NAS, for example)…

Check your logs on pfSense and on the RADIUS server, maybe run a packet capture and see what you show for RADIUS requests on port 1812.

@Thilroy:

…. then receive a confirmation link to activate their account...

Keep in mind that portal clients have very limited possibilities when he/she hasn't authenticated yet. DNS works - DHCP works, and that's it.
So "receiving a link" (by mail) is impossible.
Fat mail clients - web mails etc won't work at that moment.

@Thilroy:

Is this in any way achievable with pfsense ?

Well, yes.
My pfSense makes coffee with the mouse click  ;) (no joke, it does)
It's all about : you have to code this one up.

edit NPS server : I don't see how a "Windows NPS server" would help you if some Portal visitor with a (example) "Android device" hooks up to your network.

edit again I do remember that "Mac Donalds" does have port "110" and "143" open up front, and better yet, they intercept the connections using these ports, they "intercept" your mail address (yes .. yes, they did) and …. when my mails came in, I also received a mail (on ALL my mail accounts) from them with HouseRules, "Welcome" & "More burgers .." etc etc. I think they abandoned this procedure  ^^ (and all my mails passes along using "993" / "995" now - Mac Donals's doesn't do MITM yet ...)

First things first.

Does the internet work if you turn off the captive portal? If not, check the rules on that interface.

More info : https://forum.pfsense.org/index.php?topic=136370.0

I have a few tips.

But first : you are using the latest (2.3.4-RELEASE-p1) .version, right ?
If not, well ….

Start by saving your config for later analysis, and bring all settings to default.
Leave LAN as proposed.
Setup your WAN connection.
Now, check that you have an Internet access from any device on LAN - and pfSense of course.

Create a group called "portalusers", and assign it this privilege "User - Services: Captive Portal login".
Create a user "test" with password "test", make it member of the portusers group.
Activate captive portal.
Set "After authentication Redirection URL" : set it to whatever, but something correct like : "https://www.google.com"
Authentication method ; select "Local User Manager / Vouchers"
Save - the portal is running now.

IF you use LAN as the interface for the captive portal, no need to add or touch the 'hidden' GUI firewall rule (actually, you can't - its hidden) . The default 'pass all' rule will do for now. DO NOT ADD anything. It's ok like this.

Now, its time for some basic checking.
On the device you use for testing, BREAK the connection (rip out the cable - switch off the wifi radio).
Activate it.
Get a command prompt ( run cmd, open a shell session, or, at least, go view network connection settings)
CHECK if you obtained an IP - and it which MUST be in the range of the DHCP server that's running on the captive portal (your LAN or OPTx interface on pfSense).
This implies that DHCP (client) must be active on your device.

Check also : what is the gateway on the device ? Must be the IP of pfSense. The DNS MUST be pfSense also (same IP gateway).

Now, for the most simple test - and most f*ck up here : ping to google.com (NOT to 8.8.8.8 !) do this : "ping google.com".
There will be NO ping replies but the name resolution part (translating google.com to 216.58.198.206) should work. This shows you that you can not reach the internet, but, somehow, DNS still works. DNS HAS to works, otherwise the captive portal doesn't work - or "no device on the LAN will work".
DO NOT use the DNS Forwarder - use the default DNS Resolver on pfSense. ( This is part of the golden rule : keep everything to default except if you know how to deal with it )

Bookmark and read this : https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting

Now, when your device has an IP, a DNS and a gateway, you see that you do not have to open a browser (you shouldn't do so - if it has a default home page to a https site, things will break because your browser will NOT accepts replies from any site except this https site.
So, a browser will up all automatically - windows launches one after a popup, iPhone/Pad will do so by themselves, Android : I don't know but I guess they do
This browser will go to some http:// site and, by magic, gets redirected to the page that the pfSense serves : our built in login page.
If credentials are ok, you will get redirected to our "After authentication Redirection URL" which proves right away your are connected.

Note : it takes 5 times more time to write this up as setting up basic captive portal access using pfSense.

Btw :
"even activating DHCP …." ?? without it you'll be an expert to make it work.
"activated a Proxy on the browser  " : What ? Why ?
Do not edit the default login page except if you have some minimum html knowledge, respect the minimal 'html coding' as shown on the captive portal settings page.
"do not start with radius" or whatever (proxies like Squid) . radius is nice if you know what it is. Know how to set it up. And, most important, know how to debug it, and know how to debug the inter communication between pfSense and radius. As usual, hours and hours of reading will reduce setup time to minutes.
Do not make complicated setups: keep it simple. These tend to works for years - mine does now for nearly a decade ( !! ).
Read - but do not trust - what you find on the Internet. Most isn't recent, talks about old version - ALWAYS miss an essential thing (up to you to find what it is). pfSense.org pages are valid, the rest is just a story of a guy writing up something ones.

Always make a minimal working situation first, then add very small steps towards your final setup. When errors are shown you can focus very easy on what went wrong, and go back to the working situation "with one click".

The captive portal can work on LAN, but it really works best on a separate, dedicated interface, like OPT1. You can put on that interface special firewall rules for captive portal users. This is a chapter of itself, and depends on what kind of visitors you have on your portal.

@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 ?