No need to checkout your pfSense install, you could tead this :

The main 'index.php' file that generates the login page (and error page) :
https://github.com/pfsense/pfsense/blob/RELENG_2_3_2/src/usr/local/captiveportal/index.php
and
https://github.com/pfsense/pfsense/blob/RELENG_2_3_2/src/etc/inc/captiveportal.inc

captiveportal.inc contains most, if not all the logic.

Thank you.  Great tips.  I ended figuring out my issue.  I accidentally defined my entire network in the Allowed IP list not realizing this is a bypass list.  All is good, portal comes up.

Took the entire idea and moved it over to a posted bounty here: https://forum.pfsense.org/index.php?topic=122701.0

Anyone interested or finding this thread via search, I imagine it'll be more active there

@lupin212:

I apologize for my question which is not specific so that you may misunderstand.
When I configure pre-authentication redirecting to URL: http://abc.com, this causes problems. When users open the first website with form https, time to direct to portal login website is too long (still can redirect). In case users open the first website in day with form http, it can redirect immediately.
How can users open the first website with form https and quickly redirect to portal login?

Understand that you see your setup in front of you.
I see none.

Please: detail ….

Also : lately, more questions about "per auth URL" have been posted and from what I can make of it, it's more then tricky to use it.
Do you need pre auth ? (why has the visitor visit first page A on server B to auth to the captive portal on page B using server B (B = PfSense)) ?
Is your A also pfSense ?
If not, did you list the URL or the domain so that a connection to "A" is possible even when NOt auth against portal pfSense ?
In that case : did you test that these rules where present ? ( use https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting - and show results here )
The GUI firewall rules permit visiting site "A" (if sdite A is not pfsense).

These are only the question I would check if I decided to use pre auth page usage - and because I never used it, is even more questions will pop up ......

So : what about telling us more ?

Thanks. Got thinkgs working. I modified and pasted following.

Add "login.college.com" to the DNS resolver or forwarder so it point to the IP of your captive portal.
See here : https://forum.pfsense.org/index.php?topic=63791.0 - read the DNS forwarder point.

Edit : tel visitors to http - not https.
Normally, you do not need to supply a login URL. Any http://what-ever-here.tld (like http://www.google.com ) will show the captive login  portal page without any user action needed.
By nature, laws and other unbreakable rules : "https" will NOT show the portal page …. and people will be unable to login.

What about : debug the "pfSense to Radius" connection both ends ?

@bassc:

….So what do you suggest now my friend? Thx and good work.

pfSene is translated in two other languages, one of them is … Turkish.
Check out how all the other html pages are generated and you have the solution ;)

Hi Dylan,

THANK YOU !!!

After days searching on Google, I still couln't figure out what was happening with my "programatically ;)" submit button, then I found this topic !
I have the EXACT SAME issue, what a relief to find someone who could finally solve this.

I'm a beginner in html/js and stuff (started only 2 weeks ago) so I just copy/pasted your code which did…
...
Nothing :(

Then I noticed the last line looked like jQuery stuff (you confirmed this at the beginning of this topic), so I thought it would be a good idea to add this to my code :

but it didn't help.

Of course I changed PortalAction and RedirURL to my own variables.
I also put alert('xxx') right before and right after your code : I can see both but nothing happens.

Since I know nothing in jQuery, I don't know if I should add a ; right after the last line of code :

$( '#accept' ).click()

I tried though, but it didn't change anything neither.

Thanks to you I'm really close to the behavior I want to get from my portal page, but maybe I need help from a more experienced person.
Could you suggest something obvious I may have missed ?

I can post my code if needed, but it's part of a biggest website so it would look a bit weird out of its context).

Edit :
I changed PortalAction and RedirURL to static urls, didn't help.
I also commented this line :

//submit_form.display =  'hidden';

Shouldn't I be able to see the form appear on the page then ? I mean, btnSubmit should be visible, right ?

As long as it is not https and it is resolvable in DNS by the client, yes, any hostname will work.

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