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

@coach

Remove the cisco 4221 router. Just use switches.
See that the the portal works. See that it uses IPv4 and MAC addresses to function.

Just for my own curiosity : Really, a router on a captive portal network ? Where did you get that idea from ? Not the pfSense manual.

@moelharrak said in use FQDN instead of IP:

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,

4326294f-5a70-43c7-9230-8f72cec8e469-image.png

and the FQDN "portal.pfense.whatever.tld" for your portal

Inform your unbound resolver about the host override "portal.pfense.whatever.tld" :

c0da646a-d8e7-4094-bd34-ec3b6d210c43-image.png
where 192.168.2.1 is your captive portal interface IP.

Now, select the https access on your portal :

21d77874-ffdd-4297-99d5-56bdf16f891b-image.png

Done.

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.

Experimented with & on an Intel box.

ie:
ipfw table CaptivePortalZoneName_pipe_mac add any,04:33:C2:64:65:E1/&ff:ff:ff:00:00:00 3002
ipfw table CaptivePortalZoneName_pipe_mac add 04:33:C2:64:65:E1/&ff:ff:ff:00:00:00,any 3003

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.

Thanks @jimp

Adding an "Allowed IP Address" of 239.255.255.250 for SSDP (Roku Discovery, DLNA Media, Sonos, UPnP + More) to the captive portal did the trick. Thanks a bunch

I've also added 224.0.0.251 for mDNS / Multicast DNS (Chromecast Discovery + Bonjour + More)

Works like a charm now :)

You mean this file /var/db/captiveportalxxxxxxxx.db ?
This is SQLite3 file - it says so itself :

e2f234dd-8c71-464e-9d6d-33c449cfd7b0-image.png

As pfSense, you need this to interact with it.

Good news ; pfSense has the sqlite3 PHP extension loaded.

Friendly warning : the simple fact you had to this (IMHO : simple to find out yourself) means that you should not 'mess' with it.

Removing a 'record' in that database is can be done with these button button :

aa81f840-6474-4ec2-9c35-c79fa76a83d4-image.png

The other info stored in it (per record) is :

allow_time INTEGER,
pipeno INTEGER,
ip TEXT,
mac TEXT,
username TEXT,
sessionid TEXT,
bpassword TEXT,
session_timeout INTEGER,
idle_timeout INTEGER,
session_terminate_time INTEGER,
interim_interval INTEGER,
traffic_quota INTEGER,
bw_up INTEGER,
bw_down INTEGER,
authmethod TEXT,
context TEXT

Changing these values isn't useful, the underlying captive portal "ipfw" firewall rule won't get changed.

i solved this problem thanks.

@thisislivin said in Block MAC Headers from known hacked devices:

Pfsense newbie.

As we are all learning every day, So I guess we all are.

But you can shift from "think you know" to "know you know" just by looking at something like this :

Youtube Video

It starts with a wire, 8 conductors .... easy.
By the end, you know what 'networks" are, what and IP address is, and a MAC address.

SupporteATECH asked :

c6dfb0bc-f2f7-4683-badd-17470fa3c326-image.png

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 :

bd467ce7-b111-4982-9613-966fde1eadf8-image.png

So this is the SQL3 database file that contains all the users that are connected :

81ecd1fb-4825-4062-bf6b-9871f40f41cc-image.png

This file is wiped and created on restart.

If this option is set :

8a7dd18b-32b1-44bd-a6d7-55c145b52dd9-image.png

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.

It works for me ©™

I'm using 2.5.1 CE.

@sanctify said in 1 User Per Voucher Code:

@gertjan how do you upload or install this patch on the Pfsense that's these "1 User Per Voucher Code"?

That question was valid in 2016, that's 5 years ago.

These days, you select :

1a3997c6-e867-4d97-b29f-6a38cc9bd176-image.png