There is a bug where the traffic on VLAN links is reported as twice as much: https://redmine.pfsense.org/issues/3314 Separately, the WAN links where you are using your OpenVPN across may increase in latency as traffic increases. This causes the gateway monitoring agent to react adversely. I've had some success in increasing the latency monitoring thresholds in those links: System | Routing Edit the respective gateway, press 'Advanced' Change the latency thresholds (I used 750ms/1000ms) This was definitely helpful However, there may be a bug in play: @cmb: If you don't have any gateway alarms, there is a potential second cause I just fixed. Edit /etc/rc.newwanip and find where it has curnwanip in there. Replace that with curwanip (just remove the n), save, might want to reboot afterwards just to be 100% sure nothing is using the old code. Be careful when editing any code like that. That made things think your WAN IP had changed in cases where it hadn't, so it did things like restart VPNs where it was unnecessary. I'm going to revert the latency settings to default and test the /etc/rc.newwanip fix tonight. See this thread for more info: https://forum.pfsense.org/index.php?topic=76735.0;topicseen -nb

That definitely sounds like the circumstance noted in those FreeBSD PRs. The work around there is to run "ifconfig greX up" via shellcmd after boot, and have it manually add the routes that way as well. That's been fixed in 10.x so won't require any workarounds in 2.2.

I wanted to ask if imposed PfSense in bridge mode, I can apply the same firewall rules, such as the IP block, DNS Forwarder etc? Yes, as far as I know. But I don't use it in my environment. The logical difference is, you have no NAT and DHCP.

Yeah, sounds like you have the same problem that a lot of people are having. OpenVPN chokes when the bandwidth of its WAN is saturated. You see that error, and then OpenVPN restarts itself in 10-30 seconds (or so). These other threads all have the same problem from the looks of it, but no bug has been filed yet. https://forum.pfsense.org/index.php?topic=75989.0 https://forum.pfsense.org/index.php?topic=76735.0 https://forum.pfsense.org/index.php?topic=77169.0 I'm hoping this gets filed soon.  The problem has been present in 2.1.1, 2.1.2, and 2.1.3 (64bit) (versions I've tried) -nb

Which SSD exactly is it? Steve

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.