@justsomeone:

24 gig RAM, possibly a memory setting in the BIOS is affecting it? though if AC-BNFA-NQ performs the best, maybe I should leave it.

It's been stated here on the forum several times by several folks that the best setting is AC-BNFA-NQ.  Some of the other settings can quickly chew up RAM unless lots of optimizations are done, but the Snort package does not support in the GUI all the fine-tuning required.

Bill

This issue was probably due to issues with the package repository that day. Tried to set up the export utility today, and it worked fine even though there have been no changes to the utility since I last tried it.

It seems that if I add

http_port [2001:xx:xx:94a::1]:3128 acl localnet src 2001:xx:xx:94a::/64

Into the Custom options on the General tab it nows listen to the ipv6 IP correctly.  However, the transparent proxying on ipv6 doesn't seem to work.

@networkinggeek:

This post might help you, have a look at it.

https://forum.pfsense.org/index.php?topic=69370.0

Thanks for the reply!

That's too bad… Sounds like there's no way to do it locally and have it show up in the Gui.

Well, at least there's a way to do it through SSH rather than the WebGui... That'll likely be more reliable.

Thanks for the link!

The fix for this has been submitted and is awaiting review and approval by the pfSense Core Team.  The request has been posted for 23 days as of today.  I sent a friendly reminder e-mail today asking the team for an estimate on when this will be merged.

Here is the active Pull Request:  https://github.com/pfsense/pfsense-packages/pull/692

The problem is the interface domain tagged onto the end of the Link-Local address.  That trips up Snort (and Suricata).  The coming fix strips that off when adding Link-Local addresses to HOME_NET and PASS LISTS.  There is really no workaround so long as you enable and use IPv6 on your interfaces.

Questions

Is there a workaround and/or recommended correction for the FATAL ERROR (see Detail)?

Why does snort add trusted DNS servers to HOME_NET, as opposed to creating a new variable to specifically track DNS behaviors explicitly by naming the DNS servers there?

There are three interfaces on my pfSense firewall that are "Tracking" the WAN IPv6 DHCPv6 request for an IPv6 /60 delegation prefix.  Comcast is assigning of those internal interfaces an IPv6 /64 address space.    When IPv6 addresses get rotated, will snort automagically restart to pick up changed IPv6 address assignments for HOME_NET?

You can uncheck the box for including DNS servers in HOME_NET if you don't want them there.  You can instead add them via an Alias on the VARIABLES tab in Snort.  First create an alias under Firewall…Aliases containing your DNS server or servers, then put that alias name in the DNS Servers box on the VARIABLES tab.

No, there is not way for Snort to magically restart on its own if you get new IPv6 addresses.  However, there is some logic in pfSense that will restart packages when there is an IP change on the WAN.  That may trigger what you want.

Bill

@jimp:

@KOM:

SSH in and delete /var/squid, /usr/local/pkg/squid.* and /usr/local/pkg/squid_.

Don't delete /usr/local/pkg/squid* or you will lose your Squidguard settings, if it's installed.

The settings are in config.xml, not there, so you can remove "/usr/local/pkg/squid*". If you want to reinstall the packages after, make sure to reinstall squid first before trying to reinstall squidGuard.

As for the settings, if you want to remove those, try this from Diagnostics > Command in the PHP Execute box:

$squid_sections = array("squid", "squidnac", "squidcache", "squidauth", "squidextauth", "squidtraffic", "squidupstream", "squidusers"); foreach ($squid_sections as $sec) { if (is_array($config['installedpackages'][$sec])) unset($config['installedpackages'][$sec]); } write_config("Removed Squid");

Or to remove squid, squidguard, lightsquid, and anything else with 'squid' in its package name:

foreach (array_keys($config['installedpackages']) as $sec) { if (strpos($sec, "squid") !== false) unset($config['installedpackages'][$sec]); } write_config("Removed all squid-related settings");

Not perfect but it should get the job done.

Either that, or backup the config, edit the settings out, then restore.

it works! thanks a lot!

@HSeffers:

Hi there,

I am running a pfsense for years now. To get a real fresh system, I want to rebuild completely.
So running a "temp" pfsense in VM, just to do all the proper settings etc, before moveing config to live system.

I did install on the new system, squid3-dev and Dansguardian with NAT redirect for port 80.
Dansguardian then redirects to Squid.
Everything works well, until I install Snort and activate the Snort interface WAN.
I did set it up with the same rules and settings as on actual running live system, where btw. no Dansguardian is installed
But when I then try to open a web site on port 80, I get the following error message in the browser (i.e.: www.computerwoche.de):

Der folgende Fehler wurde beim Versuch die URL http://www.computerwoche.de/ zu holen festgestellt:

Verbindung zu 2a01:138:a028:0:62:146:83:75 Fehlgeschlagen.

Das System antwortete: (65) No route to host

Der Zielhost oder das Zielnetzwerk ist momentan nicht verfügbar. Bitte wiederholen sie die Anfrage.

Ihr Cache Administrator ist

Basically it looks like there appears an IP6???
I disabled IP6 on the pfsense and wonder now what is happening there.

HTTPS sites work still fine as they are not redirected through Dansguardian.
For testing, I did enforce in one browser to use squid directly as HTTPS proxy and also works fine.

So I wonder, if there is anybody out having an idea about this issue???

Disabling the Snort interface and all works well.
It looks like to me like the combination of Snort and Dansguardian not loving each other…

A push into the right direction would be really appreciated :)

Thanks

Holger

Did you have Snort in blocking mode?  If so, did you check the ALERTS and BLOCKED tabs in Snort to see if had blocked traffic?  Without some initial startup tuning, Snort can be very aggressive in blocking some web sites that send out quasi-malformed HTTP traffic.  Most of the time these are just false positives, but they result in a block anyway.  There is a thread here in the Packages sub-forum you can search for that includes a suggested SUPPRESS LIST setup for Snort that avoids the most common false positive events.

Here is a link:  https://forum.pfsense.org/index.php?topic=56267.msg300473#msg300473

Bill

Does anyone have any ideas?

Where you already running a haproxy-devel 1.5dev versions before or the stable 1.4 ?

For a possible easy solution you might try uninstalling the package, and then installing it again.
If that doesn't work, download a config backup, remove the <haproxy>section and restore the config file (make sure you know how XML should be formatted). Then try to install again..

As for troubleshooting it would be nice if you could change the /usr/local/pkg/haproxy.inc file and include some more lines with 'debugging' info like this between where that last line of logging is generated, and where the next one doesn't show.:

$static_output .= "HAProxy, debugging step 1\n"; update_output_window($static_output);

Then from a developer shell option 12 on the console run these commands:

global $pkg_interface; $pkg_interface = "X"; include_once('haproxy.inc'); haproxy_custom_php_install_command(); exec

And check the output generated to at which debugging step the processing 'stops'.. Then please report back.</haproxy>

it does not see my lan nic

@Cino:

try ntopng instead, just came out so their could be bugs… report any in the link below

https://forum.pfsense.org/index.php?topic=80461

Wow! Thank you so much for sharing this! I thought ntop is dead.
For some reason its not showing up in packages.
I'll ask in main thread.

@zimba:

Thanks, Bill!

I am not sure what happened but it is now working!

Sometimes the Snort.org web site has temporary issues.

Bill

Thanks a lot for both !!! For the workarround (it was a real good idea) and for the new version - we will test it next days.

I did a little research and the crash seems to be related to a memory access violation by Squid.  You're running an alpha build of 2.2 so I'm not shocked, but still.  What is your configuration? i386, x64?  Virtual, physical server or miniPC (ALIX board etc)?  Any other packages?