@gertjan Ahh I see, so it's not a secondary login, it's a backup login.

Thanks again for the help.

@yogi_en said in Help Needed!. Captive portal not working ( No login page ):

I didn't get any pop browser or captive portal login.

Ah, I'm curious.
What OS / what device ?

When you buy a device from here it works, and as far as I know you, as a user, can't do a thing to stop this process. As Apple checks accepting an app on their platform.
Other brands : they care less ?

Windows : I've tested 10 'home', 'pro', 11 home (burk) and 'pro'.
I even debloated them (see Youtube about that) and portals are recognized. That is, you still have to spot the tray notification message and act upon it.

I've seen people using some high end (consumer high end that is) firewalls/antivirus and they had set up : "only trust my home wifi network" so now their security was great ..... and moments later they want to use their device on my wifi network ....
Yeah, that was a fail .... as the device was following the original instruction : do not trust / use 'other' networks. So they went for the Hall 200 problem : do not give automates conflict instructions, as they will bite (the example : kill) you.

@yogi_en said in Help Needed!. Captive portal not working ( No login page ):

I even tried a local url http://192.168.5.25:5000

Portal firewall rules will redirect port '80' and port 443 if you use https.
So port "5000" : you hit the wall.

Use these :

6cc8be0f-9940-4ffe-bfd8-17e55af044a9-image.png

to test the portal web server.

Or, when connected to the captive portal network, as soon as you received an IP (DNS, gateway, network) : use http://192.168.10.1:8002/index.php?zone=ZONE

where ZONE is your zone ID.

Btw : http://captive.apple.com/hotspot-detect.html should also work as this is a http thus port '80' TCP request.

@yogi_en said in Help Needed!. Captive portal not working ( No login page ):

DNS server is my router 192.168.1.1 ( which I cannot ping when CP is enabled ).

I have to shave-up your definition of a captive portal.
A captive portal allows minimal interaction with itself.
If 19.168.10.1 is your captive portal pfSense interface, you can :
Do DHCP
Do DNS requests on port 53, UDP and TCP.
Port 80 (http) listens to you.
Port 443 (443) listens to you - if you've activated that
Ping the captive portal pfSense IP
You can NOT go to some other network, and that includes your local networks like 192.168.5.x

So, right, the portal works : no ping or whatever to 192.168.5.x

I just tested :
I've connected my phone to the captive portal (as the stupid thing does not accept the wifi connection without a login first).
With an phone app I launched a 100 times ping to the portal interface, that was 192.168.2.1 for me.
It replies constantly.
Then, in the pfSense dashboard GUI, I removed my phone's connection.

The ping app in my phone continued to send pings to 192.168.2.1, and 192.168.2.1 continues to reply. Or, at that moment, from a captive portal firewall point of view, my phone was disconnected.

@gertjan Do you know what I can do with it?

Here's my most recent logs by the way.
60f67b9e-a786-4435-9cfb-cf5b69c0b810-image.png

@heper I am on the latest stable version of pfsense 2.6.0

Well, I am rather sure, after about 8 years he did found a solution...🙃

Regards

@adnan97

From what I recall , these issues were solved with patches pfSense package ages ago :

4dcf0368-291d-486f-9000-c36f26764e2e-image.png

The bad news : you have to dig them up, here, in this forum or redmine.
The good news : 2.7.0 - coming out soon - will take care of things.

I was using 2.6.0 quiet long time, and issues (important to me) were solved after some forum interaction.

@david6464 said in Voucher expiry:

Can you send me screenshots of your captive portal and freeradius config?

Of course.
But before we compare apples with oranges, I'll describe my setup.
I have a dedicated 192.168.2.1/24 captive portal network interface.
I'm using the "https" access with known signed certs - I use acme.sh - this isn't related to your question I guess.
I'm using my own login and error page, just to add some logos etc - the internal html is identical ti the build in pages.

cpsettings.jpg

The auth server settings page :

9796d5cc-72a2-4a9f-8db0-b993c1a4b572-image.png

FreeRadius :
I have a bunch of users :

9796f809-cd8e-49f7-b3f2-23d36b9c4ac1-image.png

Most of them have only there 'name' and password set.
User '001' has a daily limit of 600 seconds.

Keep in mind : I use Radius, but are not really bit counting, are rate limiting, or whatever.
I'm not selling my access, and I don't have to educate kids or so.
My portal has one rule : if it works for you, then that's fine.
If it doesn't, then you (the portal user) has an issue - not me ;)

The MACs page is empty.

f32b9571-5ae0-4190-a1af-60db30e0a87e-image.png

75ff5cfc-16f4-443d-823e-8dbe58d13128-image.png

78b102e0-0c18-419e-9051-198c907e74ab-image.png

d63eda76-1ab3-465b-896b-fe7ccd408ba6-image.png

Note : the FreeRadius cert was auto generated ? I don't remember any more. The Youtube => Netgate FreeRadius movies will help you.

4193c5f4-102e-4f1c-99ac-4bb475feff22-image.png

Note 192.168.1.33 is my Synoloy NAS with the SQL server.

The last 3, LDAP View Config and XMLRPC Sync are not used by me.

Last image : My Mariadb (SQL) database with the tables.

fe060bb6-7f1e-44bb-9e79-7b48d1f1e361-image.png

