@ermal: You can disable the state reset under advanced options. Perfect.  It might be a good idea to have that state clearing option log its action though.  I would have never guessed it was a feature.  Also maybe some type of a delay - looking at the logs, the whole down/up cycle is only 2 seconds. @ermal: Otherwise this is your issue cabling/switch/etc not a pfSense one. Same cable and hardware as when I was running 1.3, so I kind of doubt it.  If I can find an easy way to move the WAN to another interface, I'll try that and see if it looks like an 8.x issue with the xl driver.  Odd that's it's doing this at 2 a.m. everyday though…

heper thanks  :) so this means that it's NOT officially supported "Out-of-the-Box?"

@wagonza: @Loke: This will put old way to gather CPU stats back. or just update to the latest snap. When i wrote this there was no fix to this. Already fixed so this topic can be closed.

Confirm same thing. Very annoying. Would be great to have an option to turn this message off. And to know what is this at all.

I'm still on the issue. I don't have any other network card to put on it. I've been keeping on date all the new releases of the version of my pfsense machine, but there is no solution yet, only way is to reboot the machine. It's OK that problem is a driver bug, is there any way to report to developers to solve it? Internet forums tell that there are patches to resolve this on FreeBSD OS, but I don't now how to put this one on a pfsense machine. Thanks jimp for your response.

I don't know if this will help, but update your bios if you haven't. X7SPA0.C17 http://www.supermicro.com/support/resources/getfile.aspx?ID=1124

You might have better luck with lower-than-1500 mtu settings.

pfSense supports whatever the driver to your hardware in FreeBSD supports. (And what your hardware is actually capable of). This might help you: https://spreadsheets.google.com/ccc?key=0AojFUXcbH0ROdHgwYkFHbkRUdV9hVWljVWl5SXkxbFE&hl=en#gid=0

Hmm… I was kinda hoping it would help :-) I don't know if it still is a problem, but I read somewhere here in the forum that when using load balancing, people trying to access https will get problems. Is this still true? If so, do you know if I can use a rule to keep them on the same connection for the duration of the session?

I will lock this topic and it can continue on the specifc threads.

could it be linked to the fact that the outgoing traffic from this VPN server has a non-default gateway (wan fail-over) ? how could i set it up so that does not interfere ? with policy filtering (having the inbound traffic marked and have another outbound rule on front of the first one, having the default gateway set up instead) ?

It is fixed now. The problem is from DNS, since WAN is set DHCP it will use DNS of modem. Thank you Giang

@ermal: What do you mean by disable? As in logging onto the standby CARP firewall, then going to "status", "carp failover", and clicking "disable carp".  After I've done that  I would expect the cluster to remain disabled until I manually re-enable it. Then I can reboot the firewall without it taking back over as master when I don't want it to. Thanks

I'm seeing something similar in my System Logs. I'm running in a ESXi 4.1 VM with only package installed vnstat2 and Snort. 2.0-RC1 (amd64) built on Tue Mar 22 00:31:28 EDT 2011 Mar 23 21:05:18 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 20:05:18 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 20:05:18 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 19:05:18 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 18:05:18 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 18:05:18 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 17:05:17 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 17:05:17 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 16:05:17 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 15:05:18 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 15:05:18 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 14:05:17 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 14:05:17 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 13:05:17 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 12:05:17 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 12:05:17 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 11:05:17 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 10:05:17 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 10:05:17 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 09:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 09:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 08:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 07:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 07:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 06:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 05:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 05:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 04:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 03:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 03:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 02:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 01:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 01:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 23 00:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 22 23:05:17 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 22 23:05:17 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 22 22:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 22 21:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 22 21:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 22 20:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 22 19:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 22 19:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 22 18:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 22 17:05:16 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 22 17:05:16 dnsmasq[38221]: read /etc/hosts - 26 addresses Mar 22 16:05:17 dnsmasq[38221]: read /etc/hosts - 26 addresses Mar 22 15:38:39 dnsmasq[38221]: read /etc/hosts - 25 addresses Mar 22 15:38:39 dnsmasq[38221]: read /etc/hosts - 25 addresses

Just to clear my issue up, to fix the slow loading just go to the LAN firewall rules, and make a rule for 192.168.100.1 and 192.168.100.2 and bind 192.168.100.1 to WAN1, and 192.168.100.2 to WAN2. (192.168.100.1's gateway will be WAN1, 192.168.100.2 will be OPT1)

Rebooting from the shell seems to have fixed the problem for now. I can't seem to get the RRD Graphs page to load (it seems to hang trying to connect to the page but not actually displaying anything) and that was happening before the upgrade as well. But I can get to the GUI and the PHP error is gone at the shell.