@sebastiannielsen: no, he isn't out to restrict to a specific OS. what he is out for, is, when a client authenticate correctly, the client's MAC, OS-fingerprint, and IP is saved in the firewall rule. So the OS-fingerprint must match whatever the user authenticated with, to prevent spoofing. Yes, that's precisely what I'm looking for. I wasn't aware that pf wasn't used for the Captive Portal. However, since pf is still available for filtering, I was thinking about something like this: Create a pf rule that logs the OS fingerprints of clients. After a successful login of a user, create a pf rule for the IP that the user got that only allows TCP traffic with the OS fingerprint that has been detected during login. After either a voluntary logout by the user herself or after the soft / hard timeout, remove the pf rule for the user's IP. This should add one more layer of security. Sure, it's not foolproof but certainly would add one more hurdle to abuse.

Ok, i understand ! it's logic. i will see if it's possible whith a proxy… Thanks you to all.

To solve this issue forever you must add the CA cert to Pfsense GUI and restart the Captive Portal Services Step: Cert Manager –> CAs Tab --> Create a new records --> fill up "Certificate data" with CA Cert --> use IE or FireFox to test https url Note: don't use Chrome because it can handle this case

@Derelict: If you do not get an address it's DHCP - nothing to do with captive portal If you cannot resolve names, this might be because you are not passing through necessary name servers in captive portal. hosts need to be able to resolve names if you want browsers going to www.domain.com to bring up the portal. I have probably 8000-15000 different devices going through Captive Portal every week. It works fine if configured correctly. You are going to have to systematically go through the steps necessary for CP to function and find the specific failure before we (or at least I) can help you. Thanks Derelict I have found the problem and it was the Wan and the Lan had some checks that should not have been checked and it was the bottom 2 that refuses bogons and the other above it. I unchecked them and then all went well quick and hope it helps someone else if they have the same problem. I can now type in password only on the custom page and no more hanging and timing out off to the world web. Thanks for your patience with me even though I know I didn't explain very well but like I told yawl I'm totally new to pfsense. I did go back and use the default pfsense portal page like you ask me to and was still no good until I unchecked them boxes.

Hi all, Seems I fixed it after upgrading lighttpd. Thanks

I would start by comparing the DNS settings on the machines which work against those that don't. If they're using different DNS servers then that could possibly account for the conflicting behaviour. Check the routing, too.

NAS IP and VLAN ID in the user config aren't the same thing. You'll need to configure freeradius accordingly to use the NAS IP you're sending it. I'm not sure offhand how to accomplish that in freeradius but that's where you'll need to look.

The CP simply handles authentication, not proxying. What you're asking for is a proxy solution that shows sites visited. Hence I would suggest either Squid/Lightsquid bound to AD to map usernames to sites visited, either running on the PFS directly or running as a standalone proxy.

Or use standard limiters. If you're on 2.2.X YMMV.

thanks!

It apparently waits quite a long time for something to happen (blue progress bar loads to about a third) but then presents me an ERR_CONNECTION_TIMED_OUT. I clicked around in status and found the services running like seen on the picture below. Don't know if that helps.  

@asistio04: @mendilli: for the username and ip;open captiveportal_logout.html which is in "/var/etc" add this line anywhere you want to display the client username and client ip LogoutWin.document.write('USERNAME = '); LogoutWin.document.write('YOUR IP = '); you are very welcome Thank you for this ,,,tested and working

Captive portal is not compatible with squid (at least transparent) on the same node. You could have an upstream caching/filtering node with the portal node behind it though.

@ThePirat: Thank you very much Derelict, I'll try and let you know if it works Best, Cristian ps…yes, I have configured my pfsense two vlan yet such could you solve your problem.? If you've been able to solve what was the solution if you would be so kind. Regards.