Right now the only thing I can think of is the length of your cable from pfsense and the switch. Sometimes a longer cable will fix the issue.

This changes in pfSense 2.0

I'd try UPnP (understanding the security risks) or forward the relevant ports.  If you don't know what those are then a forum about this "xfire" you're talking about should be able to help.

You need to know what type of VPN is being used - IPsec or PPTP.  Once you know that then it should be easy for people to direct you to the right piece of documentation.

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).