@NightHawk007:

Is there a way disable this rule i have problems with most websites  because of  this stupid rule . This Started to have more alerts and blocks after i got my gigabit fibre package !

I dont know if your running a server or not, If your seeing these alerts just surfing the internet just add a fake "http server" in the "snort_define_servers.php" tab.
Dont forget to define the ports too.

Moreover, you can edit the snort.inc file and add "double_decode alerts off" to the "preprocessor http_inspect_server:" part.

Example:

TYPE: "ee /usr/local/pkg/snort/snort.inc"

Find "preprocessor http_inspect_server:"

@Derek Zeanah

Suppress disables the rule completely.

What do you mean "first page", can you post a pic.

A quick fix is to edit the snort.inc and add "no_alert_incomplete" to the "Preprocessor rpc_decode:" area.

Example:
Preprocessor rpc_decode: 111 32771 no_alert_incomplete

I'm also having this problem.

I found that when you set up pfSense in System-> Advanced-> Admin Access check http squidgard works well. But if you check HTTPS or HTTP and defines a port other than 80 it presents problems.

In version 1.2.3 I was using http and port 8320 (my default).

In pfsense 2.0 rc1 is showing this error because squidgard always configures
redirect to redirect http://192.168.1.1:80/sgerror.php?url=403%20&a=%a&n=%n&i=%i&s=%s&t=%t&u=%u

Even though you have set your ateriormente that would work with pfSense
HTTP:8320

File squidguard_configurator.inc
function sg_redirector_base_url($rdr_info, $redirect_mode)
{
    global $squidguard_config;
    $rdr_path = '';

# gui port, ip & proto
    $guiip = (!empty($squidguard_config[F_CURRENT_LAN_IP])) ? $squidguard_config[F_CURRENT_LAN_IP] : '127.0.0.1';
    $guiport = (!empty($squidguard_config[F_CURRENT_GUI_PORT])) ? $squidguard_config[F_CURRENT_GUI_PORT] : '80'; ////////////////////// the error is here ////////////////
    $rdr_path = "http://$guiip:$guiport" . REDIRECT_BASE_URL;

The staff should make pfSense squidgard used the same port as defined in
System->Advanced->Admin Access check HTTP

I changed my code to cause the port to the redirect was equal to the configuration of pfSense HTTP: 8320, is now up, but I think this is a
BUG.

By using aliases and such, usually it isn't necessary to have such a long list of rules. Are you sure there isn't any way you could be simplifying your ruleset to be shorter?

Any changes like those mentioned in the other thread would be too large for 2.0, so it would be 2.1 at the earliest, if that.

You use either vi or nano or ee to edit/update the file

@jwelter99:

I'm running it on just the master for now.

I will setup a test environment next week to play and will update this thread as perhaps we can work through it?

Fantastic package by the way!!!!

Absolutely. It would be pretty cool if I could make the package compliant with your setup.

At the very minimum, we could develop a special version just for your setup.

going to take a look at it,
many thanks for your kind advices!

That's all up to you and your environment. If you have a very large hdd, you could have a very large squid cache :-)

I have the same problem, except some of my alerts are working properly, and some are not.

Output of the signature table in mysql shows

Some are good and some are bad

|    105 | Snort Alert [1:408:0]                          |            1 |            3 |      5 |    408 |      1 |
|    106 | Snort Alert [1:396:0]                          |            1 |            3 |      7 |    396 |      1 |
|    107 | Snort Alert [1:5999:0]                        |            6 |            1 |      4 |    5999 |      1 |
|    108 | Snort Alert [1:5693:0]                        |            6 |            1 |      6 |    5693 |      1 |
|    109 | Snort Alert [1:16281:0]                        |            6 |            1 |      1 |  16281 |      1 |
|    110 | Snort Alert [1:368:0]                          |            1 |            3 |      6 |    368 |      1 |
|    111 | Snort Alert [1:381:0]                          |            1 |            3 |      6 |    381 |      1 |
|    112 | Snort Alert [1:16627:0]                        |            6 |            1 |      1 |  16627 |      1 |
|    113 | ICMP PING Windows                              |            1 |            3 |      7 |    382 |      1 |
|    114 | ICMP Echo Reply                                |            1 |            3 |      5 |    408 |      1 |
|    115 | ICMP Destination Unreachable Port Unreachable  |            1 |            3 |      8 |    402 |      1 |
|    116 | ICMP PING BSDtype                              |            1 |            3 |      6 |    368 |      1 |
|    117 | ICMP PING *NIX                                |            1 |            3 |      7 |    366 |      1 |

The way some applications bind, they don't function entirely correctly with bridging unless the IP they're using is on the bridge itself (which is only supported in 2.0), I suspect that's what you're seeing here. The only thing I've seen to date that has issues in that scenario is nmap but other applications likely have the same issue.

Or use DNS Forward to do it.

It works, you just have to be careful with your selection of rules.

@Cry:

Your best bet for tuning advice for HAVP may be on their own forum or mailing list.

Unfortunately, I can't seem to get on their forum.  I registered, but it won't send me an activation email.

I've actually tried almost all configuration combinations and I am not able to get the client IP in the logs.  Has anyone been successful with this?  I've read in the 2.0 pfsense release Squid will not bypass pf, and should provide visibility to the client IP address.  I think it is a functionally issue not a configuration issue.  Although, I have been wrong before. :)