Updated to reflect push of Snort Dashboard Widget ver 0.3.4

A new version of the Snort Dashboard Widget will hopefully go out soon is now out.  The new version is 0.3.4.  If you have the Snort Dashboard Widget installed, you most definitely want to update it to this latest version!

I just discovered a rather nasty little bug that causes the Snort Dashboard Widget to crash the package startup for Snort upon a reboot of the firewall.  It only shows up when the widget is installed.  I have tested the fix for this and it works.  I inadvertently "included" an incorrect include file as part of the uninstall routine I added for the widget… :-[

Bill

And perhaps SARG package can offer you some more specific information but you have to check this by yourself because I don't have any experience with SARG.

There is some dialogue on freeradius mailing lists:
http://lists.freeradius.org/pipermail/freeradius-users/2013-April/066212.html

Alan Dekok is one of the developers of freeradius. He is an absolute expert in freeradius but - in my opinion - he is not very polite when posting on the list.

As far as I understand him you could add something like the following in "../raddb/policy.conf"

if (User-Password) { update request { User-Password := "%{tolower:%{User-Password}}" } }

Perhaps you cann follow this conversation and test and if you found a solution post it here that we can implement this into GUI.

The command you run only downloads the sqlite program/libraries, it does not update the PHP module.

Give a 2.1 snapshot a try, it should have a more up-to-date PHP library for sqlite.

@costasppc:

Snort and Squid are not recommended in embedded installations. You will have memory hogs. Also Squid needs disk space for caching, which is not much in CF card installations.

Best regards

Kostas

I agree for Snort.  It can easily consume more than 1 GB of RAM just by itself with a moderate rule set.  I've had some 1 GB RAM virtual machines used in my Snort testing start swapping out to disk with Snort and a full set of rules running.

Quoted Bill for the Open Issues.

Wanted to seperate the two threads :)

@bmeeks:

Folks:

I think we may be narrowing down the list of open issues in the current Snort package version 2.5.6.  Here are items that I am aware of still open.  Actually I think these are all holdovers from the 2.5.5 package.  I have working fixes for these in my current test environment.  I just want to be sure I've caught everything major before I push out a 2.5.7 package update.

OPEN ISSUES

1.  Snort not saving edits to the Rules Update and Remove Blocked Offenders cron jobs.

2.  Snapshot updates on 2.1-BETA systems do not fully complete the Snort rules update post-upgrade and Snort does not start until a manual rules update is performed.

3.  Snort not auto-starting after a package reinstall with prior saved settings.

Did I miss any big ones in my list?  I wanted to double-check and see if anything else was lurking out there before pushing another update.

Bill

Same problem I just had.. Not sure why it failing.. Will look at something and get back to you later.

can some1 give me commands to run to output the firewall rules in normal condition and when traffic stops, mayb it will provide more info

Again, thank you for all your hard work and bug fixing!
Updating from old version to the new one worked (again) without any problems!

Thx alot for the tip, I'm going to try this. I was going crazy no being able to install squidguard without crashing pfsense.
I just tried this and it works with 2.0.3 !

Hi!

I have had big problems with my siproxd but your guide has helped alot. The problem I had were that the state between my firewall and my sip provider kept dropping. After I set the rule up that you suggested it worked much better and the state help up for some days. But this morning it was down when I came to work.

I have 6 phones which are all registered in siproxd's interface. I have setup the rule as I think you did: on the Wan side the sip provider is set a source and my wan adress on the destination, port 5060 over TCP/UDP.

Are there anything I can setup for forcing the state not to go down, much like a ping can keep an VPN connection up. As of now from what I can understand it keeps up as long as possible but nothing stops it from going down if the resources are needed elsewhere. Perhaps there is a way to get the state up again if it goes down? The only way that I found to get the state up again is to make an outgoing call from one of the phones.

Hope for some help. Cheers!

//Peter

@nathanpinotti:

There's a VPN rule allowing all traffic to anywhere. Could it mess my LAN rule up?

Not at all. Lan traffic pass by lan rules and floating tab, not vpn interface.

web request –> nat(80 redirect to 8080) = transparent proxy

@sronsen:

This error message almost always means you have mixed 32-bit and 64-bit libraries on the system.  These "unsupported layout" errors have happened before for many other packages besides just Snort, and each time it's caused by having a mix of 32-bit and 64-bit stuff on a system.  In particular this error can happen when 64-bit libs wind up on a 32-bit box.  I can't tell you how this might have happened, but I'm pretty sure that's what is wrong now.

I had to reformat the drive and reinstall pfSense, but I finally got Snort working.  If I could only figure out why the pfSense installation won't work from a USB CDROM, I wouldn't be so put off, but the installation asks for a mount device and fails when a valid one is entered.  If I plug in a SATA CDROM drive with the same disc, it just installs to the proper drive without asking me anything.  This is on a rack-mounted PC w/o any external bays, so I have to unmount the PC and open it up to rerun the installation.  Ugh!  I think I'll pass on pfSebse and Snort updates for the next year.

I installed my current config from usb. My 1u system has no optical and I didnt have a usb cdrom. Mine installed just fine using the usb install method.. Maybe try that instead of cdrom?

After the revers zone issue was corrected, everything works fine now.

Thanks for the help.

It could be the load on the specific server if it located in two different places :)

i have re-installed bandwidthd and it is working now. However, I ended up using ntop cause that is the only bandwidth monitoring that support multi-wan.