We're typically very fair about how we charge against the hours.  If the ticket requires a fair bit of research and bug fixing, no we don't charge you for the hours.  A recent notable example involves a customer who came across a really nasty bug with the mobile IPSEC code.  CMB and a couple of the developers have put approximately 30 hours into diagnosing, coding and testing the fixes, but the customer hasn't been charged anything like that.  We only assign time to a customer's account if we're actually working directly for the customer during that time. The other side of that, however, is that if the customer expects a support technician to be on the phone with them the entire time, while they try and figure out a completely unrelated problem, then yes, that time will get charged.  To date, we've had a great track record with very satisfied customers and as far as I know, we've not had to refund a single customer based on a quality of service complaint.

It's currently set to Europe/Stockholm, I have tried with the GMT setting as well. Error is the same. I guess there is just simply a bug in how the firewall log displays time, as all other places where time is shown, it's correct. A sidenote which perhaps might be of interest for debugging: If I run a syslog server or Wireshark, the time in those programs are shown correctly.  However of course I don't know if any time stamp is sent with the data from pfsense to the syslog server, or if the programs just use the computer clock.

@Cry: You could use Squid as a reverse proxy/accelerator to do that. As you said, using hostnames adds a massive, non trivial, overhead and potential delay. Thx, As I noted, when Squid is installed on the same box as pfSense, if it doesn't evaluate packets in front of the firewall then it's not a workaround (if possible at all would have to be configured on a different box). Also, if Hostname lookups were to be done along the lines of what I suggested then overhead should be at least manageable… it avoids bottlenecks of hitting the disk and requires a DNS query only initially. Utilizing a simple lookup table/array in RAM would likely be so fast and require few CPU cycles to the point I don't know if indexing would be necessary. Anyway, thx all... I'll ponder the issues if I decide to trial before the next major version of pfSense...

I'm using the same board with VLANs on the onboard NIC while I wait for my low-profile Intel to arrive and it's working perfectly for me on 1.2.3 prerelease, so you might want to try upgrading. Otherwise disabling hardware tagging might be worth a try (ifconfig re0 -vlanhwtag), or just buy a decent NIC (though these are miles ahead of the RTL8139 - I can actually get about 95Mbps throughput on this board).

go to any PC shop and buy your self a floppy drive + floppy cable (they won't believe you, insist !!) Hey i still have a stack of brand new original packed floppy drives and some unopend boxes of floppies just in case i ever need them :D The store i bought them from even had unopened original packed 5.25" drives and disks :o !

i was going by this http://blog.pfsense.org/?p=208 i guess that's outdated info

Try pfsense 1.2.3 - see http://blog.pfsense.org/?p=377 Note the remark about improved hardware support and the download link at the bottom of the page.

I try to start VPN, but this is not important. I lose connection when load satic route 192.168.0.0<->64.233.167.99. I want to restore connection without to preinstall PFsense if it possible from console.

@valnar: Exactly.  I can do that with any other self-created cert too though (which is what I want to avoid in the first place).  So what makes them special?  Am I missing something? No … yo're not missing something. As you thought already you have to buy a "official" SSL cert ... that will be the solution for your problem.

http://doc.pfsense.org/index.php/HOWTO_disable_acpi

What else is happening on this box at the time?  What kind of bandwidth usage do you have going on?  How about firewall states?

ISTR that it is enabled by default and will connect to a randomly selected NTP server from pool.ntp.org.