Show captive portal page as home page?
-
Is there an easy way to show the captive portal page I uploaded to my pfSense box as the home page of a web browser? I'm setting up a couple kiosk thin clients in an area and when the browser is launched, I'd prefer to point it directly to the page that the users would see should they attempt to go to the Internet anyway…I just want to skip that step! I'd prefer not to fire up a separate server for on the subnet for this.
I couldn't figure out how to easily do it.
ie. If my pfSense LAN interface is 192.168.1.1, can I make it http://192.168.1.1/etc/where-the-file-sits.html or similar?
That would alleviate the need of worrying about certs or if a user tried an https site first. -
I would just set the default page for the browser to be something like http://some.local.domain/
That would always be redirected to the portal page.
You could set it directly to the portal page itself, such as http://192.168.1.1:8002/ but then if you made a change like add another portal or something that kicked that one to port 8004 you'd have to go touch the clients to make the change.
You would also want to put some kind of content on http://some.local.domain/ so if the browser was through the portal and was somehow told to go to that site again, something sane would be displayed.
-
In the case of these thin clients (or my portal in general), there is no authentication. We simply need them to accept the T&C's when it is launched. So if somebody steps away from the thin client and somebody new walks up, it'll be there with the "accept" button for them to press, even if it was just "authenticated" a minute before. There is no other local server on the network besides the pfSense firewall itself, or I'd prefer not to put one there.
I will try http://192.168.1.1:8002 later today. Thanks!
-
Is there an easy way to show the captive portal page I uploaded to my pfSense box as the home page of a web browser? …..
Short answer : your question is wrong. ;)
Long answer : Except for some ancient OS's like XP, all modern ones are "captive portal minded".
This means :- The user should activate the wifi part in his device.
- As soon as the wifi software found available SSID's, the user should select 'your' SSID.
- As soon as the (ONLY the radio !) connection comes up, the DHCP client in the user's device asks for an IP, DNS and gateway.
- The OS (not you, not the browser, not your home page) launches a simple GET : http://captive.apple.com/hotspot-detect.html - the page return should be "Success" - nothing more - nothing less. When this test succeeds, the OS 'knows' is has a open connection to the Internet - any server on the world.
- IF NOT, the the OS launches a mini built-in browser (like apple devices), or a a pop-up (Windows) that bring will up your default browser or ? (don't know what Androids do - it's messy - to many OS versions etc).
The mini browser used by apple will use the same GET again : http://captive.apple.com/hotspot-detect.html and again, the request will be redirect to the web server (nginx) running on pfSense, which will NOT return "Success" BUT your login page. The visitor can actually see the reply, and interact with it. In your case : clicking on "Accept". The web browser transmits the answer to pfSense, the portal web server and what then happens is what it all makes it work : among others, it will put in place a firewall rule that permits your device to bypass all other firewall rules that blocked and redirected your device in the first place.
Important to know is : portal detection by the OS is done on port '80' with a NOT a httpS request, redirect https requests like https://captive.apple.com/hotspot-detect.html will NOT be reached, your browser will NOT let you do so. The MTM-game is not an easy thing to circumvent.
Btw : you could publish a simple page somewhere on the internet, and use the pre-auth facilities of the captive portal offered by pfSense. Hosting pages on parallel on pfSense needs captive-portal-rejection rewriting (any requests coming in the pfSense captive portal interface will be rewritten (redirected) to the captive portal page).
-
These are thin clients and they aren't on WiFi. They are always up and connected. I realize for the WiFi devices everything you said is fine.
The thin client kiosks will default to a single page when booted up, and I want it to be the T/C page. When you close the browser, it starts right back up.
-
These are thin clients and they aren't on WiFi. They are always up and connected. I realize for the WiFi devices everything you said is fine.
As long as these devices open a http://this-page-should-exist.tld, - and present some kind of html feedback to humans, all will be fine
True, the captive portal also works fine when I slide in a Rj45 plug (cable) into my laptop, hooked up to the captive portal network. The wifi part is just optional, although more frequent.But why use a captive portal for "devices" ? Captive portals are fine for "devices with browsers that are piloted by humans".
What do you mean by "thin devices" ? Are you hooking up local coffee machines ?
-
Google 'thin clients'
-
Note that closing the browser will not log the user (IP/MAC pair, actually) out of the portal so the next user will not get the T&C page. They will already be logged in.
If you manually set the home page to the 8002 page this SHOULD not display the login page again but I think it might. You might have to make some settings in the portal to clobber the old IP/MAC entry when a new one comes in that matches, or you might end up with multiple entries (that would generally be harmless.)
-
