… but a reverse proxy should NOT be run on the same machine that gets all your traffic from point A to point B, that should be handled by a separate box.

That is a fairly absolute statement, and there are no absolutes in the business. There are plenty of cases where a reverse proxy absolutely SHOULD be run on the same machine that gets all your traffic from point A to point B.

And considering that someone went to the trouble to create a package to do it in the first place…

Did you increase the size of the Max Table Entries?

System:Advanced:Firewall/Nat  : Firewall Maximum Tables Entries?

Maximum number of table entries for systems such as aliases, sshlockout, snort, etc, combined.
Note: Leave this blank for the default.

Hello,

I have the same issues too on new fresh install in 2.0.3(x64) with the freeradius RC1 2.1.12_1/2.2.5_3 pkg v1.6.9

The package won't start and i have this message on the log :
/usr/pbi/freeradius-amd64/etc/rc.d/radiusd: WARNING: /usr/local/etc/raddb is not a directory.

Thanks for the help.

Myke.

I ran into this same issue experimenting with unbound.  First I would confirm that unbound is able to answer the query.  Use 'dig <hostname>@<pfsense_lan_ip>' from a computer on the LAN.

If that returns the correct response then you probably are running into the same thing I ran into.  With the default dns forwarder disabled the dhcp server was giving clients the dns servers listed in the general setup.  I had to explicitly put the LAN ip in the dns server dhcp server setting.
–
David</pfsense_lan_ip></hostname>

Found this issue was a problem with pfsense using IPv6 .. executed this command from Comman Prompt:

env ip6addrctl_enable="yes" ip6addrctl_policy="prefer_ipv4" /etc/rc.d/ip6addrctl start

Now I can connect… pfsense programmers should resolve this problem.

Thank you

It does work mostly fine.

Except the Signal 11 problem with 2.12.03 which is the current package on pfsense.  Under heavy load it quits out and of course web stops.

Upgrading to Marcells package seems to kill the GUI.

thanks for the assistance.  I'll read through the content and apply (test).

@MilesDeep:

Barnyard on two interfaces seem to be increasingly disabled.  Same two interfaces.  Not on the others barnyard is running on.  This is not the end of the world, just trying to figure out why.

Look in the system log and I bet you will see some duplicate key errors thrown during database insert operations.  I'm assuming you have Barnyard2 sending data to a MySQL database.  If not, then post any system log errors.  If you are feeding a MySQL database, then go to the BARNYARD tab for each enabled interface and check the box to disable "sig_reference table" updates.  There seems to be a problem introduced with the recent barnyard2 update when multiple instances attempt to write to the same MySQL database.  The multiple instances try to insert some duplicate keys into the database, get a DB error due to that, and consequently die.

Bill

@jonna99:

This is the outcome of the command ;
ps -ax |grep snort
11823  ??  Ss    0:00.02 /usr/pbi/snort-amd64/bin/snort -R 36542 -D -q -l /var/log/snort/snort_ovpnc1365
30425  ??  SNs    3:31.75 /usr/pbi/snort-amd64/bin/snort -R 36542 -D -q -l /var/log/snort/snort_em036542
12633  0  S+    0:00.00 grep snort

and thank you for taking your time
Jonna

I think you are the victim of a bug in the DUP interface code added to Snort a few revisions back.  A fix for that is coming up shortly.  Notice the number following "-R" in the output you posted is exactly the same:  36542.  They should be different.  Did you by chance create the VPN interface by clicking the + icon next to an existing interface?

To fix this now, before the update is released, requires a number of manual actions including renaming some directories using the command line.  If you want to try the manual fix, send me a PM (private message) here on the Forum.

Bill

reinstall the package, and give the 'ip matches ip or alias' acl a try, you can just put the name of a ip-alias there and it should work..

remember the list is only reloaded when config is written again while starting haproxy.. changing an alias does not currently trigger that.

@ukhost4u:

Hello.

We have been running a range of testing using Snort and have 2 questions in regards to it:

Is there any way to redirect blocked IP's to a web page (ever on the firewall or externally) which can tell the user that there IP is on the blacklist and how to go about contacting us to remove it. We do something similar to this on our CSF Linux software firewalls and its very useful for customers.

We have a customer who does not want his traffic inspected by Snort, is there a way to set a rule so that if the destination IP meets the requirements that Snort ignores the rules and just whitelists any source traffic going to this destination IP?

I hope someone can help with these questions.

Thanks,

Paul Hughes
Senior Manager
http://www.ukhost4u.co.uk/

For #1, no, there is currently no mechanism for that in the Snort package.

For #2, I think you can accomplish what you want using the IP REPUTATION preprocessor.  Create a whitelist containing that customer's IP or IP range.  Assign that whitelist to the IP REP preprocessor for the interface using the IP REP tab for that interface.  Set the options on that page so the whitelist has priority.  IP addresses in a whitelist are NOT inspected by Snort other than the initial quick test to see if the IP is in the whitelist range.  Once that determination is made, the package bypasses the remainder of the Snort inspection engine.

