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

@owenv said in Image URL in captive portal not showing:

I’ve added the domain name AWS bucket as a host name but even with this the image won’t show

Connect to the portal without identification.

Can you use / visit / see the AWS rule now ?
Keep in mind : a firewall doesn't use URLs or host names for that matter : it only understands "IPs" so if you use a host name, it should be present listed in the allowed host names and now you have to hope that the IP (only one IP !!) it resolved to is the correct one (AWS is typical for using a lot of IP addresses, not just "one").

See here : Allowed Hostnames - the first Note.

@des000 said in Captive portal and subnet:

want to transform dd-wrt into an ap

4760f5b0-081a-40eb-a817-de3b34fc97bb-image.png

Disable WAN.
Give it a static IP, like 192.168.2.2 / 24
Gateway and DNS is 192.168.2.1 - my captive portal pfSense interface.
Shut down the DHCP server.
You might even assign the WAN port as anther LAN port, if needed.

I've 4 of these (192.168.2.2 -> 192.168.2.6)

Btw : Wifi network security :

3f2fe97d-3986-4a01-9b39-7a742a913f73-image.png

Pretty rock solid.

https://forum.netgate.com/topic/183222/how-to-use-the-pfsense-name-instead-of-the-ip-address-in-http

The same purpose

Thank you for this feedback.

Correct me if I'm wrong but the normal process for the captive portal is as follows (on Windows 10 22H2) :

step 1: action of connection to public wifi

step 2: the PC obtains an IP address from DHCP

step 3: the Windows system attempts to connect to a url "www.msftconnecttest.com" with the LNASvc service (NCSI probe)

step 4a: the captive portal "captures" the previous HTTP connection attempt and opens the default browser. The captive portal login page opens.

step 4b: launch the browser by entering an HTTP URL and the captive portal page is displayed

My problem is that step 4a is not done. The default browser does not open. Unlike I can successfully perform step 4b.

The fact that the browser does not open is a problem for BYOD.
We cannot configure user devices...

I don't know if this is a problem related to PfSense...but in other establishments, it works with the same configuration...

@wendel_gt

2.6.0 is something of the past. It had its issues. For example, it had an issue with UDP, which was solved a couple of day later.

"But who uses 2.6.0 these days ?"

Take a look at the rule I showed above : if you are connected (authenticated if needed) to the portal, then pfSense isn't blocking you.

If you have non-default settings or a non common setup, please detail them.

@stevencavanagh

Try these settings :

Use pfSense using default settings : nothing altered or added by you.
Your device ; use default settings, so nothing altered or add by you.

Example : You could set up your device to use a DNS like 8.8.8.8 instaed of the DNS you got from pfSense.
That great, your choice.
But now the portal doesn't work anymore, as their is no DNS available until the portal gets unlocked (and for that to happen DNS need to work) : chicken and egg problem.

Another example : You've set up your browser to use DoH.
That great, your choice. Free world and so.
But now the portal doesn't work anymore, as their is no DNS available until the portal gets unlocked (and for that to happen DNS need to work) : chicken and egg problem.

Etc.

@Gertjan I've implemented pfSense on VmWare VM, with one nic(lan) on WiFi VLAN to provide captive portal for wifi client, and the other nic(WAN) on my lan network.

@goldsoft said in I am using a self-signed certificate. HTTP is working fine, but HTTPS is not.:

My certificate is the one that comes with PFSENSE

If you had a web site with a self signed certificate, yo would see the same issue : the browser would complain, as the certificate was signed by 'some one' that isn't on his 'trusted signer list'.
When you visit pfSense GUI using the build in auto generated certicate, you saw the same thing.
Easy solution : import the cert into your web browser cert store, and now its trusted.

The thing is : a captive portal, typically, is used for visitors, and you want them to be able to use your wifi.
With a self signed certificate, they should accept your unsigned cert first, or they have to import the cert .... and this is way to impractical.
If you want to use https : get a domain name, and use that domain name to get a trusted certificate with the help of the pfSense package "acme".

