@jenskiebee said in will not appear the sign-in webpage on IOS:

think

I use the pfSense captive portal for a hotel.
I do not instruct people - hotel clients -how to connect - I give very few information.
I presume they all know that hotels have captive portals. That is, no one even knows its a captive portal. It's just a wifi network called "MyHotelWifi", so people connect (think about it : they are actually that stupid .... )

I do not know what device they use, it could be the latest iPhone Pro 13, the green version, or some ancient Welcome device from Amazon. A PC with any OS, a tablet ? I don't care.
All these devices, as they are all 'portal aware', do the same thing : upon connection to the portal network, mostly Wifi, but it works just fine with a wired connection, the device should use the very default DHCP negotiation.
If the device is suing static IP settings, it's game over. The portal won't work, as does classic networking most probably (that is, it could work, but settings must be right).
When the network layer is set up, the magic happens.
This magic is part of the device, the OS used. A captive portal is not a pfSense thing, it's supported and handled by the device the client uses ( !! )

After the DHCP sequence, you can see what the device (my iPhone) does :
( Status > System Logs > System > GUI Service )

03-21-2022 08:50:51 Local5.Info pfsense 1 2022-03-21T08:50:52.000000+01:00 pfsense.local.net nginx - - - 192.168.2.222 - - [21/Mar/2022:08:50:52 +0100] "GET /index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html HTTP/1.0" 200 1641 "-" "CaptiveNetworkSupport-428.0.0.0.1 wispr"

You can see the encoded

http://captive.apple.com/hotspot-detect.html

because I'm using a captive portal, the http (port 80) traffic gets redirected the captive portal web server (nginx) of pfSense, which runs on port (my case) 8002.
This will not return the expected word 'Success".
This means user interaction is needed, as their might be a captive portal.
No web browser was open at my iPhone, so the iPhone will launch a stripped down Safari instance, and repeats the URL.
Now the login page shows on my screen, as by magic.

Keep in mind : it is not the captive portal web server that pushes this info the the users device.
It's just a classic http url that got redirected to another url.
Because http accepts redirects, the OS follows the redirections, and shows the page.

You know : this will not work with https requests, as your browser will refuse redirects to other urls (that is, you browser will redirect, and also retrieve a certificate. This certificate should contain the domain name of the url).

I am using the https version of pfSense captive portal. This works because the initial http:// got redirected to a https:// page. This https:// is the local captive portal login page.
After successful login, the pfsense captive portal takes the "&redirurl" argument, which should contain the original url, and redirect (again) to it. The portal firewall is now open for this device, the initially request page shows up.

If the captive portal doesn't seem to work, look at troubleshooting Captive Portal.

On the pfSense side, there is one thing that should work perfectly well. It's the same thing that most admins think they understand well. Its the same thing that they "break" : DNS.
The default pfSense DNS settings will do just fine.

@undrblack

Without knowing the details :
When you remove the 'virtual' part, that is : running pfSense with 3 real networking interfaces, bare bone, your issue will be gone. I can imagine the vitual interfaces / switch can be set up many ways, some of them could be wrong ?
See also Virtualization ! if you have a Windows 10 (Pro) orMS SErver : use the build in Hyper-V : I've one running iwth Hyper-V, and it works fine. There is a detailed step by step setup guide in the doc.
When a client connects to the Wifi, can you see the DHCP server log 'lease' attribution on the right interface ? What was the IP/mask/gateway/DNS received on the client ? That info should correspond to with the pfSense portal NIC.
pfSEnse doesn't handle the the AP <=> Client radio (wifi) connection.
if the AP is an AP and router, the pfSense portal only sees the IP and MAC of the router, not the IP and MAC of the clients. Ones a first client is logged in, all the others will pass without seeing a login screen.

@gertjan Okay. this is another screenshot without power being off or reboot
Screenshot.png
You notice it was 6184 MB and it went back to 6 MB

@stephenkwabena

No actual commands.
I was using a mouse.

If you don't know how to look at a file :

@gertjan said in PFsense 2.4.4 FreeRadius Mac Address Authentication Qouta:

Have a look at /var/log/radacct/datacounter/daily/ - see the files yourself. That makes under stand things much faster.

or what it means, then IMHO : it's not worth looking.

You could use the pfSense GUI, or, go for a free program like WinSCP.

@johnpoz
Hello
You are probably right.
The reason i am using the wan port, is that the pfsense box is just added to the existing network and not using it as a firewall but captive server. There are diffrent servers running on the lan and i am not familiar with pfsense yet and, i suppose i get lot of trouble if i connect the box between ISP router and LAN. There was a lot of work and studying when the isp router was setup with openvpn and forwarding to diffrent servers. I assume if i connect pfsense in between i would need to forward everything through the pfsense.

Would it be better if i connect my local network to the LAN port and use it as a gateway for opt1 ? leaving wan disconnected?

@mbunal said in wpa2-enterprise with captive portal local user database.:

is this poosbile to do wpa2-enterprise with captive portal local user database???

You didn't mention what AP you use.

When I select "wpa2-enterprise" on my AP, I see :

