@Gertjan

Yes, it turns out a whole trip to the theater.😊
Also, it turns out that the problem is solved, the solution (in my case) is found, published. Maybe it will help someone.

Thank you very much!

As for DNSBL - perhaps I will create a new topic.

@gertjan
btw, I change mode to "last login" in the captive portal setting then it work fine for me, clients should re-enter the code at the time DHCP lease.

@cxcx_avjj

Hummm.

After a success login, I simply redirect the user to the known :

95300287-8e35-4a7f-823b-a26585729c92-image.png

as that would make the user understand he is 'online'.

But I could also redirect to a "home made", locally available web page, like the portal login page.
This file should be uploaded with the Services>Captive Portal>CPZONE>File Manager
Be aware : the prefix "captiveporal-" will get prefixed.

Take a look at what this button shows you :

c3c27d9a-d1d4-4fb1-9c2d-c7c7bc0515fc-image.png

You will see the login page.
And more important : the URL used, with the port number, as it is not port 80 (http) or 443 (https). Probably a 800x port.
And the zone ID used with a parameter called 'zone'.

So, this is posisbile :
ec125b9e-23a2-4703-86f7-640e3760853a-image.png

Where :
https://portal.yourzone.tld = your captive portal URL - I'm a https access
:8003/ The port of this 'cpzone1 ID access
captiveportal-recap.html My home made file called 'recap.html'
?zone=cpzone1 My zone ID of this portal zone

The "recap.html" html can have use PHP !
And because you can use PHP, and the recap.html is called with the "?zone=cpzone" parameter, you can now access whatever you want !

Take /usr/local/captiveportal/index.php as an example. You'll see how it extract the zone argument.
If, for example, you use vouchers, you can test vouchers for time left : Status > Captive Portal > CPZONE > Test Vouchers
Just take a look at /usr/local/www/status_captiveportal_test.php and you'll know how to extract the time from a given voucher.

How do you know what voucher is used ?
Well, your 'recap.html' can obtain the IP your device is using.
With this IP, and the "connected users database" (see /etc/inc/captiveportal.inc - this file is a must-read-and-understand) you can get the user login code, which is the voucher code.
With the voucher code you can obtain the time left.

Want to know what the default popup logout window does - or how to log out a user?
Again, go have a look at /etc/inc/captiveportal.inc

So, yes, the sky is the limit.
An yes, this goes beyond what you can find in the GUI.

@gertjan The suggested system patch fixed the issue. Thank you!

@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

Feliz fin de año a todos y que la pasen bien.

Después de investigar mas sobre las reglas del firewall, el portal cautivo, dns resolver y sobre las Zonas desmilitarizadas (DMZ), pude solucionar el problema de la redirección del portal hacia mi servidor web, tuve que borrar algunas reglas anteriores que en mi caso no son importantes.

Luego de configurar la interfaz de la DMZ, darle acceso a la red LAN con las reglas del firewall, le di un dominio a la ip del servidor WEB con el DNS resolver y en el portal cautivo en "after authentication redirect" colocar ese dominio, tuve como resultado que cada usuario que se conecte a mi router pueda ser redireccionado al portal cautivo y de ahí autenticarse con solo hacer click al botón que está por defecto del pfsense (Que con un poco de css, html y no puede faltar javascript voy a cambiarle el estilo con respecto a mi proyecto) de ahí ser redireccionado a mi pagina web al fin.

Bueno no del todo, mis pruebas se limitaron a dispositivos móviles en el cual no me ha dado el resultado que pienso que debería dar, ya que por lo menos en android al conectase de manera intuitiva (no por el navegador si no por un programa que desconozco) me lleva al portal para autenticarme, clikeo el botón y me redirecciona automáticamente a mi pagina web pero al pasar 1 o 2 segundos se cierra el programa que abre el portal cautivo y claro por ende ya me deja navegar e ingresar de nuevo a mi pagina web, pero ya saben tengo que abrir el navegador y tipear la url, la idea es que se quede en la pagina que me redireccionó ósea en mi pagina web.

Me imagino que en otros sistemas operativos diseñados para computadoras eso no debería pasar ya que el usuario tendría que abrir el navegador, buscar algo y por naturaleza del pfsense ser redireccionado al portal cautivo, y como ya está en el navegador este no tiene porque cerrarse como me pasó a mi en el celular.

Solo me queda arreglar eso y bueno, tal vez me aventure a buscar manera que los usuarios no busquen otra cosa fuera de mi servidor web, que ya con una regla de firewall les quito el acceso a internet pero me gustaría que fuesen redireccionados al mismo si eso pasa.

Buenas noches.

@Gertjan Thank you. I'll try to find right web-portal to ask my question than. Have asked this on StackOverflow but I am still ignored there ))