Btw : the https login page is only protecting the login page. As soon as the user is logged in, every site he'll visit on the internet is using https anyway. Mail comes in also over TLS.

I'm using https for my captive portal (a hotel) because its more serious to show
"https://portal.hotel-brand.tld" with a nice padlock an no browser complaints, as a login URL as is "http://192.168.2.1/...."
( Yes, I won (rented) "hotel-brand.tld")

You could do this.

@aminbaik

Captive portal, or not, you should know who connects to your network.
Portal users : you gave the login credentials, right 😊

Next time : when give them the login, ask them to give you their device's MAC address.
With the MAC, you can set up a "static DHCP Lease" and from that moment, when a user (person) connects, you == actually : pfSense, will know who it is.

=> or observe the pfSense log Status > System Logs > Authentication > Captive Portal Auth and yo can see what 'login' uses what MAC (and IP) addresses.
=> Or look at the Captive Portal Status Dashboard widget.

With the IP you (== pfSense) can do what is called policy routing.

Captive portals make often use of policy routing, as you do not want the un trusted portal users using your WAN IP. Image these users use infected devices, you'll be having troubles. See this example.

I'm using the captive portal for a hotel, and I should (as I'm actually not doing it right now) route my captive portal users over to a "VPN ISP".
Using a VPN for them can gibe issues, as, for example, Netflix usage could be impossible.
The choice is up to you.

@mra said in Captive portal issue:

My problem is that when connected to wifi1's wifi, the user who needs to log in to wifi2 will also be able to log in to wifi1. In this way, I want to create a user group for wifi1 and connect only to wifi1 captive portal.

I think I have a solution for you.
No radius needed, just pfSense.

Locate Line 263 of the main portal /usr/local/captiveportal/index.php file.
It's an empty line, just before the function

$auth_result = captiveportal_authenticate_user($user, $passwd, $clientmac, $clientip, $pipeno, $context)

where a user name and password are used to check if a user is authorized.

These are your 'zone' names :
zone1: "localzone"
zone2: "wifi1zone"
zone3: "wifi2zone"

Add this single line line :

$user = $cpzone.$user;

83d222f4-9aef-4828-8e72-4032dad7700a-image.png

Now, goto the pfSense User manager.

Example :
Let's presume you have a user called "001" that is allowed to visit your "localzone" captive portal.
Make the user info look like this :

fa0a71c4-6ec4-4059-937d-69e0b99e8fb3-image.png

If user "001" also needs to be able to visit the "wifi1zone" portal zone add another user like this :

2d5831ad-c7db-4e93-a13b-ce20cf95a3a6-image.png

@BENROFU Perfect, with wifi calling 👍

@oldschoolrouterjockey

Yeah, accepting DNS is a must have. DNS is mostly UDP btw, and rarely TCP.

@oldschoolrouterjockey said in Captive portal Help:

and also 8002

Don't need to do that.
The device will do the "http" (port 80) request initially. There is no need that the portal user needs to know that "port 8002" is used on the pfSense side.
Initial user port 80 traffic gets redirected at the firewall level to port 8002. The portal user's browser will never know it was talking to the server over this port. Or port 8003 when https is used.

# Captive Portal rdr on igc1 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80 tagged cpzoneid_2_rdr -> 192.168.2.1 port 8002

where igc1 is the portal interface, and "cpzoneid_2" is the portal zone ID, 192.168.2.1 is the portal IPv4.
A second portal instance will use, probably, port 8004 and another ID.

http portal mode is ok to "make it work".
Go to the https version, as most browsers will bark, showing warnings that will be errors in the near future, when not-TLS is used for any http traffic.
Also, the RFC1918 Portal IP won't show up anymore, the local pfSense portal host name is now used, because that's what certificates is all about.
Ones "https portal authentication" is set up, your done done with it installation. It will work well from then on.

There is a price tag, as you will need to rent a domain name. Annual fee : less then 5$ / year ?
Before you chose a registrar, make sure that it will work with "Lets encrypt", the pfSense package that will handle the automatic certificate renewal.

