@robinwright said in Apple devices not automatically opening CP Login:

Do use any filtering?

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.

@madmax1234

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.

The same configuration on 2.4.5-RELEASE-p1 works without issue.
the issue on 2.5.x

@seekerman found somewere in the forum that this is a bug on version 2.5 fixed in development version.. ill try and let you guys know

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

@robinwright said in Enabling HTTPS login certificate errors on http redirects:

they want MITM logging for public devices

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.

@robinwright said in Enabling HTTPS login certificate errors on http redirects:

saying this just won't happen

Well ... he paying your hours, right ?
This isn't like "installing yet another Windows PC". Not the same 'qualification', neither ... ;)
Still : good luck ^^

Btw :
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.

I had to install an old version of OpenSSL to get this to work. I did the following under Ubuntu WSL:

# (Install compiling library Make) sudo apt-get install make # (Download the latest OpenSSL 1.0.2g binaries) wget https://www.openssl.org/source/openssl-1.0.2l.tar.gz # (Extract the tar ball to the local directory) tar -xzvf openssl-1.0.2l.tar.gz # (Enter extracted OpenSSL directory) cd openssl-1.0.2l # (Configure binaries for compiling) ./config # (install configured binaries) make cd apps ./openssl genrsa 31 > key.private ./openssl rsa -pubout < key.private > key.public cat key.private cat key.public

@jimp
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
Edit:
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

@ahmetakkaya said in Captive Portal Last Activity:

@gertjan

I already have my settings as in the picture

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.

@gertjan I tried the code and it worked! .. and dropped it directly into cron .. thank you, sir!

@jeromert said in Pfsense partal with access to amazon aws:

The amamzon aws site has several IPs corresponding to its hostname.

Go here first.

Take note of :

7cab8ca3-edec-4983-8044-24c5e14b9d19-image.png

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.

Hi,

So I investigated and...Indeed, you are right. It's a bug

Well, to be more precise...it's a side effect of a completely unrelated bug.

The bug is related to the login form itself :

The login form on the error page is redirecting an user to the pfSense FQDN but it should instead redirect the user to pfSense IP.

When receiving an HTTP request on the pfSense FQDN, the captive portal does not understand it, and issue a 302 redirect.

047f1591-bf4d-4dfa-8ff1-838e8d6768d2-image.png

This issue has been already reported (here : https://redmine.pfsense.org/issues/11902 ). It has been fixed in 2.5.6 (the latest, development version).

@viktor_g said in Captive portal allowed hostnames / allowed IP not working as expected, how to debug?:

This is pfSense 2.5.2 ?

Yes.
I'll file one as soon as I found it ;)

Unfortunately no, I have little experience with wireless bridges.