That's why I couldn't find the message. It's part of the ipfw sub system. @rennai said in need a pipe/flowset/sched number error: But I wondering why Stop wondering. It has been solved in 2.7.0 and 2.7.2.

@Gertjan Hello Gertjan. it's just anonymizing the Mac Addresses. Looks like it may be related to pass-through MACs when "noconcurrentlogins" is set along with per-user limits. "I disabled the 'Pass-through MAC Auto Entry' on the Captive Portal, and the error messages have stopped. However, now, to avoid these messages, I need to add these entries manually. It seems like a bug. Anyway, it's exhibiting some unusual behavior.

Thank you all for your answers to this issue. Truly more heads are better than one :)

@pfsenseISIP said in Captive portal slow down connection troughput: there are no firewall rules No rules on an interface means : no traffic enters that interface. Example : [image: 1708930987182-8dc5480d-c651-47ec-be79-1035f61500c3-image.png] @pfsenseISIP said in Captive portal slow down connection troughput: via freeradius installed And the basic, vanilla, just one "Portal on a OPT1", like shown on the official Netgate (Youtube channel) video's, that works ? @pfsenseISIP said in Captive portal slow down connection troughput: and the CP is on both So you have two portal instances ? Normally, LAN us for trusted devices, like the one you use for adming pfSense. All non trusted devices should belong on other interfaces, like OPT1 (portal 1), OPT2 (portal 2) etc. True, a captive portal can work on LAN ...

@AW-0 And you have a question ? If so, don't forget to detail your settings. Btw : my portal access isn't great neither. And I know why. When I plug myself into the switch that is connected to the pfSense portal, get get the full 'nearly' 1Gbit up and down, as that is the speed of my ISP. So, you get it, my APs are the limiting factor. When a portal user is connected, the user's IP and MAC are added to the 'pf' firewall table that contain the authorized users. This pf rule (tbale) is like any other firewall rule, and doesn't limit the connection. For every connected user there is a also a 'limiter', you can see them here : Diagnostics > Limiter Info and default they are : Limiters: 02010: unlimited 0 ms burst 0 q133082 100 sl. 0 flows (1 buckets) sched 67546 weight 0 lmax 0 pri 0 droptail sched 67546 type FIFO flags 0x0 16 buckets 0 active 02011: unlimited 0 ms burst 0 q133083 100 sl. 0 flows (1 buckets) sched 67547 weight 0 lmax 0 pri 0 droptail sched 67547 type FIFO flags 0x0 16 buckets 0 active 02008: unlimited 0 ms burst 0 ...... == unlimited.

@michmoor @Gertjan Thanks for the answers, it's clear. However, while you still have squid in the PFSense 2.7.2 package, I would like to continue using squid, in the meantime I gain time to think about something or leave it without squid and follow the recommendations. As there is still squid in the package, is there no rule I can apply to block 443 HTTPS access before authentication on the captive portal? thank you all

@jenyabutakov said in Wireguard and Captive portal: @Gertjan thanks! It is definitely a shift to a positive direction. Now this error (noclientmac) has gone, but I still have no redirection to portal page. PS: Tested the same with LAN interface - working like a charm

@yogendraaa it seems issue is related to FreeBSD (Maybe) not only Nginx but the queues from NIC also have issue. with 2.6 as i mentioned all okay. but same hardware switching to 2.7.2, got CPU0 @ 100% which slow down everthing & then 502 & 504 errors occur. I am specific to Captive Portal implementation. attached image for reference. [image: 1707582880399-platinum-issue.png]

Thank you for your help.

Digging a bit deeper and watching what is actually going on, it turns out the issue might not be what is being reported by our users. A reboot seems to have settled things down, but while watching what happens during a time when users should be getting disconnected shows an odd behaviour.... At 21:45, a bunch of students had access switched off through AD Radius. What is happening is that only one user out of the bunch gets disconnected approximately every 10 seconds, even although the changes to their account in AD were all made at the same time. The logs for Authentication...Captive Portal Auth near the time when the last of the users being disconnected looks like this..... Feb 6 21:59:28 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user137, da:dd:f4:f7:db:XX, 172.10.7.77 Feb 6 21:59:18 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user143, 5e:57:bf:01:bd:XX, 172.10.7.137 Feb 6 21:59:09 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user125, ee:fe:dc:b5:f0:XX, 172.10.0.62 Feb 6 21:59:00 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user920, fa:46:4e:f5:8b:XX, 172.10.7.3 Feb 6 21:58:51 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user027, ba:9a:fa:6f:d2:XX, 172.10.6.134 Feb 6 21:58:42 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user126, f2:0f:33:86:86:XX, 172.10.0.145 Feb 6 21:58:33 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user158, d2:fc:85d4:XX, 172.10.8.93 Feb 6 21:58:24 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user941, 0a:e4:5f:fa:d8:XX, 172.10.6.12 Feb 6 21:58:15 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user048, 52:e6:00:7d:97:XX, 172.10.0.135 Feb 6 21:58:05 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user231, ea:04:0d:80:09:XX, 172.10.1.98 Feb 6 21:57:56 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user193, aa:4e:7e:c1:4b:XX, 172.10.7.15 Feb 6 21:57:47 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user159, 2e:8f:c0:63:f6:XX, 172.10.7.113 Feb 6 21:57:38 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user079, 2e:f8:4f:7b:4c:XX, 172.10.0.16 Feb 6 21:57:29 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user797, da:d8:50:ad:73:XX, 172.10.6.178 Feb 6 21:57:20 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user153, fa:49:df:d4:23:XX, 172.10.0.220 Feb 6 21:57:11 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user841, f6:e5:29:59:94:XX, 172.10.7.71 Feb 6 21:57:02 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user101, 9e:85:cf:5f:fb:XX, 172.10.7.107 As you can see there is approx. 9-10 seconds delay between each DISCONNECT. Then, only after all of the users who should have been disconnected at 9:45 are actually disconnected, does the CP report the correct number of users still connected. Does anyone know if this is by design? Or am i missing a setting somewhere?

