I've found the following 0 byte files that are being written pretty often (no idea what with, or why the writes are so large) [2.0.1-RELEASE][root@pfsense]/var/log(33): find / -type f | xargs ls -lt | head -n 2 -rw-r--r--  1 root      wheel          0 Sep 19 17:15 /tmp/tmpHOSTS -rw-r--r--  1 root      wheel          0 Sep 19 17:15 /var/db/currentipsecpinghosts [2.0.1-RELEASE][root@pfsense]/var/log(34): How can I stop these files being written? Cheers, Yax

Oh wow, i feel stupid, I did change the configuration on the client… I accidentally removed "10.0.0.2  serverhostname" from the host file... But I still get loads of these entries in the log, almost one every second... Is that normal?

So pinging to wireless clients from wired should work, but make sure your resolving the mac.  After you trying pinging a wireless client from a wired client.  Check the mac for that IP in your arp table arp -a from a cmd prompt on the box your pinging from. As stated quite often with wireless to wireless you could have Isolation setup so wireless clients can not talk to each other.  And depending on the wireless router, and if using say a guest wireless network.  You could be preventing wireless from talking to wired. First thing I would do when attempting ping is verify MAC is resolved.  And that mac is correct, if correct and still not working - verify host firewall allows icmp/ping – this is common for that to be blocked on say windows default firewall settings.  If firewall is ok, and mac is ok - I would sniff on both pinger and pingee and verify your seeing the traffic go out the wire, and that the pingee is seeing the traffic. This really is just basic network troubleshooting 101.

Perhaps my first layout picture was a bit fuzzy. I only mentioned the IPsec tunnel because I thought there's a small chance it would matter but I really don't think it will. My lab setup has no vpn or IPsec connections whatsoever. In the live setup both the regular and the guest networks connect directly to the internet, with only the regular (corporate) network connecting to an IPsec tunnel. Btw, I rebooted PfSense after setting up the second nic and the firewall behaviour didn't change so it's not a hiccup. But it works so I'm happy :)

We've been running production v6 networks for about a year and a half, no issues.

The full config isn't held in memory, nor any parts of the actual config.xml that are usable. Your firewall rules should be accessible in /tmp/rules.debug maybe, may have to run "pfctl -vvsr" to get the list. That's the list in PF syntax though, it'd just be a reference you could use to recreate from scratch once you're on a fixed hard drive. Other services have config files in a variety of places but mostly on disk, the configs they're running with now that the disk is gone aren't extractable. Unfortunately you're probably stuck with the exception of the firewall rules.

I have also heard of cheap, software based NIC's causing those kind of performance issues.

I don't have v2 installation. Back when I was installing this server, v2 was still flaky, and since then 1.2.3 performed flawlessly. I've tried all major browsers, same result. I understand that my version is too old, maybe time to get out of my shell :)

Anyone please  :-[

The logs for cron are not configured in syslog – however, if you enable remote syslog, and tell it to send "everything" it will also forward the logs for cron to a remote box where you can see them. In a cron script, always make sure you use the full path to every command - even date, cp, rm, etc. That or at the start of the script, set your own PATH variable to include the directories where the binaries you need lie.

The pfSense WAN adapter? No. The wan side of pfSense can be a private network. Steve

johnpoz is correct. Block ALL ports and ONLY allow  the standard ports like 80 and 443. I haven't tried blocking hotspotshield with squidguard since i am running squid in transparent mode. try doing my suggestion and post your results here.

I moved it, no problem.

You probably need to add routes at sites A and C so that they know how to get to each other: via site B. Unless your are pushing routing information or running some routing protocol it's probably easiest to just add them as static routes. Steve