Advantage is : portal login goes over https, so there is no need anymore use any SSID security, the traffic is already encrypted. As soon as the user is logged in, all subsequent traffic is also using TLS : all mail, web and whatever uses TLS these days.
And as said above : portal users that want to add their own security : that's where VPN ISPs come in handy. : even you as the pfSense admin can 'see' their traffic anymore, you will have to trust your portal user ( ! ), which is actually a strange situation because portal users are actually 'untrusted' as they can do what they want with YOUR internet connection.

edit :

Purely optional :

If you have the NTP deamon running on pfSense, have it also listening on the portal interface.
Add this :
a555fc6f-40df-4909-b012-516cf32552fe-image.png
to the portal DHCP server (192.168.2.1 is my portal interface IP).
Add a rule like this :

2b7ce0ff-e511-460e-a7c2-805bd12a5826-image.png

to the portal firewall so portal users can use the pfSense NTP if they want to.

@Gertjan

@Gertjan said in Setup a Captive portal for PON Network:

I know this isn't what you want to achieve, but a captive portal 'wants' to use/see the actual client IP and MAC addresses.
A captive portal, on the pfSense side, is just a set of firewall rules. And these need these two, as there is not else to handle upon.

Hi Gertjan,
I've done to setup the whole system, and it worked.
However, now I consider to use a separate DHCP server, not rely on pfSense. Could I deploy this model? And How to setup network connection between DHCP server <--> pfSense <--> AP?

Thank you!

@Gertjan By See this "Allowed IPs, placed in the cpzoneid_2_allowedhosts anchor do not seem to use the attached pipes, pipes that should limit the flow speed." I now knew that you know it does'nt work. Which needed to be fixed :) And I am waiting when the stable version will be released which have these problems corrected. THanks

@Gertjan
What I mean is that the users are outside the work environment and through the Internet and Openvpn they can connect to the WAN interface through Public IP and access the LAN network where files and other things exist in the work environment.

Everything works fine, I just wanted to be able to limit bandwidth and amount traffic for users and I noticed that Freeradius can't limit without CP enabled and the problems I mentioned above occur when CP is enabled on the Openvpn interface. has it.

How do you limit amount of traffic for users who have been authenticate through Freeradius? I enter traffic and bandwidth daily in FreeRadius, but it doesn't work. This part only works when CP is active on the desired interface and users log in through CP that interface.

When the user is authenticated through CP and Freeradius, everything works, but when only Freeradius is used to authenticate users, the bandwidth limit options do not work, and the user has no limit.

I want to implement the following scenario, but I am having trouble.

Untitled.jpg

Openvpn Client from internet >WAN public IP > Pfsense > Openvpnserver> Captive Portal> Authenticate with freeradius > Access to My LAN

Everything is correct and users can connect and access the LAN network, but it is not possible to apply a limit to the traffic of users in Freeradius, there is an option to apply a limit in Freeradius, but it does not work on its own, and it must be used in addition to CP from This option is used. For this reason, I have to activate CP for Openvpn next to freeradius so that I can use the restriction option in freeradius, but it is not possible to activate CP on the Openvpn interface, I am now looking for a solution to apply the restriction to users, a requirement to use I don't have CP and any solution that can apply restrictions is good, but pfsense can apply restrictions to users only through CP and radius, but this method does not work for openvpn users.

I also followed this solution, but this solution didn't work either
https://forum.netgate.com/topic/141034/rate-limit-on-radius-reply-attributes-for-pppoe-connections-not-working

@Gertjan
Okay , Thank you for help

@Gertjan

Your solution involving the modification of the captiveportal_blocked_mac function in the /etc/inc/captiveportal.inc file has been tested successfully.

Following your guidance, I implemented the updated function you provided. The modifications have brought about the desired outcome, enabling us to effectively block MAC addresses using mask values.

Your willingness to share your knowledge and solution has not only resolved the technical challenge but has also showcased the strength and support of the community. I appreciate your dedication and time spent on investigating and addressing this issue.

Thanks again.