Hello

it`s work very well on new version of FreeRADIUS package (2.2.5)

Thank you very much

@priller:

@bmeeks:

Based on my testing, either the patched binary or turning off the delayed-detect feature worked.  Translated, that means you need the new binary if you want to leave "delayed-detect" set to "on", but if you don't have the new binary yet, you can just set "delayed-detect" to off and should still not see the bug.

It seems to be OK with that set to "off".

We tried that previously ( https://forum.pfsense.org/index.php?topic=74778.msg410720#msg410720 ) and still had a problem.  Other than having multiple interfaces then vs. a single one now,  I'm not sure what else is different in the config .. or the sequence of events to trigger it.  Anyway, looking much better today.

From my understanding of the bug and the Suricata binary code, the call to load the Suppress List entries was made and the list successfully loaded before the rule signatures had been loaded.  So there were, at that moment, no rules in the memory table for the Suppress List to match and thus the flag to "not alert" was not set for any Suppress List rules.  Delayed-Detect is an option designed for inline IPS operation that allows Suricata to go ahead and come up and start passing traffic even before all the rule signatures (detection) are loaded and enabled.  So in this mode, there is a time where traffic will pass uninspected.  In the current quasi-IPS/IDS mode Suricata uses, this parameter has no meaning but I had defaulted it to "on" for the future.  When you disable Delayed-Detect, the rules load earlier and thus are in memory when the Suppress List is loaded and parsed.  So this means rules can match up.

The reason this worked using the icons on the Alerts tab is those add the entry to the list and then initiate a "live rule swap" within Suricata.  This is not the same as a restart, thus the rules are in memory and can be matched up against the Suppress List when it loads as part of the "live rule swap".  Restarting the service, however, does trigger the bug when Delayed-Detect is enabled.

I've done two things to address this in the upcoming release.  First, I back-ported a patch from 1.4.7 to the 1.4.6 version used on FreeBSD that makes sure the Suppress List is loaded after the rules have been processed.  Second, I added a checkbox on the INTERFACES tab to allow the Delayed-Detect feature to be manually enabled or disabled by the user.  It will default to disabled.

Bill

't Works  ;D

Although it took me quite some learning, as I am an economist and not a technical guy  :-[

I too have a Ubiquity access point which supports Radius. So basically this is it:
1. I have laptop and smartphones which connect wireless.
2. I created a special VLAN for wireless only.
3. pfSense cert manager has created certificates (so: not passwords).
4. The certificates are installed in the laptop (wifi connection) and in the smartphones (android).
5. After setting up Radius to use these certificates:
5.a. The smartphone connects to the Ubiquity, which has been told to use Radius, and the address of the Radius-server.
5.b. The Ubiquity forwards the connection request via the switch to the pfSense where Radius resides.
5.c. Somewhere/somehow the client certificate (how this works is not quite clear to me, but it works) of the smartphone is offered to the pfSense radius server to indentify the smartphone. The other way around the server identifies itself to the smartphone with it's server certificate (to avoid MitM-attacks).
5.d. If this authentification is approved the Radius server tells the Ubiquity to allow access for the smartphone.
5.e. The DHCP-server on the VLAN then issues an IP and the firewall assures the smartphone can only go to the internets, and not to the LAN.

't Works  ;D

I hope this helps  :P

Bye,

If i understand your requirement correctly, what you are asking for is doable in DG… There was another thread where someone was talking about getting it working. Just saw it in the last couple days...

@torsurfer:

@pfSense2User

I think you need to enable 'execute' permissions on both the clamav and dansguardian directories. Try this:

chmod u+x /var/log/clamav /var/log/dansguardian

I made a script to chmod the entire /var/log directory called perms.sh in the /usr/local/etc/rc.d folder:

Then, I used the chmod +x perms.sh to make the file as an executable for everyone; lo and behold, it runs!

Thank you kindly!

Step 1. Go to Site Lists under ACLs in dansguardian
Step 2. Edit the Default profile….Under banned.....type all the sites which you want  time based access...Site1.com,Site2.org,Site3.net,Site4.com,Site5.org,Site6.info
Step 3. Create a new profile, example Time1.
Step 4. Under Exception lists of Time1 type the list of sites you want to grant access to
For eg you want to grant access to Site1.com, Site2.org & Site2.net from 17:00 hrs to 18:00 Mon-sat
Hence Under Exception list you will add
#time: 17 00 18 00 012345
Site1.com
Site2.org
Site3.net

Step 5. Create another profile Time2....type the list of sites you want to grant access to
For eg you want to grant access to Site4.com, site5.org, Site6.info from 09:00 to 13:00 Mon-Fri
hence Under Exception list you will add
#time: 09 00 13 00 01234
Site4.com
Site5.org
Site6.info

Step 7. Include the paths of the profiles Time1 & Time2 under the exceptionlists of Default Profile
eg..under Exceptionlist of Default profile it should be
.Include
.Include

Adding these two lines instructs dansguardian to parse these files one by one

Similarly any number of banned, exception & greylists with different access times can be created.

Im interested in this topic too. I hope someone who knows will answer?

many thnx in advance :)

After updating to never version i have issues installing every package. I actually have  this problem:

Beginning package installation for squid3 .
Downloading package configuration file… done.
Saving updated package information... done.
Downloading squid3 and its dependencies...
Checking for package installation...
Downloading https://files.pfsense.org/packages/amd64/8/All/squid-3.1.22_1-amd64.pbi ...  (extracting)
Loading package configuration... done.
Configuring package components...
Additional files... squid.inc failed.
Backing up libraries...
Removing package...
Starting package deletion for squid-3.1.22_1-amd64...done.
Removing squid3 components...
Tabs items... done.
Menu items... done.
Services... done.
Loading package instructions...
Include file squid.inc could not be found for inclusion.
Deinstall commands...
Not executing custom deinstall hook because an include is missing.
Removing package instructions...done.
Auxiliary files... done.
Package XML... done.
Configuration... done.
Cleaning up... done.
Failed to install package.

Installation halted.

I will try to disable snort and hope the best?

Many thnx for this tip. It could solve mine problem, cause i COULD install snort...

Many many thnx

My repo is not a pfsense package fork. Use only official repo.
If you need any package from my repo, use pkg/pbi via console/ssh

@fmaxwell:

@marcelloc:

The code was merged today. take a look.

I just did a package reinstall and that completely solved the inability to create a suppression file.  Thanks!

You're welcome!  Sorry about the bug.  It was totally my fault.  In adding some additional security for configuration changes, I accidentally broke saving a new list… :-[

Bill

fragged is correct.  This only impacts the IP REPUTATION preprocessor.  It is disabled by default.  I was just pointing it out as one area that can fail with RAM disks.  The downloaded rules tar balls and the individual interface rules are stored on the /usr partition.

There once was a bug where Snort did not put the /usr partition in read/write mode when trying to update some files, but I think I have all of those fixed now.  Report back if you notice any errors in the system log about attempting to write to a read-only partition.

Bill

Hi finalcut,

If nothing is shown in the firewall log, then creating a floating rule like you proposed (https://forum.pfsense.org/index.php?topic=71515.msg414518#msg414518)wont help.. Unless you have rules that match but don't log traffic. But i think that this kind of problem is unlikely to be the cause of your current issues..

You could try is disabling the trafficshaper, maybe that 'interacts' strangely with squid..??

Would also be interesting to see some packet captures of both the wan and lan side simultaneously while a failing upload is being made, so it is clear which side of the connection 'breaks'. Then combine that with logging of squid with a higher then normal verbosity and it should help in determining what part of the process causes it to fail.

Greets PiBa-NL

Hi.

There is an update for fix this.

Also, we are expecting the upgrade to 3.14.12 on FreeBSD ports, so we can update here on pfSense.

Best Regards.

Here is a link to a discussion I had in regards to blocklists.

https://forum.pfsense.org/index.php?topic=73353.msg402927#msg402927

Some of those lists are for mail servers and can be ignored. If you add more blacklists, you will need to increase the maximum table entry.

Goto  Advanced:Firewall/NAT  and increase the "Firewall Maximum Table Entries".

There is no functionality currently to see if the blacklists are downloading the lists at the specified frequency unfortunately.

Please search the forum, there are a lot of threads with dansguardian workarond configurations.

I'ts related to freebsd, not package configuration.

You can help looking for workarounds searching on google.

http://lists.freebsd.org/pipermail/freebsd-ports/2014-February/090322.html
http://sourceforge.net/p/c-icap/discussion/420422/thread/1a2978aa/
http://bit.ly/1h6nxFA

i386 version with same config files works, so in your production environment you can forward  proxy requests to a i386 virtual machine with squid and icap.

I've found you did start another thread a while before.. https://forum.pfsense.org/index.php?topic=74085
That you never got a reply is likely due to the very small amount of fragmented information you have given. "uploading file failed" is not a very descriptive title for someone to look at.

As it has nothing to do with HAProxy, and unlikely to be related to floating rules i'm not going to continue the discussion here.

@vito:

Looking at the IP Rep option I see where you can add list…
Question: It seems the list are stored locally and not pulled from a site (like PFBlocker)
Is this the norm or will added feature be coming latter to pull list from web and do scheduled updates like PFBlocker?
If I understand correctly, IP Rep “could” replace PBBlocker at some point? (or am I wrong?)
Thanks for your help and hard work on Snort (and Suricta)

vito

You are correct that, at the moment, the lists are static and stored locally.  I think some users have created their own cron jobs and associated scripts to download updates and write them to the directory.

For now, if a list is updated, Snort needs to be restarted in order to pick it up.  I am investigating some other options for the future.

Bill