Thanks Heper, yes the circuits are all from the same ISP, you've helped me understand the issue, I know what I need to do to get around this, esxi only allows 10 maximum vnics, but I can also add passthrough devices which it does not count towards it's maximums, so I will use one vswitch with 10 vnics ports, each in its own vlan, and then I will install a dual port nic and do passthrough(i've already done one nic) so will end up with my required 12 and no vlans done through pfsense.

Hello again I just installed 32-bit pfSense on a physical machine and as expected it ran just fine. Someday I might revisit this issue and see if I can find a working libvirt configuration, but for now this works.

Diagnosis so far… I can ping 8.8.8.8 from the default source with no packet loss I can ping 8.8.8.8 from the WAN source with no packet loss I can't ping 8.8.8.8 from the LAN source - 100% packet loss. I believe this indicates an outbound firewall rule issue, which I have set up as: NAT->Outbound Automatic Outbound NAT rule generation WAN  127.0.0.0/8 & 123.168.4.0/24  *    *    500    WAN address    *    Yes WAN  127.0.0.0/8 & 192.168.4.0/24  *    *    *        WAN address    *    No

Is this a single system or part of an HA cluster with CARP? What features are you using? Which version/architecture of pfSense? At first glance I'm inclined to say it's hardware since it's crashing in what appears to be some memory management, but not allocation or I'd say it's run out of some resource. If you can capture more crash reports, attach them here (attaching as a .txt file would be better than pasting inline)

I am not sure about what happened but seems that the config.xml file became not manageable anymore and PfSense got stuck on reboot. I had to restore an old config.xml and clean the config backup directory from all files were there. I am assuming that pfblocker lists I use started blocking too many hosts and the config file became too big. Do you think this can be indeed the root cause? Zeno

A little bit of Google pointed to this: http://forums.xfinity.com/t5/Basic-Internet-Connectivity-And/Re-keep-loosing-signal-on-Arris-TM-722/m-p/2346077#M213125 Basically, the cable side of the device is likely sensitive to signal quality (power levels and SNR).  Walk the coax from outside your house to where is connects to the Arris;  if there are any splitters in there, see if you can get rid of them.  Most areas Comcast serves should be all digital (no analog TV signalling), so any splitters need to be higher quality and higher bandwidth than generic ones from Radio Shack or your nearest electronics store. It could still be a sw issue, but I'd verify physical connectivity first

One other note on VLANS, if you're mostly supplying customer internet via WiFi then it probably doesn't matter much. But if you offer hard wire access to rooms there's some definite security advantages to using VLans to isolate each room to it's own subnet. Not to mention the ability to diagnose where excess download traffic is coming from.

With your listed uses, that hardware is tons of power (both network wise and electrically  ;)  ) Unless you get into RAM intensive packages like Suricata/Snort 2GB will be lots. HD vs SSD similarly won't gain you anything unless your package requirements change (even then - not likely). If and when you move to 500/500 speeds, you might have to look at more CPU power, but probably not.

i have upgraded pfsense to 2.2.4-RELEASE (amd64) built on Sat Jul 25 19:57:37 CDT 2015 FreeBSD 10.1-RELEASE-p15 Congratulations! but i am facing problem with LACP. ??? Would this perhaps help you out with the right information? LAGG (LACP) Behavior Change LAGG LACP defaults to strict mode in FreeBSD >= 10 my switch (that was working prior this changes) probably doesnt' support LACP strict, There are two different ways to set up a LAG (Link Aggregation Group) dynamic LAGs automatically using the LACP (Link Aggregation Control Protocol) static LAGs manually using "setting up" the LAG right and fully identically on both sides by hand Which mode your Switch is supporting? but if i put the sysctl modify proposed here (net.link.lagg.0.lacp.lacp_strict_mode) https://doc.pfsense.org/index.php/Upgrade_Guide#LAGG_LACP_Behavior_Change Ok you where now having created a so called work around to get your switch with limited LAG capabilities or functions working, is this correct? But did you also create a /boot/loader.conf.local file to store this informations for the next pfSense update or upgrade process? Because then all files will be new written and created and your small work around is gone! but if you were creating a loader.con.local file there are not gone! at reboot this option doesn't get kept. For sure! You are changing something at the system and this changes will be persist, for sure, it is a must be because after a reboot no one want to set it up once more and more and more again! can you please give me some information about that? The update or upgrade process will be write all or many files new! So that the former information is not there after this process. Create a /boot/loader.conf.local and put all the changes you made there in and then after an upgrade of the whole pfSense system, do a reboot and all changes will be made once more again automatically.

Something you perhaps misunderstand, given what you describe: when configuring FW, rules apply at "input" level, not "output". This means that is you want to, e.g. grant access to DMZ from internet, you will have to configure rules at WAN interface, source being, most likely, "*", destination being your DMZ.

If you wiped your config and didn't upgrade you're doing it wrong.

Depends on how big of a config it is. George should get back to you on Monday, probably will want to setup a quick Webex to review what you have in place now to put together a scope of work and cost.

go into the developer shell once and create a script: pfSense shell: record checkopenvpn_status Recording of checkopenvpn_status started. pfSense shell: require_once("openvpn.inc"); pfSense shell: $clients = openvpn_get_active_clients(); pfSense shell: print_r(array_values($clients)); pfSense shell: stoprecording Recording stopped. then either do from devshell playback checkopenvpn_status or from normal shell or console: [2.3-ALPHA][root@pfsense.xxxx]/root: pfSsh.php playback checkopenvpn_status Starting the pfSense developer shell.... Array (     [0] => Array         (             [port] =>             [name] => vpn to xxxx             [vpnid] => 1             [mgmt] => client1             [status] => up             [connect_time] => Sat Oct 3 1:49:14 2015             [virtual_addr] => xxxx             [remote_host] => xxxxx             [bytes_recv] => 151003156             [bytes_sent] => 151211004         ) ) adjust however you want offcourse. relevant functions: openvpn_get_active_servers(); openvpn_get_active_servers("p2p"); openvpn_get_active_clients(); for more insight: https://github.com/pfsense/pfsense/blob/master/src/usr/local/www/status_openvpn.php

Much easier fix: https://github.com/pfsense/pfsense/pull/1954 - merged and will be fixed in next 2.2.5 snapshot.

use cheap webhosting instead of vps :) ssh everywhere

Thanks!  I kinda had that vibe.  Just wanted to check