I found the issue is related to http://connectivitycheck.gstatic.com/generate_204 being blocked on PFblocker. I heard I can make my own 204 page and redirect devices to that. I am not sure on the best way to go about doing it.

@rm MAJOR UPDATE: So while comparing and applying previous settings I found the setting that was breaking my captive portal from functioning. SystemAdvancedFirewall & NAT :Disable all packet filtering. When checked this breaks captive portal redirect on 2.7.2 and allows traffic.

@Gertjan Thanks for the detailed info, I will give it a go. Much appreciated Steve

@Gertjan I think that I have issues with the DNS because when I connect to the WIFi and I type ipconfig/all the DNS is the IP that I have in my proxy server. I am going to explain you better. I have a proxy server with to ISP. So to have Ethernet in the pfSense server I put from proxy switch to WAN pfSense. But in this case i don't set up any DNS in the pfSense So I have that question I will need to setup something else in the DNS pfSense server ? Also I set up in my PC DNS auto Here i attached some pictures. There is the lease I can see my PC but I only can access to the captive portal if i put the IP. [image: 1704471820921-7.png] [image: 1704471821040-8.png]

@Bonesaw said in Family keeps blowing data cap, need guideance on captive portal idea: Now I was thinking. Can I give each user their own cheap router and then setup a captive portal on my pfSense router on and have the captive portal handle it via MAC address to those routers. Have a captive portal for each user basically. Normally, I would come out of my corner and say : don't place "routers" on a captive portal network as it will complicate live. But in your case, and I'm thinking with you : this might actually be a good idea. Create a captive portal network, for example 192.168.10.1/24. Wire (wire up) the X routers (router + AP build in, this is the most common type), one for every family member. Use a strong wifi WPA2+password every router, members won't share thee as they won't share their bandwidth ^^ Connect every routers WAN port to a common portal switch, so all are hookud up pfSense. Every router sgould have its own DHCP range, like Member 1 on router 1 : 192.168.100.1/24 Member 2 on router 2 : 192.168.101.1/24 etc Evey member 1's devices will get connected to router 1 Wifi and routers 1 LAN ports. The user should use one device initially to login against the captive portal. All other devices connected to router 1 from that point will have internet access, as pfSense (the portal) will only see an IP traffic like 192.168.10.x/24 coming from router 1 (all traffic will use the same router's WAN MAC). With some classic pfSense FreeRadius bandwidth limiting and/or quota limiting for each user, you'll can enforce control.

@ngpfpeter said in Captive Portal with self registering: Or have you already integrated FreeRadius into PfSense? You mean installing the pfSense Freeradius package ? Yes, I'm using it for several years now. I had decided back then that I needed FreeRadius for the Portal authentication. I've also set up a NAS as 'mysql' database, although not strictly needed. When set up, I've switched the portal's Authentication Server to "Radius ...", assigned a bunch of portal users Services > FreeRADIUS > Users. I've been using the official Netgate pfSense youtube video's. @ngpfpeter said in Captive Portal with self registering: Have you already implemented something like this or something similar? ( Captive Portal with self registering) No, never, as this means adding a extra stuff that has to be maintained. Also, some core pfSense script files have to be modified, although minimal. This does means that after every pfSense update, the portal 'breaks' and you have to re apply your own modifications. This is tedious and often dangerous, as updates get postponed to 'later' which introduces security issues.

@vahidmoghadam said in a User with one device get many IP addresses, why?: This is a bug No I wouldn't say that - its related to feature(s) that has yet to be enabled in the "PREVIEW" version of their kea implementation. I am not a huge fan of the wording they used to notify users of the future removal of isc dhcp.. But if users would of spent some time reading over the release notes before blindly clicking over to using the new kea which they did clearly label as "preview" in the release notes.. And went over what features are not yet enabled, etc. Better wording might of headed off some of the posts we are seeing with users trying to use kea that is not fully implemented yet with all its features and bells and whistles. And also a "preview" version is prob more likely to have some kinks or bugs to work out.. Also with anything "preview" even if didn't read the release notes, when switching to it - would be a great idea to actually validate it is working for all the things you need before sticking with it. I read the release notes, and knew right away it wasn't going to be viable for my use at this time. But I did switch to it, and yup client gets an IP from dhcp.. So it is functional as a dhcp server.. But again per the release notes its missing things in its current implementation that I am currently using in my setup. So for now I stick with ics dhcp.. Maybe with the note they popped up could of included a warning that all features are not fully mature or enabled - please validate it it will work for you before switch - link to release notes, etc. Its hard to say what the best course of action is - warning the users of removal of isc dhcp at some future time is a good thing.. But maybe it might of been been better to just hold off on the warning, and put in the release notes (which seem to go unread by many) that there is a preview version of kea available if you want to play with it.. etc. It is currently missing xyz features, etc. So be warned.