Captive Portal - Change redirect from IP to a DNS name
-
Hi Guys.
Complete novice here with DNS resolvers and SSL certificates, so please bear that in mind when replying.
I am installing a SG-5100 in a hotel and they need a terms and conditions page.
Having set the page us with a custom HTML template works great.
However, I need to make sure that the customer can reach it manually if their device does not bring up the page automatically.
Currently, after logging into the wifi, a firefox redirects to 10.10.0.1:8002/index.php?zone etc... (it's a massive entry).
I'd like something simple like portal.hotelname that looks a little more professional, and where the customer can easily be instructed to type this address manually to get to the page.
As mentioned, I don't know much about DNS and that kind of thing. It's also hards to google what I'm trying to explain, so if someone can point me in a direction that would be great!
In addition, It would be great to also allow HTTPS but I don't like the sound of renewing a certificate every 90 days. Not sure if there is an explanation of how we can allow HTTPS.
Thanks in advance
-
@wifi-will said in Captive Portal - Change redirect from IP to a DNS name:
However, I need to make sure that the customer can reach it manually if their device does not bring up the page automatically.
I'm using the pfSense captive portal for a hotel for more then a decade.
Way back in the past, I mentioned the in the instruction the FQDN to visit if the portal didn't show up on a user's device.
But this isn't needed any more.
Today, there is no OS out there that doesn't support auto captive portal detection. I didn't saw users using a "Apple iPhone GS from 2009" (just to name an example) that doesn't work with pfSense's captive portal. These devices just can't exist any more.@wifi-will said in Captive Portal - Change redirect from IP to a DNS name:
As mentioned, I don't know much about DNS
Technically, you don't need to know anything about DNS. The default pfSense DNS settings work fine.
( but do you really want to fly the plane without a pilot licence ? ;) )On the DNS side, all you have to do is add a host over ride :
where "my-network.tld" is already declared as :
Make use (keep !) of the default pfSense settings like
LAN is and stays 192.168.1.1/24
The OPT1 interface will be your captive portal interface, 192.168.2.1/24 - add a switch to this interface and all your access points.
Get (rent !) a domain name - make sure the registrar offers a "acme" update method. Use the acme package to get and keep the cert updated. Just ask for a wildcard cert like *.my-network.tld". Use this cert on the captive portal's https settings page (and for the pfSense GUI will you're at it)
And your done, portal https access for the portal works fine.You can always inform your clients that they could use
https://portal.my-network.tld:8003/index.php?zone=cpzone1( but do you really want a 'client' to type in such an address ? ;) )
Take note : the captive portal is not (can not) using the default https port 443.
Their has to be a "?zone=xxxx" parameter.
Use this button :
to discover what your port number is : Mine is 8003, yours could be different.
same thing for the zone identifier : mine is "cpzone1", your will be different. -
@gertjan Thanks for the detailed reply.
A few takeaways are;
-
The standard setup should work perfectly and there shouldn't really be a concern. If a client needed to type in an address however, does that mean they would have to type the full URL?
-
DNS host over ride can replace the IP address, but it wont get rid of all the information after it such as /index.php?zone=portal1 ? Ideally, the only address would be portal.hotelname.net or something
-
HTTPS needs to be dies to a real domain that we would host. Such as a subdomain on our website or something? It would need to offer ACME and then I would have to set it up with the ACME package in the netgate? But you think HTTPS may not be needed as HTTP works fine for most devices? If I was to setup ACME, would that achieve the desired result of the portal being reached at portal.hotelname.net?
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?
Appreciate your time.
-
-
@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.tldthere 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
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