Note : keep in mind : The pfSense FreeRadius package is a partial implementation of what FreeRadius can really do.
A lot is hard coded in the FreeRadius config, as bringing them to the GUI would be ..... mission impossible.
To understand what I mean look here : /usr/local/etc/raddb/ and have a look at
ALL the files and ALL the files in ALL the sub folders.

The main file is /usr/local/etc/raddb/sites-enabled/default , it all starts there.
Most of it is purely hard coded.

FreeRadius is complicated.

@harias

You should go here.

These are the ones you need :
IDS/IPS : as packets need to be inspected to know what a user on a LAN does.
Cache/Proxy can might also give information.

Both go way beyond (like a light year) of classic firewall / router management.
You asked for the full control of whatever traffic flows through pfSense.
This means you have to know for real what happens, and why.
When that is the case, these tools will do the dirty work for you.

A guy from Chine (of course) said ones : "You can only fight the dragon if you know what it looks like".

Btw : Freeradius can checks used ID, user hardware ID (MAC, IP) and bytes consumed. And clock the connection over time, and grant access basd on what ever criteria you chose.
Freeradius doesn't know anything about the traffic - or destination, or what it contains.

@gertjan very interesting. Thank you for this.

I was on a few 'premier' captive portals recently - American Airlines/GoGoInflight and a large state university - and I realized that they don't use the 114 option either. It's easy to break the Guest Wifi workflow though with iOS and Mac; just ignore the window the first time. Their Captive Portals don't redirect https either - so you have to know neverssl.com or something similar to get back to the portal.

Returning to the solution and discussion: setting the iOS device to see the 114 option is super easy. However, after I do my auth - the iOS requests again to the url, but now I have no context. I guess this is primarily because the IP address is forwarded from the pFSense. Even if I use Tailscale or Wireguard to get all the devices on the same network - pFSense / Netgate box is forwarding the request, so I can't tell who is coming in based on the iP address, nor mac address.

Am I missing something? After you got the 114 login portal working, how did you redirect the iOS device to a 'captive: false' json? I'm missing that part.

@lucas-2 said in Captive portal does not load google account authentications:

Google's hosts are all allowed, and so is authentication with Google's IP allowed, in the "Allowed IP Addresses" settings.

Check blog post again. No need to allow hosts.
Freeradius, running on pfSense, can access freely all IPs on the Internet, as it is just an outbound connection over WAN.

Netgate's blog post is written with pfSense 2.6.0 (or 22.05 Plus - identical I guess) and it should work.

@viragomann
Oh sorry I didn't know that.

Yes, the VLANs are defined as a virtual interface.
Yes, the captive portal was activated on an explicit VLAN.
So the VLANs that are on the physical LAN interface are tagged. The physical LAN interface can be reached via all VLANs.

9aba8909-bc04-4489-be6c-77532ecdca1b-image.png

This is just an excerpt, there are only other VLANs below.

@tapabrata

Did you ever get a solution to this?

Hello,
Thanks I'll try, I'll let you know

@jorge-igor said in Captive Portal x NXFILTER x PFSENSE:

NXFILTER

Easy answer : do not do that.

Portal users should be connected directly to the pfSense captive portal interface (passing trough cables, Wifi, switches etc)
That is : the client's IP and MAC should be known to the pfSense portal.

@unreal516 said in CP and DHCPD Issue 2.6.0:

I have tried rebooting the CP service

The captive portal isn't a 'service'.
A web server, a copy of nginx, is started and listens on port 'localhost' (127.0.0.1) using port 800x and 800x+ (if you are also using https).

Because you want the DHCP server to work for your clients (static IP setup for not network aware clients) won't work ;) you have set up a DHCP server for your captive portal network.

Normally, your "vmx1" should be your LAN.
The captive portal interface should be ... vmx2, some "OPT1" second LAN type interface. As I advice you strongly to put your trusted devices on a LAN and the not trusted devices on another, OPTx network, dedicated for portal users, who are nontrusted by default.
Otherwise : if you trust them, why bother : put an AP on your LAN network, give them your SSID password and you're done.

Btw "vmx1" means : you are using a VM ?
My advise : great ! But first make the portal work on a bare bone, and when it all works out very well, go add another layer of complexity.

"dhcp.c:4164: Failed to send 300 byte long packet over vmx1 interface." means : there is an issue with the vmx1 interface itself. Not some firewall issue.

Btw: the captive portal "ipfw" firewall rules, used by the captive portal, pass all DHCP (and DNS) traffic by default. You don't need to add "DHCP" type firewall rules on your vmx1 "pf" firewall
rule tab.
Also, firewall rules, pf and ipfw, filter incoming traffic. That is : traffic oming INTO the interface.
Your error shows an issue with outgoing traffic, traffic generated by the dhcd (with a "d") server deamon.
Your "dhcp" : is this an error from the dhcp client, typically running on the WAN interface ?

Also : can't remember any more, wasn't there an issue (bug) 2.6.0. with "captive portal only accepts TCP" (and not UDP and ICMP) ? This would explain DHCP == UDP issues.
What are your patches ?
Using the pfSense System patches packages is not optional anymore ;)

@michmoor Thanks, i didnt check if they got an IP. I will have to do more testing. With their MACs in the pass list, is it known that they do work? All the other devices were fine. Not using VLAN.

Thank you!!