I'm not filtering, caching or whatever on my captive portal.
I use the captive portal so I can offer an controlled access to the Internet.
I'm not controlling content, as I think I have no right doing that. And I don't care.
If these people (adults) want to visit "the-worst-site-on-the-web.tld" than that is in their right. They want to look at all the publicity ? Perfect to me.
I offer internet "as it is", and not looking to store traffic they generated, or sites they visited.
Ok, true, I use pfBlockerNG (latest) and ones in a while I have pfBlockerNG also filter the clients on the captive portal interface. More for testing purposes, actually.
The film "Ready player one" (and Facebook themselves) gave me a good idea recently : No FB Fridays and Sundays.
[ I'm joking ]
Clients that use my captive portal and try to launch nukes from their hotel room using our Internet access, they will use a VPN - which makes any filtering on my side useless.
The good old 'http' only days are over.
Yeah, there was something .... I've been using a patch for the captive portal back then.
I'm not sure it was disconnecting clients, though.
I've been using 2.4.5-p1 for months if not a year, way back then (2 years ago ?).
2.5.0 was better - 2.5.1 even better and 2.5.2 is just great : set it and forget it.
The real issue is : why do you chose to use a version that has already has ameliorations and bugs fixes for it ? true, they are all documented and discussed in the forum : 2 years ago.
I can't actually list up anymore aspects of 2.5.0 or even 2.5.1 ;)
edit : Coffee got my memory back : for 2.4.5-p1 there is are two rules that you have to apply :
Rule 1) Never change the portal settings when user are connected.
Rule 2) If you have to, go to Status > Captive Portal> ZONE and use the red button.
@dwolfix wondering if you had this issue, when using radius mac authentication i get the hostname instead of the ip address in post action. if mac authentication disable y get the ipaddress and it woks fine
@gertjan Thanks for helping with this.
This is my first chance to get back on this. Everything works correctly now. I posted the wrong url- the one I posted was for the captive portal page and not the page that is re-directed to. Your last sentence was the clue I needed.
I used the CP page URL for the first part then added "/captiveportal-SH.html" on the end. That works perfectly. It passes the valid URL test and allows saving the config and then it works to redirect to the correct page.
For anyone reading this for help. If SH.html is the name of the file, file manager saves it as captiveportal-SH.html.
Then use the live view to open the CP page and note the URL. In my case the URL was http:/192.168.100.1:8002 and I added this before the file name.
Final result is http://192.168.100.1:8002/captiveportal-SH.html.
Thanks also to Jimp.
Have the word 'public' removed.
MITM can work with devices you control and most probably own.
So you will know what happens on devices you control ... quiet logic as it would probably be 'yourself' operating these devices.
Or it could be devices that are given to employees. These are also under your control.
But there is no need to use a captive portals for these devices.
A captive portal is meant to be used for unknown - untrusted devices, belong to unknown people, and you want to 'offer' them a Internet connection. These people / devices do not use any local services / resources, just the connection.
Well ... he paying your hours, right ?
This isn't like "installing yet another Windows PC". Not the same 'qualification', neither ... ;)
Still : good luck ^^
Look at https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security most 'big' sites use these HSTS certs these days.
When the device visit ones one of these HSTS sites, the cert is stored for a year or so. A later MITM type of connection gets detected and refused.
MITM is a 24/24 H job, new exceptions will constantly pop up and have to be deal with.
@tseip I have the same issue you describe. No portal offered to the clients.
I'm using 2.5.2 version in two different sites with HA on each.
It just stops working after some days on both sites (2 failures in 15 days) and the temporary solution is "edit and save".
I don't think the secondary IP is the reason, it's the standby and it's not used by the clients.
I looked at the logs but I don't find anything that looks interesting.
The captiveportal- prefix is there.
In Captive portal file manager is named captiveportal-SH.html
The file uploaded was SH.html and the upload process renames it to captiveportal-SH.html
That is the name typed in the redirect URL box that causes the error. The name includes the captiveportal- prefix
The full name in the redirect box is "captiveportal-SH.html".
Is that all that should be required?
Edit: Should it be http://192.168.100.1/captiveportal-SH.html
How can I query the last activity information on the accounting side or on the sql side?
I doubt the If the result of "captiveportal_get_last_activity()" is actually stored in the SQL database.
The 'acctupdatetime' (updated every 'actinterval' = env 600 seconds) together with acctinputoctets and acctoutputoctets could used to see if there was any activity during the last 'actinterval' seconds.
The radpostauth table contains an every minute a recheck of the login (if you enabled that feature).
A real time updating of the results of the "ipfw" can't be transmitted to Freeradius. Run radius -X for your self to see what is send between the pfSense captive portal and Freeradius.
@gertjan Ah, because when I test in my office it works fine (it never seems to get a CDN address) so I need to test it on site and that is a little bit more complicated and required permission before I do it.
I will of course report back as soon as I have tried.
I guess "amazon" can be considered as a "large public web site".
This means that there is no way to obtain all the IP's of a host name.
Even if you manage to get them all, at that moment, the info is la ready outdated, and your alias list isn't valid any more.
If you need to make stuff available, put it on a host (and or domain) where you have some control over DNS.
does that mean they would have to type the full URL?
Easy answer : when the portal user types in the 'bare' domain name of the captive portal, like
there will be a fail.
Look at the index.php file that gets loaded, it's here : /usr/local/captiveportal/index.php
The port number has to be present, as the portal is not listing on default port 443
The 'zone' parameter has to be supplied.
My simple explanation :
First, the browser take the host name, and resolves it to an IP. Because the local host over ride will match the host name, this will be a quick job.
Now, the browser has the IP (of our captive portal network) and will connect to it.
When it connects, it asks for the (a) default page - file actually, index.php and add parameters to it (if present).
But you think HTTPS may not be needed as HTTP works fine for most devices?
Forget about "http", it's dead. https is not some sort of option. In a nearby future, browser won't be able to use it anyway (without a boat load of warnings etc)
And what about this one :
A captive portal does not use WPA or WPA2 wifi encrypting. This is not really an issue because :
every mail you get and send, every web page you visit, every request an App in your Phone makes (to your bank), is TLS encrypted. There is no need to encrypt encrypted data.
True, DNS traffic will go over the Wifi in clear. So, some one might know you just visited facebook. But nothing more.
If I was to setup ACME, would that achieve the desired result of the portal being reached at portal.hotelname.net?
You should use the acme pfSense as it permits you to automatize the entire process. The needed certs will get renew automatically, no maintenance needed.
Normally, I never need to 'manage' our captive portal.
I could even take a 6 month holiday, and will still work just fine.
You can also buy some where else a cert with a validity of one year, or two.
This means you have to come back after some time to put in place the new certs.
So, why bother ?
Get a domain name (a couple of $ a year). Get acquainted with what Lets-encrypt is, what "acme" does, set it up and enjoy.
Or, is there a way for the client to type portal.hotelname.net and it redirects to https://portal.my-network.tld:8003/index.php?zone=cpzone1 for example?
I understand your question, as I had the same way, way back.
You will discover over time that your question fades away.
Again, all devices on planet earth use OS's that are captive portal ready.
It goes like this :
The client actiavtes the Wifi and connects to an visble SSID - like your "Your Hotel".
When it connects, many things happen, and end user don't know, don't need to know.
You are the admin,you should know what happens now.
The client device thtows out a DHCP request to obtain a network, IP, gateway and DNS.
Then, the devices throws out a initial 'http' (not https !!) request to a known URL, like http://portal.apple.com - see https://discussions.apple.com/thread/7491051
Android based devices work the same way.
Microsoft (Windows) works the same way.
Any 'Linux' based OS works the same way.
As said, the clients in our hotel are not smarter as elsewhere, and they all connect just fine without me giving any instruction.
This doesn't mean it works for everybody.
There will always be people that use devices that use anti virus stuff with strict firewall rules that do not accept any other connection as their own 'home' known network.
These guys won't be able connect anywhere, as their security was set up to enforce this behaviour. The funny part is : they don't know this themselves ...
Private (random) MAC, or not, when my iPhone is connected to my local 'office' wifi it keeps replying on my pings until it lockes down.
And to my suprise, my phone is locked right now, and it sill replies to pings (I really thought it would de activate the wifi when it sleeps *** ....)
When you connect for the first time, with private (random) MAC activated, that MAC address will get used every time you use that SSID.
If the MAC was really randomized every time the wifi reconnects to a known network, users wouldn't be able to use a network with a captive portal ;)
As soon as I activate my iPhone again, it reconnects to my office Wifi immediately.
Because I "told" it to do so.
Exception (I'm not sure - the Apple doc will tell) for those who activated the "spare battery mode" (signalled with a yellow battery indicator ?) you have to tap on the wifi SSID to make it to reconnect.
I confirm that I had never had issues using whatever Wifi network using whatever iPhone using whatever iOS version.
And if there were isues, billions would see the same thing, and Apple would have applied an urgent iOS update.
So, @davidki, tell us about your setup, and we'll tell you what's wrong with it ;)
An example of an issue would be :
Bad Wifi (radio) signal, mixed with other SSIDs that emits on the same frequency, etc.
To many AP's in the neighbourhood.
To many devices on one AP (noop, the basic ones can't handle many devices at the same time).
And also : DHCP issues.
edit *** : and when I think about it : I was mistaken.
When you switch from 3G/4G/5G operator data carrier to a wifi 'Internet' source using some Wifi network around you, your phone is reachable by the Internet-over-wifi connection, not your operator's carrier (and Internet connection).
When the phone stops the wifi, it wouldn't be able to receive mail pushes, VOIP calls etc in real time. So, no, the Wifi connection (the radio) shouldn't stop, even when telephone is locked. It probably goes is some low power consumption mode.
@rotanon The voucher field in its default state is visible whether or not you have configured the captive portal to use vouchers or not. Maybe you do not mind this but personally I think it makes the captive portal too confusing to the end user. If you have configured your captive portal to allow just "accept" the terms then you can edit the html file and simply find the field tag and type in "hidden" to hide the voucher field from view.
iOS 12 or before - or the newer (latest) 14.6, the captive portal works fine.
The (non) issue is pfSense 2.4.3. Easy to solve : hit the upgrade button, 2.5.2 is out and does the job. I have an entire hotel hooked up to the portal, and tourists are connecting just fine using all kind of devices.
is there a way to use a FQDN instead of an IP address ?
It's even advisable to use FQDN instead of a bare 'IPv4'.
The "http" access is just for the kick start of the captive portal: a real captive portal should be setup up to a https based portal, and use a trusted certificate so you can (have to !) use FQDN
Do not use a self generated certificated for obvious reasons.
Do this :
install the acme.sh package,
understand what it does, what 'Letsencrypt' (certificates or "https") is all about. What registrats are supported.
get (rent !) a domain name with one of them.
keep it simple : ask a wild card certificate for your domain. Like *.whatever.tld - so now you can use a the FQDN "pfense.whatever.tld" to access your pfSense,
and the FQDN "portal.pfense.whatever.tld" for your portal
Inform your unbound resolver about the host override "portal.pfense.whatever.tld" :
where 192.168.2.1 is your captive portal interface IP.
Now, select the https access on your portal :
edit : see also the official Youtube > Netgate offical captive portal video's. Or use one of these. This one is recent and looks ok to me.
Running these from cmd line within pfSense seemed to soft brick it, but runs from serial shell.
It populates in the ipfw table with the /24 syntax, which tells ipfw has some idea of what's up but maybe something wrong with their hashing?
--- table(CaptivePortalZoneName_pipe_mac), set(0) ---
04:33:c2:00:00:00/24 any 3003 0 0 0
any 04:33:c2:00:00:00/24 3002 0 0 0
Restarting the Captive Portal service does not flush the ipfw table, but I don't have a foolproof way to prove the table is "loaded and active" vs this functionality not working as documented by freeBSD?
Router reset flushes manual entries, and in the couple minutes of ctrl+f I couldn't find the path in captiveportal.inc for the SQL db.
I'm open to any suggestions. Have several good restore points and comfortable in the serial terminal, so I don't mind temporarily bricking something for testing purposes.
Older version had old bugs. This issue, "You are connected" doesn't exist any more.
I just tried it myself :
This is my captive portal zone name :
So this is the SQL3 database file that contains all the users that are connected :
This file is wiped and created on restart.
If this option is set :
then the file is not reset.
Upon reboot, the file is read, and for all captive portal users that were connected upon reboot - listed in this file, 'ipfw' firewall rules and tables are re created. See the ipfw rules for yourself.