@getcom said in captive portal: nginx 504 GW timeout & 'dnctl: need a pipe/flowset/sched number' => MAC addr cleanup job needed: https://github.com/pfsense/pfsense/commit/8bfe17dae7ab15b7af802f69dbb7c421d098d38c Looks like that related. It's an easy edit, go ahead ! @getcom said in captive portal: nginx 504 GW timeout & 'dnctl: need a pipe/flowset/sched number' => MAC addr cleanup job needed: You said "Easy to rebuild as "if voucher is expired, then ditch the auto added MAC"". Should we implement that and commit a fix? The easiest solution would be : don't "auto add", as this is only a comfort option for your portal users. On the long run not for you ! They, the portal users, log in once using the voucher code, and from then on they stay logged in forever. Its up to you to remove the 'old' macs manually. Seems tedious to me. Is there a comment add to the auto added MAC entry ? If so, and it contains the voucher ID, it's easy to parse over all the mac entries, isolate the voucher code, test for validity (still time left) and if not, delete the mac entry all together (does doing a auto clean up ^^). I'm not using vouchers at all on my portal, but I'll have some spare time next week, and I'll see what I can come up with.

@gsrinivsn Got the same behavior and ran into similar problems: https://forum.netgate.com/post/1157259 This problem is from my perspective unrelated to the firmware version. If I`m not mistaken, it can happen after backup restore or reboot. The reason for this are described in the linked thread: tons of MAC addresses in the config file & DBs.

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.