For Squid3 (3.4.10_2 0.2.5), on pfsense 2.2 you need ipcs and ipcrm from a 10.1 base.
The diskd text should reflect that, now it still refers to 8.3.

diskd uses a separate process to avoid blocking the main Squid process on disk-I/O. To use ipcs and ipcrm on squid, Download livefs.iso from ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/8.3/ mount it and copy /usr/bin/ipcs and /usr/bin/ipcrm to your system and set them as executables. diskd uses a separate process to avoid blocking the main Squid process on disk-I/O. To use ipcs and ipcrm on squid, Download livefs.iso from ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/ mount it and copy /usr/bin/ipcs and /usr/bin/ipcrm to your system and set them as executables.

Simply deleting /var/log/radacct/timecounter/db.daily and starting the service fixed the issue.

The newly created db.daily is 64 KB, not 16 KB. So it looks like it got corrupted somehow.

How do we prevent this from happening in the future?

Thank you

First add a backend, in there you can add multiple destination servers.
To actually use it, you also need a frontend that uses the backend and listens on a port.

Thanks for your reply.  I definitely have some reading/digging to do but that link appears to contain helpful information for the active directory piece.

@johanstrand:

Hi!

I had it set to AC. I changed to AC-BNFA and it Went from 1.3GB to 380MB. Maybe this was the reason for the original problem. I am still suspicious of the rules because now (after resinstall) I can activate all rules using AC as the pattern matcher and snort starts without any problem and it takes about 1.4GB of RAM.

I can not reproduce the reconfig thread problem.

/Johan

The AC pattern matcher will slowly gobble up RAM as it operates.  I have seen posts on other sites where users have had it gobble up 16 GB of RAM and more with a lot of traffic and rules.

There is no appreciable difference in the performance of any of the pattern matchers on today's hardware.  AC-BNFA or AC-BNFA-NQ is the suggested setting, and I would advise to never change it.

Bill

@webstor:

Tried, couldn't fix it.
Still the icap error. Maybe related only to amd64 ?

Check your logs
the icap is working on 0.2.4 version.

There is a typo on clamav config check that i'll send a fix today.

Well I'm trying to eliminate any security measures from a certain lan due to bitching about the rules blocking stuff… so adding snort to the wan will probably cause more issues and they are not willing to troubleshoot.

Surely I know and have used Squid as cache. But never more than that.
Thanks for pointing me to it.

I figured out how to fix the issue.

First I had to learn some Squid bits and figure out how the Squid.conf is interpreted (ie. top-to-bottom for first-matched ACLs) and what some of the various "tags" mean. I found the following link quite useful to get some basics under the belt: http://www.deckle.co.uk/squid-users-guide/squid-configuration-basics.html

After grokking the Squid.conf that was generated by pfSense, I figured out what the existing reverse-proxy configuration ACLs were (as it was needed to for the cache_peer_access tags).
For those interested, you can use the "Edit File" function under the "Diagnostic" in the webconfigurator to browse to the generated Squid.conf file.

In my case it was under: /usr/pbi/squid-i386/etc/squid/squid.conf
Note: Yours may in in a different location if you use a different version or have the AMD64 version of pfSense.

After figuring out how these are interpreted by Squid (i.e. the order, precedence, overrides, etc.) with the help of the above link, I understood what was needed.

I looked up all the reverse-proxy ACLs generated by pfSense and create an tcp_outgoing_address tag for each using the LAN side IP (or DMZ side if that's where you are reverse-proxying to).

For example, the following is what I ended up with. This must be placed above the bits for the random ACL to load-balance the forward-proxy. 192.168.0.254 is the IP of my LAN side interface:

tcp_outgoing_address 192.168.0.254 OWA_URI_pfs tcp_outgoing_address 192.168.0.254 rvm_Extranet tcp_outgoing_address 192.168.0.254 rvm_Prototype tcp_outgoing_address 192.168.0.254 rvm_WebService tcp_outgoing_address 192.168.0.254 rvm_License # Put load balancing tags after setting the tcp_outgoing_address for reverse proxy tags acl fiftyPercent random 0.5 tcp_outgoing_address <<wan1-ip-here>> fiftyPercent tcp_outgoing_address <<wan2-ip-here>></wan2-ip-here></wan1-ip-here>

The result is that for the reverse-proxy traffic goes to the specified LAN side IP , and then the remainder of all other traffic is load-balanced via the random ACL on the WAN IPs.

Hope that helps anyone else who might run into a similar issue.

+1.

Running one firewall with pfSense 2.1.5 (AMD64) + Squid (2.7.9) + SquidGuard (1.5_1.1 beta) + Snort + pfBlocker and have no issues. Proxy is NOT transparent.

Running another firewall with pfSense 2.1.5 (i386) + Squid3-dev (3.3.10 pkg 2.2.8) + SquidGuard (1.4_4 pkg v.1.9.5) + Snort + pfBlocker and have no issues. Proxy is NOT transparent. ClamAV is not enabled as I get ICAP timeouts.

Both are stable and responsive.

Hth.

Cool! Glad to hear! Those instuctions were directly from my own setup, so if you need any further assistance I'll help where I can.

Use the setting upstream proxy.

Can any one help me?

By the way, if you come up with a collection of working rules for OpenAppID that you think others would find useful, please share them here on the Forum.  This is a new technology, and group collaboration would be a good thing as folks learn and try it out.

Bill

I found solution! On the user check attribute add Calling-Station-Id += 'mac adress', | Calling-Station-Id += 'mac adress', | and more if need… before I try syntax := and this not working..

Currently Emerging Threats offers no lower cost versions that I am aware of (excepting the free Open Source version you mentioned).

You can use the Snort VRT rules with Suricata, but there are around 700 of those rules (if I remember the count correctly) that will not load because they contain keywords Suricata does not recognize.  They won't break Suricata, but any protection afforded by the non-loading rules will of course be sacrificed.

Snort VRT does offer a home-use annual subscription for their latest rules.  It is $29.99 USD per year.  That's certainly cheaper than $500 USD per year.

Many folks use a combination of the ET-Open free rules and a paid Snort VRT subscription.  Of course if you are a commercial enterprise, $500 per year is generally not considered an excessive expense for cyber security protection.

Bill

Mine did not install at first.
Just hit back in the browser and installed again.
Second time it worked.