Well again look in the resolver log..  This is where errors in the resolver starting up would be listed.. Increasing the verbosity would log more info.. How is this NOT answering your question?? [image: resolverlog.png] [image: resolverlog.png_thumb]

We have this running for years now. Keep in mind that you need a subnet on both the cable and DSL (only 1 IP will not work with CARP, you need at least 3) Our cable is faster than the DSL, so I have set up just a gateway switch, when cable is down it switch to DSL (gateway groups) So if your cable and DSL have a subnet, you can connect them both to both pfsense

@dbennett: We have a wild card cert purchased from Godaddy for our company.  I would to create an intermediate CA off of that so certs I create within my company will validate back to Godaddy essentially adding us to the chain. So  Godaddy -> my company -> my certs.  Essentially our own internal intermediate CA We are creating OpenVPN users with certs and the boss would like those certs authenticated back through us to godaddy. I'm assuming it can't be done but thought I would ask. As johnpoz says, you won't be able to do this. There will be a flag in the Godaddy certificate that says 'cannot act as a CA'. Even if you forcibly sign your CA certificate with the Godaddy certificate, the signature will not act as part of a valid CA chain. It is sometimes possible to get a CA certificate signed by a CA certificate in the public roots, but they come with considerable security requirements (typically including storage in an HSM), are for a limited range of uses and are extremely expensive. Most CAs never issued these certificates and those that do issue them may well insist on retaining physical control of the certificate and using it to sign objects at your request so that they can ensure the security and usage limitations are respected. Issuing user certificates would almost certainly be outside the usage scenarios for a CA certificate signed by a public root even if you did possess one. Typically, you cannot use an intermediate certificate to do anything other than issue server certificates for DNS names. As you can get server certificates chaining to a public root for addresses in the public DNS for free thanks to StartSSL and most people never look at the contents of a certificate, having your own CA that chains to a public root is of limited value. Your boss needs to understand what is being asserted and by whom. In the case of a VPN user certificate (or user certificate for a Windows domain), the assertion is that user X is a member of your organisation and is potentially entitled to use its resources, which is rightly made by a CA controlled by user X. There is no need for the CA making that assertion to chain to a public root as no member of the public will be relying on the assertion in the user certificate.

"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