You can monitor the states that are made. All clients should connect to whatever is the default gateway on pfSense. You can control which gateway is used for what traffic / which host with policy routing and/or using gateway groups.

ADSL (at least here in South Africa ;) ) is provisioned using PPPoE to setup the connection via Telkom (the big monopoly on copper last mile) to the chosen ISP's IPC (The ISP's data centre from where they provide the internet data) So that is the part that is a constant for all the users and ISPs, and Telkom issues a random IP for the duration of your connection from the network block the ISP have provided Telkom for their users in a certain region. The L2TP is then a separate tunnel (as would've been any other VPN/tunnel over OpenVPN/IPSEC/L2TP/PPTP/etc.) over the internet (though in the case in point it's using the ADSL line  with PPPoE) to then  provide a fixed IP address for the user of that ISP. The issues is specifically the authentication/shared secret part of the L2TP over IPSEC that is not usually implemented by pfSense and other opensource L2TP codes, but typically only by the closed source "pricey" routers the ISPs then dish out for these static IP solutions.

really the problem was the limiters. i disable the limiters and the backup firewall not failed again. Hopefully this problem will be resolved in the release 2.3 thanks for the efforts

Thanks guys. I had used smokeping for years set up on a raspberry pi, but i just gave it away to someone to use as a media center. Im going to get a raspberry pi 2 here soon. I will then demote my other pi to smokeping duty.

I think you will have better luck in forum with your native language..  You see a good product where? pfsense will pretty much run on anything here is some min requirements https://www.pfsense.org/hardware/

Normally you just change the static IP of the LAN interface. Once that's done the DHCP server will serve up addresses in the subnet defined by the LAN interface.

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.