@empbilly: …. How I can check If my certificate is Trust by default? When you obtain a certificate from a Trusted source ( Certificate Authority ) => https://en.wikipedia.org/wiki/Certificate_authority you'll be fine. The tutorial you mentioned showed you how to do it.

Google knows a lot about "Resource interpreted as Stylesheet but transferred with MIME type text/html". It isn't a pfSense or FreeBSD or even nginx or apache2 issue. It happens when …. well .... you'll find it out. I'm also using this : <title>xXx</title> ..... The file "captiveportal-style.css" is the uploaded style.css file. Always worked for me.

Thanks, I have this value set at 10 concurrent logins. Please note: The other pfsense doesn't get these disconnect's in the logs and doesn't get users being disconnected randomly, the same customers on the same physical network (different VLAN) using the same radius server. These disconnects dont' have a reason, all the other disconnect have a reason in the logs. This must be a clue? It seems that users don't get to stay on for more than a week, right now the longest online user is 3 days - there are about 14 test users. Cheers, Tim

Oh thanks for the troubleshooting link. I had previews rules to block http and https of the proxy, so after auth the user couldn't connect further. Also, I had to change the dns served by the dhcp to be pfsense itself, instead of allowing the lan network to reach the dns server. Thanks! Now I'll focus on creating the pages for the users on the captive portal, thanks again

Probably a case of : Captive portal + squid = no joy. Check out other (recent) squid related messages.

@JerryV06: Suppose Im only concerned with loggin Macs and date/time stamps then; how can I accomplish that? Activate authentication. You'll be having a log like this : Nov 24 06:35:11 logportalauth 20593 Zone: cpzone1 - LOGIN: 109, 70:de:e2:84:da:ee, 192.168.2.239 Nov 24 05:27:39 logportalauth 66704 Zone: cpzone1 - TIMEOUT: 212, 44:2c:05:47:41:49, 192.168.2.18 Nov 24 04:35:17 logportalauth 45602 Zone: cpzone1 - TIMEOUT: 202, 88:63:df:83:26:00, 192.168.2.13 Nov 24 04:07:06 logportalauth 40072 Zone: cpzone1 - TIMEOUT: 106, c8:85:50:19:c5:df, 192.168.2.10 Nov 24 03:26:34 logportalauth 28397 Zone: cpzone1 - LOGIN: 110, 58:48:22:d4:08:83, 192.168.2.12 Nov 24 03:09:06 logportalauth 28397 Zone: cpzone1 - LOGIN: 212, 44:2c:05:47:41:49, 192.168.2.18 Nov 24 03:02:39 logportalauth 11099 Zone: cpzone1 - TIMEOUT: 107, d8:3c:69:fc:a5:18, 192.168.2.148 Nov 24 02:54:35 logportalauth 57574 Zone: cpzone1 - TIMEOUT: 109, 70:de:e2:84:da:ee, 192.168.2.239 Nov 24 02:13:17 logportalauth 5599 Zone: cpzone1 - TIMEOUT: 203, 18:3d:a2:02:99:f8, 192.168.2.16 Nov 24 01:23:36 logportalauth 94954 Zone: cpzone1 - LOGIN: 210, 80:13:82:21:45:b2, 192.168.2.17 Nov 24 00:45:40 logportalauth 20329 Zone: cpzone1 - TIMEOUT: 103, 48:51:b7:80:d5:a4, 192.168.2.11 Nov 24 00:34:35 logportalauth 27497 Zone: cpzone1 - TIMEOUT: 108, f0:db:f8:9e:be:35, 192.168.2.8 Nov 24 00:26:31 logportalauth 11276 Zone: cpzone1 - TIMEOUT: 110, 58:48:22:d4:08:83, 192.168.2.12 Nov 24 00:22:30 logportalauth 86792 Zone: cpzone1 - TIMEOUT: 109, b8:76:3f:3f:e7:99, 192.168.2.14 Nov 23 21:59:01 logportalauth 94954 Zone: cpzone1 - LOGIN: 203, 18:3d:a2:02:99:f8, 192.168.2.16

The patch was removed because it's been breaking CP plus patching other package's/core OS files is just completely wrong. And no, replacing it with a GitHub copy won't help to get the "feature" back.

What I did is to configure CP to "no authentication" and load the "Splash Screen" with no post button. That way the clients that does not know about the proxy when they tried to access the Internet directly will receive the "Splash Screen" blocking their access. If you want to allow some machines you do it by adding their MAC address to CP, or if allow to some sites add them to the "Allow Hostnames"

There has almost a month since I started this thread but did not had any reply. I guess then that there is no way to know the blocked sites by Captive Portal. So maybe this should be a feature request to pfsense, and in my opinion an important one.

Noop. You have two option : Code it yourself. Have it coded.

The default in my experience is <ip-address>:8000. So in your case it would be http://192.168.12.1:8000. Provided your access points are all on the same VLAN as the RJ45 users, you should be able to get a CP page once your client tries to navigate anywhere on the internet.</ip-address>

I use Daloradius. Makes management of the accounts a lot easier and reporting - including data usage - is available. http://www.daloradius.com/ Sorry if this sounds a bit like a commercial.

Thank you Gertjan It seems that reconfiguring DNS (forwarder –> resolver) and removing 8.8.8.8 helped. Problem is solved.

Hello Gertjan, thanks for your reply! I discovered the issue, I had enabled the following options in Captive Portal settings: Reauthentication - Reauthenticate connected users every minute RADIUS MAC Authentication - Enable RADIUS MAC authentication So, when I disabled them, the php-fpm service decreased the CPU usage and now everithing is fine! Regards Olá Gertjan, obrigado por responder! Eu descobri o problema, eu tinha habilitado as opções abaixo nas configurações do Captive Portal: Reauthentication - Reauthenticate connected users every minute RADIUS MAC Authentication - Enable RADIUS MAC authentication Então quando desabilitei, o serviço php-fpm diminui o consumo de CPU e agora está tudo funcionando! Abraços

Did you get this fixed? I am running into the same issue.

@jimp: captive portal is not a package -  it's part of the base system. Fair enough

Status => System Logs => Captive Portal Auth Logs shown in GUI will 'expire' but your can extend the delay. You'll find the info. If you use vouchers etc, do use an external syslogger.

Wow, I didn't even think of that. Nice work!