My understanding is the authentication is certificate based, which I don't have access to so no way out of that. I was hoping pfSense had some Layer 2 capabilities baked in, but was a shot in the dark. I have a Dell 5424 switch which should in theory be able to only allow the 802.1X packets through to the RG and everything else to pfSense, however I'm having trouble just getting the RG and ONT to talk through the switch in the first place before any ACLs get applied. I appreciate the reply!

@tuscany22: I just wanted to get this posted out there so people could see it, as it sounds like there are major issues with ipsec vpns on 2.2.5 and 2.2.6. I do not agree that we should all wait for 2.3 or run 2.3 as a dev instance in production. I believe the issue should be patched in the 2.2.x tree as running to 2.3 may introduce other issues. pfSense 2.3 is based on FreeBSD 10.2-STABLE, which is FreeBSD 10.x some time after 10.2-RELEASE. pfSense 2.2.x is based on FreeBSD 10.1-RELEASE. This means there are a fair number of changes in the base operating system between the two versions. With no clear idea what triggers the crash and which FreeBSD change(s) would need backporting to the 10.1-RELEASE build used in 2.2.x to fix it, there's really not a lot that can be done. The vast amount of effort needed to bisect the issue really cannot be justified considering that a further 2.2.x release is unlikely and 2.3 is probably no more than a week or two from beta. Apart from packages, many of which still need some work, 2.3 is already very accomplished. It is only the packages situation that is stopping me from running 2.3 in production today.

Just an update here - this looked to be related to the TCP offload engine being 'enabled' after upgrading to PFsense 2.2.4 a few months ago.  I didn't start noticing issues right away, but when I did they were connectivity limiting.  For some reason only my master firewall had this enabled, the backup firewall did not get the TOE option enabled after update. Disabling TOE fixed this issue. We've since upgraded to 2.2.5 and the issue did not repeat.

@jimp: Not currently, no. It requires console access. I travel the 300 km to enable the TRIM support, sure I don't forget this the next time  8)

System specs: Super Micro: SYS-5018A-MLTN4, quade core ecc processor, quad intel gig nics, http://www.supermicro.co.uk/products/system/1u/5018/sys-5018a-mltn4.cfm 8GB Kingston ECC Memory Please remember this is not a Intel Atom (Rangeley) platform, it is a Intel Atom (Avoton) SoC! Rangeley = AES-NI & Intel QuickAssist Avoton = AES-NI & TurboBoost So enable PowerD (hi adaptive) is a must be on that platform as i see it right. 64GB SSD Activating TRIM would be fine, if you use the Squid proxy also for caching. I never see my CPU usage more then 3%, it is usally at 0% even if downloading or uploading a big file.  Under System Activity my CPUs are always very high on the idle. This might be related to the missing PowerD option that scales the CPU right on much load and also if there will be no load. Why is it doing this and not working harder to process?  on speedtest.net i went from 120Mb down to 4Mb down… streaming video like on Cruncyroll is not possible...  I uninstalled all squid, and disabled snort, still no change.  only service running is the firewall. For Squid and streaming portals, some peers can be set up. I already set kern.ipc.nmbclusters = 1000000 Would be also fine, because 4 LAN Ports and 4 CPU cores are creating then many queues. 4 CPU cores * 4 LAN Ports = 16 queues Perhaps you will have a look at this site to dig out some tips for squid performance tuning.

I have now deleted the other interface. I am using a old VIA EPIA board with a dual PCI riser. The NIC is a Intel PRO/1000 MT Dual port. The WAN interface now uses these settings: IPv4 Configuration Type: PPoE (+ PPPoE configuration username and password) IPv6 Configuration Type: DHCP6 Block bogon networks: ticked So far it has survived one reboot, however it took a few minutes for the internet connection to come alive once pfSense rebooted. If this fails, I will change the patch cable and try another interface. I cannot try the MTU 1500 patch as my system is 32-bit.

This: @Koenig: Feb 17 20:02:39 php-fpm[91218]: /rc.filter_configure_sync: filter_generate_port: is not a valid destination port. shouldn't happen. Checking /etc/rc.filter_configure_syn.rv will bring me to /etc/inc/filter.inc and deep down in there function filter_generate_port will pop up the error : some source port in a (firewall / NAT ?) rule has no valid source port. Btw : which pfsense version ?

Try this : put a switch between pfsense and your modem….

Convert your WAN to another LAN for the time it takes you to get in and change things.

@mudmanc4: Thanks for the reply, and I should clarify to insure were on the same page: So would this require adding a route in the VPN client, to allow only the LAN subnet ? Reading what you wrote, I dare say yes, just pushing the route for the local LAN should be sufficient.

Sigh, found it. find / -name syslogd /usr/sbin/syslogd

Most likely BIOS (or "Legacy" boot mode on newer computers)… I don't believe pfSense (or maybe even FreeBSD in general) uses UEFI yet.

Alienvault has now release a pfsense plugin. Check out https://github.com/decay/alienvault-pfsense

Alienvault has now release a pfsense plugin. Check out https://github.com/decay/alienvault-pfsense

Alienvault has now release a pfsense plugin. Check out https://github.com/decay/alienvault-pfsense

It would be best to run your du command when your drive is showing full or nearly full usage. You can then drill down through the directory showing the most use until you get to the directory where the space is being used up. Otherwise it's anyone's guess where your space is being eaten up. Squid might be the culprit, though if your Postfix settings aren't correct your firewall might be queuing large amounts of undelivered mail - possibly system warnings(?).

Multiple things at 192.168.1.1 causing something in the middle (switch) to get confused by different MAC addresses?  Reason for asking is 192.168.1.1 is a pretty common default IP for lots of home network stuff.