2.3.4 Captive Portal Issue
-
I'm getting errors nginx: [error] 27009#100170: *8 open() "/usr/local/www/captiveportal-jquery.min.js" failed (2: No such file or directory), for several files. The problem is these files are actually stored in /var/db/cpelements. Has this bug been reported?
-
I'm not seeing those here. Maybe it's from attempting to view the portal page from the GUI and not from a captive portal client? There was a bug reported with that last week that I fixed.
-
How did you fix it?
-
How did you fix it?
jimp is one of the persons who codes pfSense ;)
Btw : the correction (about the captive portal preview function) was for 2.4.0 - a future release.But what about this one :
Maybe it's from attempting to view the portal page from the GUI and not from a captive portal client?
Yes or no ?
If yes : you should know know that the GUI uses this document root : /usr/local/www
The captive portal uses its own : /usr/local/captiveportal. In this directory you will find all your 'user uploaded' files, symlinked to /var/db/cpelements, where they actually reside.
I advise you to do a real live test on your portal : checkout the page your browser loaded when logging in. You yopu did'nt make any errors with the references used in your html code, all will be fine. -
How did you fix it?
See https://redmine.pfsense.org/issues/7646 and the commits linked on the ticket.
-
How did you fix it?
Yes, you are correct. I'm trying to view the portal page remotely after I Natted the Interface IP to ports 8000-8009 which I have done with previous versions without issue. It seems like 2.3.4-p1 will not allow remote viewing of the portal page, is this correct?
-
I just tested this on 2.4.0 RC 20170821 and found same issue with captive portal not working when accessed from interfaces not selected in CP. Actually, it displays only the index.html, but with no CP elements/resources. Makes supporting or developing captive portals for remote production servers extremely difficult. Was hoping this would be fixed in 2.4…
-
If you click "live view" it displays the portal page with all of the proper elements. "View Page Contents" literally dumps the raw index.html source at you without interpreting the macros or anything that make it display, it's used for debugging.
That said, "Live View" may not work properly in some cases because if your portal is HTTP and your GUI is HTTPS, then HSTS may prevent you from accessing the live view. If you setup HTTPS portal logins (e.g. with a proper cert from ACME/Let's Encrypt or another trusted CA) then it works fine.
-
Tried changing GUI to HTTP as test and captive portal still has same/similar issue.
Strange that this does not show as error in system logs.
Obviously, the default portal can be accessed via NAT since its CSS is inline in index.html and not referenced. Any way you could provide link to working example of remote access to a captive portal utilizing external CSS/JS/CP elements on 2.3.4+ ? i.e. http://a.b.c.d:8002/?zone=cpexample or https://portaltest.pfsense.org:8002/?zone=cpexample, etc.
-
It works for me with:
https://hostname.fqdn:8003/?zone=myzone
That said, I'm accessing it via the WAN subnet directly, or other local interface subnets. If you are farther away (e.g. not L2 connected, but routed somewhere) then you will have to disable MAC filtering, at least temporarily, or the portal security won't let you load the page at all.
-
Try hitting your portal page on your mobile ( cellular data) for example and you will see the issue that exists on 2.3.4. Mac Filtering has been disabled from the start. What has changed from the previous versions that the Captive Portal page is no longer accessible remotely? Thank you for your continued help.
-
Again, it works fine for me here. I have HTTPS enabled on the portal, with the firewall's hostname filled in, and with a "real" cert from Let's Encrypt.
It was broken on earlier 2.3.x releases but I added the "Live View" back in not too long ago and made sure it worked when I did. It has to be something in your settings, rules, etc.
-
OK, was able to finally access it by deleting NAT for ports 8000-8009 and just adding firewall rules for those same ports on WAN. Added our company's wildcard cert, created subdomain for this server and changed captive portal to https with our cert. GUI shows secure in Chrome with new FQDN, but captive portal, while displaying correctly now, shows insecure in Chrome.
-
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.