Go read up on the IP REPUTATION preprocess in the Snort VRT online manual here: http://manual.snort.org/node17.html#SECTION003219000000000000000

Bill

Lookup info on creating a wpad.dat file. It's not technically transparent, but it allows each computer to automatically be configured to use your proxy server. DansGuardian is quite nice, and very flexible as to capabilities, but is more complicated to setup and configure. SquidGuard has basic functionality, but it is far easier to get it going.

If you need to enforce use of the proxy, you could try to block outgoing traffic on ports 80 and 443. If you do any of this, you will probably want to first switch the port used by pfSense's WebConfigurator to something non-standard so that you don't accidentally proxy traffic to the pfSense box.

You can also use networkinggeek's answer.

Neither solution is necessarily better or worse. It just depends on your network and your needs.

Very annoying :(

Not running out of memory, CPU or disk.

It just wont boot until I remove the 2nd interface.

I've been away for a couple of days– sorry for the intermission.

I haven't been able to reproduce the memory error that BBcan177 is experiencing. I am running a (mostly) default install of pfSense and Snort on bare metal with the exception of the fact that I increased the memory of many parameters to offer headroom... to prevent out of memory errors. Just in case.

Per bill Meek's request, I added the following lines to my snort.inc file:

// Snort GUI needs some extra PHP memory space to manipulate large rules arrays
ini_set("memory_limit", "256M");

Since I was NOT experiencing this specific issue, I didn't expect any behavior to change.

Additionally, I have not had the time to whittle down the specific rule(s) responsible for my issue. There are, after all, over 5000  emerging-web_specific_apps.rules to work with.

I do have a few updates to add to the log:

Rather surprisingly (and somewhat disconcertingly), after several months of slowly working with this error on my own involving the two rule sets (emerging-web_specific_apps.rules and emerging-web_server.rules) which causes Snort to enter a 'Disabled' state within minutes to hours of enabling either or both of those two rule sets, I can no longer reproduce the error at all. In fact, turning ON those two rule sets will no longer cause Snort to become disabled as it once did. This new behavior was observed within approximately 24 hours of these posts to the pfSense forum. And I've made no changes to the system. None.

Perhaps Bill or someone on the Snort/pfSense team read this post and fixed the issue in a rules update? I can't determine any other cause for the change in behavior. This is an exceptional coincidence in my many years of tinkering with PCs. In fact, instead of considering the issue closed and moving ahead, I am even more curious now to determine what is happening "under the hood".

Another bit of info to consider: once I had determined that one or both of the rule sets in question would disable Snort, I of course verified this hypothesis by working with all permutations of those rule sets to verify that the problem was reproducible before posting to this forum.

BBcan177: short of re-installing pfSense or reverting to a default configuration, have you tried to run a hardware test to ensure that your memory and other components are in working order? I have found bad memory in a number of computers over the years; bad memory can cause very strange behavior and sometimes the problem is consistent and reproducible, and other times it is not.

Thank you all for your assistance and input.

Dear Als,

Thank you very much! Based on your freedback, I took a slightly more radical approach, since I found freeradius would not start with one of the accounting databases missing. I deleted /var/log/radacct and reinstalled the package. Then, things started to work, at least for the time being.

This is much better then reinstalling the entire system without knowing when the same thing might happen again.

As this is a backup system in a CARP setting, I could imagine that things go sour when the backup system switches back to is usual backup function after having been the master for a short time.

Regards,

Michael

@Thrae:

I'm having trouble figuring out how to implement the particular scheme I want:

Main pfSense router without Snort installed. (Almost) all traffic goes through Snort transparent proxy firewall unless it takes too long to respond, in which case the pfSense box stops using the proxy until it responds in a timely fashion again.

This would be a really long timeout, meaning the proxy box is probably down or at least extremely overloaded. The reason I want a separate box is because I've found Snort especially tends to be rather problematic on pfSense boxes, possibly taking them down, even if they are well over-spec'd.

I'm guessing one way to do this would be to have the boxes hooked up via a crossover cable such that all requests still go to the pfSense box, but then the pfSense box itself forwards requests first through the Snort Firewall, which then goes back to the pfSense box on the same port if not blocked. Since pfSense supports Snort, I could have the other box also run pfSense and use something like CARP and pfSense's own built-in redundancy.

What you found out was not snort, nor pfsense, or anything related to them. Snort has no problem running on pfsense. If the box is well over-spec'd and taken down that means you have a lot of bigger fish to fry than snort not running. I've run snort on old hardware that should have been sent for recycling a long long time ago, analyzing traffic most users in here will never see (datacenter volume traffic), and never had an issue with snort taking down the box.

I would not recommend adding another unnecessary box to the network.

Credentials: Author of the snort and suricata blueprints.