@robsonvitorm
You dont need to obfuscate private addresses (RFC1918) or mac addresses generally.
If you don't see packets leaving then you have a problem on the host level. Either your network stack on the host is corrupted or you got something else going on.

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

@MathiasMa

What if : Windows devices do also a ping == protocol "ICMP" to check for network connectivity ?
You don't allow 'ping' ^^

Rule 1 : not needed. And keep in mind that a UDP web server (port) '80' hasn't been invented yet.

When you start with the captive portal, use this 'one and only' rule to test :

bafa25e1-fad9-4949-8c6a-c6773fb44fdb-image.png

Afterwards, if you want, you can add more restrictive rules. As soon as stuff start to break, you'll know where the issue is ^^

On the windows device, as soon as you are connected == received a DHCP lease, you should be able to do a

nslookup gstatic.com

or a

nslookup connectivitycheck.gstatic.com

This should return a :

C:\Users\Gauche>nslookup connectivitycheck.gstatic.com ........ Addresses: 2a00:1450:4007:81a::2003 142.250.201.163

As soon as the PC gets this IP resolved from the 'test' URL, it will connect to it, using port TCP 80.
This (a typical http browser) request and will get intercepted by the portal firewall, and redirected to the web server running on pfSense that shows a "login page".

Most important rule : pfSense should do the DNS resolving for the portal clients.
This is normally always the case, as clients have to use the mandatory DHCP to get access to the portal network.

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 :

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.
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:85🆎d4: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