@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 : [image: 1629972827889-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. [image: 1629843543323-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.

@wifi-will said in Captive Portal - Change redirect from IP to a DNS name: 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 https://portal.my-network.tld 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. So, yes, this is the minimum : https://portal.my-network.tld:8003/index.php?zone=xxxxx @wifi-will said in Captive Portal - Change redirect from IP to a DNS name: DNS host over ride can replace the IP address, but it wont get rid of all the information Take your pick here. 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). @wifi-will said in Captive Portal - Change redirect from IP to a DNS name: HTTPS needs to be dies to a real domain that we would host. Such as a subdomain on our website or something? It needs to be a doman name you rent. Otherwise Letsencrypt can't give you a cert. @wifi-will said in Captive Portal - Change redirect from IP to a DNS name: 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. @wifi-will said in Captive Portal - Change redirect from IP to a DNS name: 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. @wifi-will said in Captive Portal - Change redirect from IP to a DNS name: 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 ... Btw : things will get easier in the future : see https://developer.apple.com/news/?id=q78sq5rv

@thangnv0712 Use this page and commands listed : Troubleshooting Captive Portal What are the GUI firewall rules on your captive portal interface ? Btw : 2.5.2 is rock solid, contains ameliorations and bug fixes.

Hummm. 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. Bad AP 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.

@free4 I will post the specs shortly :)

@papdee said in Voucher only template: @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. Or : use the power of PHP : This is the default html structure : <form method="post" action="$PORTAL_ACTION$"> <input name="auth_user" type="text"> <input name="auth_pass" type="password"> <input name="auth_voucher" type="text"> <input name="redirurl" type="hidden" value="$PORTAL_REDIRURL$"> <input name="zone" type="hidden" value="$PORTAL_ZONE$"> <input name="accept" type="submit" value="Continue"> </form> Make it look like : <form method="post" action="$PORTAL_ACTION$"> <input name="auth_user" type="text"> <input name="auth_pass" type="password"> <?php global $config, $cpzone; if(isset($config['voucher'][$cpzone]['enable'])) { ?> <input name="auth_voucher" type="text"> <?php } ?> <input name="redirurl" type="hidden" value="$PORTAL_REDIRURL$"> <input name="zone" type="hidden" value="$PORTAL_ZONE$"> <input name="accept" type="submit" value="Continue"> </form> Now the voucher entry filed iwill not get showed when the vouchers are not avtivated for the instance "cpzone". You could even hide user/password entries if vouchers are activated. The limit is your imagination ^^

@jimp thanks for the update, I'm relieved to know that, since the way it works now looked pretty weird.

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