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

@m4tzen said in Captive Portal - Used Voucher could be reused:

-> Does this mean ... after the "reboot" of the Router/Device, the enduser need to login again equal if the enduser device have an applied and enabled voucher code?

Yes.
After the reboot of pfSense there are no logged in users - the ipfw firewall (rule) states are nor saved, users have to re login.
I advice you to try it out - see for yourself.

@m4tzen said in Captive Portal - Used Voucher could be reused:

-> we are new on this Software ... s we dont have any experience about how much update's are deployed in a year. BUT we will upgrade/update all the time to the latest version ...

A couple of times a year.

@m4tzen said in Captive Portal - Used Voucher could be reused:

Some more question to the IDLE TimeOut ...

The captive portal was been designed to give temporary "non trusted clients" Internet access.
Your typical railway station, hotel, camping, restaurant, ** or to some extend even your own house that you rent to strangers.
The clients just come by, stay some time, do their thing (typically : updating their FB page) and then leave the premises for good.
A idle timeout, and hard time out, is needed so the ipfw tables don't get cluttered up.
Idle time out happens if the device left for the day (or was shut down for the day) : his owner should re login - and this is possible as long as the voucher remains valid.

** I forget : some are running pfSense Captive portal on aero-ports. Tens of thousands of captive portal connections all the time.
These huge system will die in minutes if an idle time out isn't set.

If, for example, 8.8.8.8 is the DNS server used by the clients, and 8.8.8.8 is added to the "Allowed IP addresses" tab, then you can resolve DNS requests from your client PC's (test that using nslookup for example).

You can also 'see' that the IP's are pass-through : go to console or SSL access, enter option 8 - and enter :

ipfw table all list

You will see the IP's white listed in a table.

But, normally, you shouldn't alter any DNS settings, and keep the DNS Resolver running on pfSense.
This way the captive portal will work "within 3 clicks" (test this ! and only then move from this position by understanding each step before taking it ☺ )

@magokbas Thanks, it worked!

Yep.
At this moment, using the current version, you should stop editing the portals settings when you have put it online.
This shouldn't be a big deal I guess, ones the settings are fine you're done with it anyway.

https://github.com/pfsense/pfsense/pull/3640#discussion_r199824018

Augustin-FL 8 hours ago • For the main CP zone : Because currently when settings are saved, captiveportal rules are re-appplied unconditionally to the network interface, meaning all ipfw rules are unconditionally flushed. **This is a big problem when editing captive portal settings while some users are connected : When saving the settings, users go technically disconnected and are redirected to the login page (because ipfw rules are flushed), but they are still considered as connected and are unable to log-in again(because they are still present in the sqlite database).** I solved this issue by flushing SQLite DB when rules are re-generated, and i also added a warning "Some users are connected, they will get disconnected. Do you want to continue ?" on the GUI. For the RADIUS database : because this database is now obsolete, captiveportal don't use it anymore.)

Hi,

The cookie solution isn't a perfect solution at all.
Did you thread the entire https://forum.netgate.com/topic/69307/captive-portal-manual-logout-page-address ?
Do so and you find out why.

Don't worry, that error was repaired. That's why new versions come / came out.

So, you have a choice : upgrade if you don't want to repair the captive portal_disconnect_client () function yourself ^^ (btw : easy PHP code - you could even look into github to see what was edited when and why so the error was cleared).