[pfSense] Quick Thanks from a Happy user
morfeas3000 at gmail.com
Thu Apr 26 15:58:32 EDT 2012
You have an interesting command line scripts aproach if I understand correctly.
The only improvement I see is that you could substitute most of the
shell scripts with php ones updating the external radius server and
database with most of the info you need and send the emails and maybe
even skip the administrator intervention for every user.
But this is a matter of tools preference.
Thx for the info.
On Thu, Apr 26, 2012 at 10:23 PM, Christian Neumann <cneumann at pih.org> wrote:
>> Date: Wed, 25 Apr 2012 14:49:14 +0300
>> From: NorthPole <morfeas3000 at gmail.com>
>> To: pfSense support and discussion <list at lists.pfsense.org>
>> Subject: Re: [pfSense] Quick Thanks from a Happy user
>> <CA+wR77o_jGyMi3F9u-xooHXeWXazdVa1SgcFY3m3=Sq=fZKqMA at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>> This is a very interesting application and congratulations on making it!
>> If you can It would be very interesting if you could provide details
>> in the following.
>>> - Mail notifications for important events (new user signed up, weekly RRD stats, reboots, ...)
> Various solutions: We have a custom portal page where every new user (system) is redirected to. From there a couple of shell scripts get the IP, Hostname and Mac-Address together with the values that the user entered on the portal page (name, email, ack'ed the terms of usage, organization he/she belongs to). At the end of this process a shell script sends out an email to a group of admins with these details.
> For the weekly RRD stats (we are just interested in the traffic graphs) we use the package 'mailreport'.
> Startup/reboot notifications are send via a simple cronjob with the time '@reboot'.
> For all of this we have installed some perl libs to simplify the email handling. Ideally this should be done in a PHP extension / pfSense package, but I didn't go that far yet.
>>> - 'Jail' for misbehaving systems and a HTTP redirecting to let them know
> Misbehaving systems could be simply slowed-down to a minimum by the bandwidth limits of the Captive Portal (e.g. just 1 Kbit/s for up- and download). But this way the user wouldn't know that his system is blocked. In case we want them to know what happened, we redirect them through a Squid config with the package squidGuard to a dedicated page for this system. This page then indicates what happened and why. As this is the only white-listed page in this particular SquidGuard category, the user (with this system) can't go anywhere else.
>>> - Reports with last time systems were connected (usefull for cleanup RADIUS users)
> With the options 'Reauthenticate connected users every minute' of the Captive Portal, the freeRADIUS logs contain detailed information about how and when systems connected. Again a couple of shell scripts dig through this data and provide some useful stats. With the build-in freeRADIUS and our ~100 systems/day we have hit a limit, so that we had to deactivate the ongoing RADIUS accounting information for now. It seems like we have to move to a dedicated freeRADIUS installation in order to bypass this. But the idea will remain the same. It might also be that the freeRADIUS 2 package is providing some of these features.
>>> - Support for external monitoring solutions of internal network devices
> We have dedicated nTop and Zabbix systems running outside of the pfSense box (for us pfSense is the inner firewall between our server subnet and all client subnets). But many network devices are inside of the client subnets, so depending on the devices (printer, access point, switch, server), what we want to monitor, and which access Zabbix needs to the devices, we have created a bunch of firewall rules and port forwards to selectively allow access. Maybe the zabbix-proxy package helps to make this simpilier, but we haven't looked so deep.
>>> - Default (low) speed group for unknown users through Captive portal bandwidth restriction
> Whenever a user/system is going through the self-signup process (see above), we assign the system with low bandwidth limits. This way someone can connect, but can't consume much of our scarce bandwidth. As we receive an email whenever this happened, we can then check if the system should have more/faster access to the network and 'promote' it through assigner higher bandwidth limits within freeRADIUS.
>> did you use an external non custom application for these and if yes which?
> I could see that some of our features eventually make its way into a clean pfSense package, but we haven't had the time and skills to investigate deeper here. So there are a couple of manual installation and config tasks required, before this all works together. I'm open for any suggestions if or how this could be made more usable.
> List mailing list
> List at lists.pfsense.org
More information about the List