Thank you! I will check out the hangouts--been meaning to enable https on the portal now that we are rolling w/ ACME, but I didn't realize it would help the situation.

It's possible the trouble we've been having with Avast (and I assumed firefox soon) is related to a firewall rule we've used to limit DNS to pfsense. Will dig deeper. Appreciate all you have done and continue to do @jimp

Might be solved.

I had 20 or so hosts listed but have removed all but 2 of them and turned off DNS resolver. This seems to have resolved the situation.

There is nothing special about Captive Portal on VLANs. It works the same as any other interface type.

@conanhughes said in Client who disconnected with a logout button regains Internet access when the voucher (or FreeRadius account) he used is entered in another device:

EDIT: I don't know if it matters, but I also already enabled Disable Concurrent user logins.

Be careful with this one.
Read https://www.netgate.com/docs/pfsense/captiveportal/using-captive-portal-with-freeradius.html

The most recent update actually restored somewhat the "expected behavior".

When you use the Captive portal and really want to understand what happens, there is something is more then the GUI to look at : https://www.netgate.com/docs/pfsense/captiveportal/captive-portal-troubleshooting.html
You'll be seeing the "ipfw" firewall rules that make the portal actaully working. Probably impressive the first time you see them, but, hey, what the heck, you're running a firewall, these rules are what makes it work.
(and you would have detected that the GUI said that there is no user connected anymore - but the rules said otherwise, permitting you to find a "problem" in a split second)

It's not your question, but still missing today is the "Use the first login, and do not accept any others logins, when using vouchers - thus enforcing the rule : "one voucher - one user - one device, the first device he'll be using - and not share the voucher,, even with himself (the user)".

Hi,

The WAN IP changes for millions of us every day or every week. That didn't "break" the portal.

But : changing the LAN could imply far more then "change some data on the Interface page and done". You didn't say what you did - neither if this implies settings on packages like "squid, squidward, clamav, cicap, snort" (I'm using none of these) so ... can't tell from here what you forget to change.

Btw ; but you did find one more reason non to run the captive portal on LAN - thanks for that.

Adding "connectivitycheck.android.com" to the allowed host list doesn't seem a good idea to me.
This URL is probably member of the http challenge page that the OS is using to check if a portal is present.
When white listing this URL (an IP) the OS will conclude no portal is present, and a direct connection to the net is available. The user will get directed the the captive portal login page when another http request to somewhere else passes by.

See also https://android.stackexchange.com/questions/123129/how-does-wifi-in-android-detect-if-the-device-has-to-sign-in-or-not

If you enable the Enable Pass-through MAC automatic addition with username the MAC entry will be expired/pruned along with the voucher when the voucher expires. I am not sure what happens if you disable the voucher as username. I would guess the MAC address entry stays until manually cleared.

@gertjan hi
thanks for you help got it working. now with the cp working i am not able to get qbittorrent or any torrent client to work nor whatsapp voice to work, ive got the nat and firewall disable and when i disable the cp all the above work fine and this is true for both the cp by it self or with freeradius enable. winamp and yes i am still using winamp wen nat is enable that will stop streaming.

can you help
thanks

It's a known issue but not one with a good solution at the moment.

https://redmine.pfsense.org/issues/3932

Ok, I'll rephase.

I don't understand what you are trying to do.

I'm using the Captive Portal, and also pfSense as a VPN server, to access my LAN from outside.

I'm pretty sure visitors that use my Captive Portal and after being authenticated, they can connect to any VPN service they have access to (but not my pfSense VPN server, of course).

You want to tunnel all authenticated trafic from the Captive Portal users through a VPN ?

Hi,

When you use the "Per-user bandwidth restriction" on the Captive portal Config page, then yes, every IP/MAC will be throttled to what you set in Default download (Kbit/s) and Default upload (Kbit/s).

On the other hand, when you did not check "Per-user bandwidth restriction" on the Captive portal Config page, you could instruct FreeRadius to handle every IP/MAC differently (this is actually one of the reasons why pfSense proposes FreeRadius).

That is impossible to accommodate. The rules must work with IP addresses. The hostnames are translated to IP addresses by resolving the hostnames, and you can't resolve *.<domain> via DNS.

If there was an option to enter that before, it was broken and never worked. It had only ever worked with complete fully qualified domain names on pfSense.

@bebop_man said in Captive Portal - Allowed IP Addresses = Bypass Bandwidth Restrictions?:

Was I incorrect in thinking that 'Allowed IP Addresses' removed all restrictions on the IP address in question?

Yes.
Bandwidth Restrictions on the captive portal settings page are valid for all devices on the captive portal interface.

@bebop_man said in Captive Portal - Allowed IP Addresses = Bypass Bandwidth Restrictions?:

How can I tag IP addresses in a specific range to bypass CP limits ?

I tend to say : put them on another interface (other LAN, VLAN)

The golden rule is : only "clients with BJOD" == non trusted devices on a captive portal.

Btw : a captive portal solution using FreeRadius can give you a bandwidth control per device.

@gertjan Thank you so much for the information. it gives me insight of the problem.

For that, the closest you will get is whitelisting the MAC addresses of the specific game consoles you have/know of. That would be handled in your AP before the traffic ever reaches pfSense (layer 2).

Look at the Pass-through MAC Auto Entry options in Captive Portal.

Captive Portal works fine on a LAN in that situation. Can you elaborate on your setup some more, including what you set in Captive Portal and also what you send the clients for DNS (e.g. the firewall or some external DNS server) and also what the exact client behavior was when Captive Portal was enabled.

... and if they can't, up to you to add their MAC on the trusted list.

Check with ipfw table all list if they are gone.
The table is called ZONE_pipe_mac

After modifying you should re save the settings on the captive portal related zone page (and / or the MACs page)

@alexcheddar said in Exclude some clients in LAN captive portal:

But is there any link or url that i can type to logout manually in CP?

As you can see on the settings page, there is a logout page. Also mentioned is the that this page is a popup :
0_1531221847508_c204d6bc-bd10-4a76-8998-5ae731149319-image.png

The link to this page, as shown in the navigator bar, is the logout URL.

Now the fun part.
You will probably find out that you didn't saw any popup when logging in. You'd say : it doesn't work.
Now it 's time that that you recall that you, and everybody else on the planet have blocked popups in your navigator. You could enable your popups again, but your portal visitor won't.

You could show the link on the portal login page, and mention on that page that people should copy it on a safe place (making a favorite link of it ?) but most visitors probably won't.

Next best solution : make the Idle time out (and hard time out) counter as low as possible (although when visitors think that they de-connected because they closed all navigators windows, all other processes, like fat mail clients, OS updates, all kind of device drivers GUI update programs, scanners en trojans etc will still use the connection, so it will never Idle out. A Wifi connection could be closed "by hand" (the button, or by GUI), but again, most just visitors don't that ...

There is a huge thread in this forum that treats the subject rather well, and explains why a real "logout button" is very hard to "close to impossible" to implement.