569aa95a-9444-4b2e-b2aa-1153059225d9-image.png

The pfSense local user manger is not accessible outside of pfSense.
FreeRadius is ... as radius is an know Enterprise Auth tools.
FreeRadius is available as a pfSense package.

It's ok for me. The patch has fixed the issue. Thanks.

@naing-linn-oo 6500+ Users in Captive Portal, 4 Gigabit PPPoE WAN Working successfully...!

6400 Users.jpeg

Read https://forum.netgate.com/topic/170300/new-system-patches-v2-0?_=1646343673426 - Apply patch (Redmine #12834) and case closed.

@hugoeyng

Read https://forum.netgate.com/topic/170300/new-system-patches-v2-0?_=1646343673426 - Apply patch (Redmine #12834) and case closed.

@qaiserajaz said in Concurrent user logins Issue:

and use 2 devices simultaneously

Using the same login credentials I presume.
That's not possible.

3cc49a0c-6f81-4f24-b9b0-f40bc2d3156b-image.png

The most logic "last login" means : upon login, if the same login credentials were already used with a device (MAC + IP pair), then existing connection is removed.
"First login" : Ones login credentials are use, and the connection is withing the soft and hardware time out, no other connections with identical login credentials are accepted.
Multiple : identical login credentials are accepted, with multiple devices.

Disabled : I don't know. This would be "Last login" or "First login".

Someting as "x users per login" is not an option, if you use the captive portal with the build in User manager.
Things change when you use the Freeradius pfSense package, where a "x concurrent logins" is possible.
The good news : it's Free.
The bad news : you have to set up a Radius server ;)

@ricardopeu

Yep, since 2.6.0 the captive portal doesn't pass UDP and ICMP traffic any more.

@gertjan said in Captive portal, certificates and chrome-Edge:

@jperezme said in Captive portal, certificates and chrome-Edge:

When I connect via Wi-Fi to the captive portal, it automatically opens the browser,

Using what URL ?

Before i got http:\172.30.0.1 but then i have added portal.mydomain.local on host overrides in dns resolver.

A final solution would need a real domain name (you have to rent one).
Then use the pfSense acme package, and get certificates for free, these will be accepted by any browser. This solution is not needed when you as the admin visit the pfSense https GUI ones in a while. You know why and what to do.
But if you use a captive portal and you want to use the https portal access, you have to have a certificate that is trusted 'out of the box' by everybody, as you can't ask to everybody upfront "whatever you see when you connect to our wifi, accept it". Why would they, the unknown to you portal users, trust you ?

Forgive my ignorance, but I don't understand how I can configure an external domain for my captive portal to work if my local network is internal.

Not yet, we are still looking at this.

@iahmad

Why would a user want to type in that URL ?
The (a) captive portal is detected by every OS these days.

I use the captive portal for a hotel, and I do not publish any URL, an certainly not an IP based URL. Still, everybody can login without any assistance from me, or some printed help.
I use https://portal.hotel.tld as the URL that points to the IPv4 of my captive portal interface.
I have to own (rent actually) the domain hotel.tld so I can get a certificate that is trusted by every browser and every device.

All OSs these days do a hidden http (not https) request to a know URL that should return a page that says "Succes". If it doesn't, it kicks of the default browser with the same URL again. The web request gets intercepted a second time, and the result will be the default login page. The user can interact with that page : he/she can login.

For all this to work :
You use https : you need a certificate signed by a trusted source (ie Letensrypt). Otherwise most browsers, if not all, will just don't want to load the page.
DNS on the captive portal interface should work.
On the Services > DNS Resolver > General Settings page I declared a Host Override :
Host : portal
Domain : hotel.tld
IP : the IP of the captive portal

Nothings stops you from declaring something like :
Host a
Domain b.c

So know the user can type in https://a.b.d:800x/index.php?zone=yourzone
The "index.php?zone=cpzone1" part can't be "shortcut".

@skilledinept

A 'captive portal' needs a IPv4 IP and network - and a running DHCP server for that interface.
Unbound needs to listen on that interface.

Because you use VLAN : the device at the other end of the 'LAN' cable (over which the VLAN "5" is running) need to handle VLAn's and set up to sift out this VLAN5.
That could be your AP's), or, by default, a VLAN capable smart switch.

@07stuntar1

The 'portal' should have access to the clients IP and MAC as these two determine what client has access. So L2 ok, not L3, as a down stream router would hide the IP and MAC.
The client should use the DNS of pfSense.

@07stuntar1 said in Captive Portal over L3 link:

Currently when enabled the captive portal cuts off network access to the client.

That's what a portal does.
A portal interface is typically a second or third LAN type network to which non trusted devices can connect. Most, if not all, devices these days detect the portal, and the login page will auto load. DNS should work to make this happen. https access is advised.

@esojmc https://docs.netgate.com/pfsense/en/latest/captiveportal/index.html#not-capable-of-reverse-portal

A reverse portal, requiring authentication for traffic coming into a local network from the Internet, is not possible.

@Gertjan @free4

The radius server is served via the internet. Its not LAN based. Does that matter? Re authentication does not take that long at normal operation.