I could half way solve the problem with adding a device without any configuration as l2tp0 and connect one side B and configure the GRE tunnel on that device. If I now could somehow either configure the GRE tunnel to use just other end of the ptp or have each site B using the same l2tp device this would be solved but I think it is not. I wonder if it would be possible to run a custom script on l2tp interface up that sets the GRE endpoint to ptp end?

I have read in the forum saying that 32-bit system can recognize up to 4G of RAM. Perhaps a fresh and full install will do the job. The reason I chose to use this particular build is that this is the build that has the best openvpn performance as compared to the latest 64-bit build. This could be, but it is based on FreeBSD 8.3 and the newer versions will be based on FreeBSD 10.1 so it would be not the best option to use an older version, pending on the other failures and problems that will be gone away with FreeBSD 10.1. For now, I would like to run 2.1.5 32-bit. Not for ever trust me please, earlier or later pfSense will be only available as a 64Bit system and then you should change to the newer version.

"And also would be nice if those automatically added rules showed up in the Firewall Rules display (read-only) so they are easily seen" Agree, this has been a long standing request has it not? Could make it a toggle that has to be enabled in advanced setting or something, since it more than likely would confuse some users.  Or guess they can show it like they show the anti lockout rule..  But fully agree, would be nice to see all the rules in the gui firewall tabs vs https://doc.pfsense.org/index.php/How_can_I_see_the_full_PF_ruleset

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