The apinger process periodically pings the WAN gateway (by default) in order to monitor the quality of the connection. If it sees excessively high pings times or packet loss it flags an alarm. If either metric become very high it will mark the interface as down. If you are using fail over this is used to determine which WANs are good.
Usually I would expect to see a warning in the logs about either 'delay' or 'packet loss' before the WAN is marked down however if the condition is extreme enough it may go straight to 'down'.
If the quality of your WAN connection is such that apinger is being triggered too early you can tune the thresholds in System: Gateways: Edit gateway: Advanced. You can also disable gateway monitoring completely if you don't need it fail over or load balancing (if you only have one WAN).

Steve

firewall, vpn for sure.

but utm, i can't seem to find from the features page http://www.pfsense.org/index.php?option=com_content&task=view&id=40&Itemid=43

Thank you, Steve.
I have one more question here, can you please help me?

Noted and thanks, I'll give it a try :)

Seeing those PHP errors often means some file is missing or corrupted. Have you installed/uninstalled any packages?
If there is nothing helpful in the system log then it would a matter of digging in the code to see what is being passed to the php code that it can't handle and why.

You may have found a legitimate bug of course.

At this point, unless you really have a need to know why this happened, I would probably reinstall and see if it is repeatable.

Steve

Edit: You could look in /tmp/PHP_errors.log

@matguy:

I say to go Low-Fi and get a bull horn to announce it loudly.

I might end up with a few dozen strays at my door waiting to start a fox's chase with this system…..
However, these kind of approach might even resolve a long standing problem i had with my firewall, as some buckets full of water can ensure a pass through better than any sophisticated rules, with a bang  :D

pfSense 2.0.1 (the most recent release) is based on FreeBSD 8.1 and hence supports hardware listed here:
http://www.freebsd.org/releases/8.1R/hardware.html

It looks like you have an express card slot which would be the best expansion option for you though I've never tried that with FreeBSD.  :-\ USB NICs are generally regarded as poor performers both in terms of reliability and throughput. Some people are using them with no problems though so YMMV.

Another possibility is to use a VLAN capable switch to create VLAN interfaces. In this situation you only need a single NIC.

Steve

There were some conditions when squid(2) and squid3 could leave the filesystem in RW on nanobsd. I fixed these up a week or 2 ago. If you have reinstalled squid or squid3 recently then you should have got these fixes, even on 2.0.1. Now squid/squid3 should always leave the "/" and "/cf" filesystems in RO on nanobsd after finishing its installation/configuration/startup. This is a good thing for nanobsd.
If anyone was relying on the previous (undesirable, accidental) RW behaviour, then they will notice that they can no longer write to places like "/usr". In that case, on-the-run/temp files need to go in "/var" somewhere. When something really needs to be saved and survive reboot, then it needs calls to conf_mount_rw() and then conf_mount_ro().
I am not a Sarg user just yet, so I am not familiar with what it is doing with saving reports on nanobsd.

Problem was on side of ISP

You can bond DSL connections from the same provider with MLPPP (if your ISP supports it), but you can't bond VPNs.

We tried a few different ways to make that work before, using lagg and such but never did get it working in a way that was functional in a usable way.

It's something we've thought about before but unless some major funding shows up for it, I doubt it'll happen any time in the near future.

It might be possible to do something like a tap vpn on three separate WANs and then a pppoe server on one side and a bonded mlppp client set for the tap interfaces. Just a guess there though, no idea if that would actually function.

Yes that's right it makes one interface per potential client.

just my $0.02, it seems like a MB issue to me. realtec is some subpar nics imo. I have been burned by alot by the cheaper realtecs and some by the higher end.

Hi,
Eight moths later, I'm having the same issue with 2.0.1-RELEASE (i386), using just one layer7 rule (httpvideo), sending this traffic (mostly youtube) to a low priority queue.  I'm getting:

ipfw-classifyd: unable to write to divert socket: No buffer space available

…about 10 times per minute, with CPU load never reaching more than %20, and near 5% most of the time.
I have 3GB ram, although it seems nothing to do with this problem.

While seen these errors, the filtering seems to be working fine... and the queue is getting the expected traffic, but only after a while, when the entire VLAN will lost connection.  After removing the layer7 rule, everything works fine again.

I have spent days and weeks searching and reading about this error, but I have found no solution yet.  If my cpu and memory are resting most of the time, why I'm still getting this error? what other system/kernel parameter I should look at?

Thanks in advance....

Try to follow this guide for either UPnP or Port Forward, personally I use UPnP.

http://forum.pfsense.org/index.php/topic,13887.0.html

I am interested in this too.

It has been announced that CODL will be finding its way into the Linux kernel very soon.

OK, AICCU did not give the interface another name than tun0.
I have patched away "tun" in $vfaces = array (   from /etc/inc/util.inc in the "get_interface_list" function, and it does now recognize the interface and I can use it in pfsense for rules and stuff :)

Maybe that helps others ;)

Thanks

@arnoldg:

i have some problem with one specific lan ip adres, but i don't know how to monitor all of it's trafic on all of it port's

If the problem is in interaction with other systems on the same IP network then you can't really do anything on the firewall to help because the traffic goes direct, bypassing the firewall.

If the traffic goes through the firewall you can monitor it by running tcpdump from the pfsense shell or through the web GUI at Diagnostics -> Packet Capture and specify the IP address of the system "of interest".