I would suggest it isn't worth running Squid in your scenario. 256MB may be just enough but you could run into trouble. There are people running Squid on the Alix but almost all using it with caching disabled, just for web filtering. Even then it's not recommended. Steve

If it's not built into the kernel you can get it here (assuming you're running 64bit): http://files.pfsense.org/jimp/ko-8.3/amd64/hpt27xx.ko You will need a large amount of RAM to use that disk space as a Squid cache. You probably won't save a huge amount of data either unless you have a large number of machines/users at your end. Steve

@wisowebs: Jason, wanted to say thank you.  I was tagging my traffic in PFSENSE and VMWare which caused my apparent issues. I got it working early this morning with a bit of re-configuring, and adding more nics on the pfsense box. Ok, glad to hear it.

I work for a DE company - so yeah they do some oddball shit ;)  Why would anyone pay for a connection that gets reset every 24 hours?  Asinine!!

^Yes, exactly. Many things wrong there. Looks like you accidentally pasted a part of the xml file. What were you trying to do there? Steve

Not necessarily. If Snort is slowly caching everything it looks at and then resets it when it reloads its ruleset that might produce a similar graph. If it's doing that without any traffic flowing through the box that would be more weird. Steve

Thank you chemlud, next time this problem occurs I can check whether I can get around it this way. Telekom-gateway not responding to ping is not such a severe problem. As long as I have a reliably substitute for monitoring this is fine. It would be a problem however if a problem with connectivity is not on my side but in the Telekom network between the default Gateway and other hosts in the internet. Fortunately this seems to be quite reliable …

If using floating rule ensure that you select the interfaces an the direction traffic goes.

Thank you for this

Ouch. Never the underestimate massive coincidental failure.  ;) Often things start to fail and go unnoticed, only when several things have failed or are failing do real problems show up. Then when you investigate you find what appears to be a string of failures but you look for a siongle point of failure because that seems more likely. Of course most of the time it is just a single point of failure.  ::) Steve

Thanks, I see this was closed a not a bug.  I have another pfSense system to install and I will see if I get this issue as well.

It is just for Nano installs. The are mounted RO by default and should have been since 1.2.3. 2.1.3 is built on FreeBSD 8.3 so you should be using those.  ;) Since 8.3 is still the current  it hasn't been archived yet so you can just add packages by their name directly without having to specify the entire path. Steve

You can set a proxy bypass in the client configuration/options on the individual workstations/browsers. Otherwise you'll need to make sure that your local DNS resolves the hostname to be the actual local/internal IP address of the web server.

Alright, thanks for the info. I will place an order for the APU then.

What I want to do is stop traffic between the 192.168.2.0 and 10.0.0.0 networks - Ive tried a few fire wall rules and also block private networks - from the interface section but I'm not having much luck If you block private networks on these interfaces there will be blocked everything, cause your LANs are private networks. Basically pfSense only allow traffic which is proper to a configured firewall rule. However on LAN interface there is a predefined rule that allow traffic from LAN net to anywhere. If you don't want this you have do delete or edit it to fit to your purposes. If you just want to isolate your 2 LANs add a rule to each interface to pass traffic, in the destination area check "not", select network in type-dropdown and in the underneath field enter the other LAN network and mask. Delete any other rules. This allow access to anywhere, but the other LAN.

same solution works for 2.1.3 :)

The problem has been solved! Set in a private ip in squid do not pass on it. Bypass proxy for Private Address Space (RFC 1918) destination Do not forward traffic to Private Address Space (RFC 1918) destination through the proxy server but directly through the firewall.