Run the minimum amount of TCP traffic necessary to replicate issues and packet capture it. Should see on one LAN or the other repeated retransmissions of large packets if it's an issue along those lines. With mssfix down to 1200 not having made a difference, I suspect that isn't the problem. Capture likely has clues as to what it is. Try various ping sizes with DF set and see at what size traffic starts getting dropped.

I realize that it does work, but many people don't know (nor should they have to in my opinion) how to install packages that aren't in the package repository - that is kind of what it is for… So end users know it has been tested, works, and is authentic. I'm not personally against unofficial packages though, and agree that is better than using pfBlocker (non-NG) in 2.2.

The BIOS for such an old board (remember it's a core 2 duo system) is as up to date as it's going to get. I had seen the unknown power management option, and now all are set the same, to adaptive. It seems to run at about the same temperature, or maybe even slightly cooler.  So maybe the displayed current CPU speed is calculated differently, between FreeBSD 8 & 10.  I assume there is lots of scope for such a minor change to have been made.

yes I did thanks for the correction.

Apparently the yacc parsing got more strict in pf. It used to accept those  (but we denied them). It was also the source of problem with some of the traffic shaping problems with DSCP and tag matching/setting. The latter of which have been fixed for 2.2.1. Numeric aliases and interface names are definitely not allowed though, it's lucky they ever worked.

@stephenw10: Ah, I missed you Doktor. Forum wasn't the same without you.  ;D Ditto, ol' Doktornotor cracks me up.  ;D

@cmb: @bradenmcg: I would love to see something analogous to Cisco's "VTI" and Juniper's "ST" interfaces for VPN; most major firewall vendors have something similar to this, even "weird" stuff like Palo Alto support this (and PA doesn't do IPsec+GRE so I have no other way to replicate it against pfSense). I would like to see that. It'd require a good deal of work, as there are missing pieces in underlying bits. Not on the near future road map at least. That's what I've been reading, apparently neither BSD or Linux have the correct tunnel interface existing on the OS, making this more complicated.  That said, Ubiquiti has VTI in their gear, so it can't be too bad to do… I believe they are some form of *nix underneath, wonder if the source for this is open? I may have to grab an EdgeRouter and stick it behind my pfSense box just for VPN purposes.  (I'm not likely to ever ditch pfSense at the edge, unless someone else starts supporting UPnP/NAT-PMP, since I have game systems.)

What type of hardware is this? If you're more comfortable communicating in French (I see your IP is in France at least, making assumption from there), you might try the French board. https://forum.pfsense.org/index.php?board=7.0

I got some Trim help here if you decide to do a fresh install: https://forum.pfsense.org/index.php?topic=66622.0

Hello, It looks like the suggested fix by cmb works.  ;) Thanks again. Best regards, Ivo

Yes,  pfSense-2.2-RELEASE-4g-i386-nanobsd .img and 2.1.5-RELEASE-pfSense-4g-i386-nanobsd.img

Thanks for making squidguard-squid3-1.4_7-amd64.pbi available, with sum  ;) Just upgraded pfSense again, after some testing everything seems to work as planned. Thanks, qinohe

@WONDER: After one or hours automatically service started. Probably freshman first run…

+1 for this

Same here on a Alix2d13 afer update to 2.2 Also VDSL with VLAN 7 Disable IPSEC stops the crashes. Any new information here?

I didn't understand this magic. If I add 192.168.2.1 as VIP and delete the same VIP then I can ping my pfsense IP 192.168.1.11 from VLAN 2 i.e 192.168.2.x same way for all VLANs. But if I restart pfsense it is not pinging, again I have to add VIP and delete the same VIP. Any idea?

Check out the bug report in https://redmine.pfsense.org/issues/3669 Note that there are 2 parts to the restarting fix: First part relates to IPv4 script /etc/rc.newwanip - this fix is rolled into 2.1.4 and later. Second part relates to IPv6 script /etc/rc.newwanipv6 - appears to be awaiting review (despite ticket being marked Resolved). Also impacts 2.2 release In the meantime it is easy to manually apply the fix and stop the restarts.

https://doc.pfsense.org/index.php/Dig_command_on_pfSense_2.2_and_later has existed for a while, just sayin'. :-)

Wow, bad cable or bad adapter? Were you using 115,200bps for both? Good catch I would have rules that out.  ;) Odd that 2.2RC worked and 2.2-rel didn't.  :-\ Steve