@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 : [image: 1694757233977-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 : [image: 1694757428967-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. [image: 1693028807354-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.

Please check here for a tutorial installing Freeradius with a modern Web GUI: https://administrator.de/tutorial/freeradius-management-mit-webgui-6972997853.html

@viktor_g Why you are talking about custom error page while the CORS issue with PORTAL_ACTION URL?

@hsrtreml Google gave me a good tip. I asked : Mac Pro OS 12.6.8 captive portal connect and found a probable issue. The thing is : you've probably used this device already to the SSID and router/firewall pfSense when there was no captive portal activated. So your MAC is not going tot auto prrtal detects, as it knows that that isn't the case - but now it is. Solution : delete the SSID profile in your MAC, and connect again. This time, the captive portal detection will work (because it's, after all, a new 'unknown' network).

@Gertjan hello, thank you for your suggesion i will try to scan the disk

@prochid thank you

@Gertjan Thanks to reply..

@mindf No DHCP .... No MAC filtering / let's hope the client can still do some DNS against 10.1.1.1, as that would give you (might give you) the "auto portal login page". I guess that's not possible as your devices use static IP settings. For me, the captive portal is a LAN NIC thing. Wireguard, is a WAN thing. I've been using an OpenVPN client for a while, and my setup was : LAN devices are all using the WAN, this was the pretty straight classic setup. And all Captive portal users on NIC LAN2 (another LAN) are routed out over the OPENVPN client (so tunneled over my WAN) and ended up somewhere in {whatever I had chosen as an end point}. I presume that 'OpenVPN' or 'Wireguard' is just a choice, both should work. When you say @mindf said in [Captive Portal] No internet access after successful authentication: I have configured Wireguard with captive portal what do have to imagine ? What I've said above ? Different ? Btw : cpzoneid_2_auth/10.1.1.2_32 rules/nat contents: ether pass in quick proto 0x0800 l3 from 10.1.1.2 to any tag cpzoneid_2_auth dnpipe 2000 ether pass out quick proto 0x0800 l3 from any to 10.1.1.2 tag cpzoneid_2_auth dnpipe 2001 that looks fine. It's a authenticated portal user. The next hurdle would by : the rules you have on the GUI portal interface firewall list. If that one contains a pass (all), then your traffic enters the interface, is in the 'system' and ready to be routed (out == leaving some other interface).

@bendida I have the same problem after upgrading to pfSense 2.7

@guntery said in CP using IP address for radius session not username: nothing to do with radius or auth. I agree. @guntery said in CP using IP address for radius session not username: it disregards mac and username It looks like that portal_allow() returns with the $sessonid. Portal firewall rules are not modified, so, while the IP is the same, the MAC will be different. No login page is presented, and no "Internet access" : that's your issue ? That is, I could not create a situation with my setup where another device (another MAC) was using an IP that had already a session. Typically, for my usage, Idle timeout (Minutes) is set to 360 and Hard timeout (Minutes) is set to 720 or 12 hours. The latter will remove sessions. My DHCP leases on my captive portal are set to 86400 sec or 24 hours. @serginho said in CP using IP address for radius session not username: for the developer to recognize and correct this error Feel free to enumerate. And as you walked through the code, you should be able to add lots of details.

@Chooks said in Captive Portal not redirected after successful login: I'm using the latest version. 23.05.1 ? This : [image: 1688710246161-3c06064e-e679-421e-b8ef-8ae0286e7c88-image.png] looks like the OS - or program - knows or suspects that the device hasn't a direct Internet connection. It's part of the portal detection. Normally, the GET (www.example.tld)/connecttest.txt should return a 'page' like this one that shows the word (for example) "Success.". If it doesn't, because another page came back : the pfsene captive portal login page, the OS should pop up a message, notification, or even a browser directly in front of the user. If it doesn't do that ... well ... After successful portal login : [image: 1688710845403-d7c6be7a-64af-4e2d-88fd-3c4917acbd46-image.png] 192.168.2.6 - - [07/Jul/2023:08:19:56 +0200] "POST /index.php?zone=cpzone1 HTTP/2.0" 302 0 "https://portal.brit-hotel-fumel.net:8003/index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html" "Mozilla/5.0 (iPhone; CPU iPhone OS 16_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148" 302 = Redirect. You can also see the URL parameter "?zonecpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html" see the "http://captive.apple.com/hotspot-detect.html" : [image: 1688717282186-b8693d06-cfb9-4078-b69a-94e313943dd0-image.png] Because I've set : [image: 1688713813218-9582e267-23f6-4b26-a378-ec51189fede9-image.png] I was take to https://www.google.com/ If my "After authentication Redirection URL" was empty, I would see the [image: 1688717455410-fd83eba8-4ed9-4cab-ab1f-c7778b48ea29-image.png] and that's a bit stupid. But correct my iPhone wanted to go to that page (that page because it uses it to detect the prence of a captive portal). When the captive portal authentification was done, it will show the page. My phone is now happy : the device has a working "Internet connection". Look at /usr/local/captiveportal/index.php - that is the page PHP that shows the login page. But it does more then that. See /etc/inc/captiveportal.inc tells the whole (rather complex) story.

@susobaco I answered you in your post. Please create a bug yourself - maybe you can better convey to the developers with your words that it is a regression of this current firmware. Then note the device key under "AutoConfigBackup" and reinstall to 2.6.0 and restore a config from 2.6.0 with the device key. Then we'll be right back. Let's hope that the developers will adjust the firmware and get the captive portal up and running again.

@dochy Ah. Your using an ancient version. [image: 1688382846934-5ae2a4b1-a046-4732-8a2e-edc2aded1058-image.png] That's ok of course, but I can't recall what I did 'yesterday'. And before yesterday, I was using 23.05, and before that 23.01 and before that ... 22.0x and before that 2.6.0. 2.7.0 isn't ok for you ? I suggest you use the use the "forum search", as I'm pretty sure some one has writing about mysql in the past. Double check the PHP version pfSense 2.6.0 uses.