"Wired and WiFi connections are part of same LAN network." Huh??  Thought you said wifi was vlan 10?  I think your not understanding what a vlan actually is.. Or for sure not explaining what your wanting to accomplish that is for sure.

Despite the lack of details, it sounds like there is a link that is ending up in half-duplex mode somewhere in the setup. Check that all links are correctly negotiating at full duplex. –A.

My FTTC connection is with Zen, who don't support YouView, so I never got deeply into this. You need an IGMP proxy running on the parent of your PPPoE interface for the YouView premium channels to work. https://forum.openwrt.org/viewtopic.php?id=52406 will probably give you some clues, though I have no idea whether the information is still current and it will obviously have to be adapted to pfSense. https://community.bt.com/t5/YouView-Boxes/Using-a-3rd-party-router-for-Multicast/td-p/1048582 may also help. Unfortunately I can't do any testing for you, as my connection is on the Zen LLU customer VLAN, not the BT Wholesale customer VLAN, so I won't have access to the multicast networks you are trying to access.

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.