That's the exact same scenario that I'm seeing. Also I think it's unbound that is causing the load problem.

Not at this time, you could still keep the push lines if you want. Since the optimal buffer size could vary based on operating system and remote client location/circuit type/latency/etc I don't see pushing the same value to all clients as something we'd want to encourage.

alix nanobsd 32 bit, i just got a apu2c4 You could edit the XML backup file and change the vr(x) against the new Ethernet port names, that´s it!

@maverick_slo: Hope it's soon so I can ditch my old power hungry pc Looks like the scheduled release date is July 26th (https://www.freebsd.org/releases/11.1R/schedule.html), so it's probably going to be a while before a release version of pfsense supports generation 2.

I also have a working config. Using 10.3.1 and 10.3.2 beta.

@Jimp - I suspect something got bricked a couple of months back, after an upgrade I kept getting problems (an error message like PF was jammed). The only thing that seemed to fix it was a power off and restart. Anyway, after re-flashing it seems OK - as yet it seems stable. I'm not going to restore from a backup, as it's possible the config has something dodgy in it too. I'm slowly adding services again.

Updating to the current release did not fix the issue, but I then did as you instructed and reset the logs, and after that syslogd was working again.  So guessing it was log corruption, but that makes me wonder why, as the unit had not been powered down or reset out of the blue, so guessing this corruption happened as part of an update..

@Hugovsky: Are you using pfblocker with DNSBL? Not using DNSBL or pfblocker. Ended up disabling unbound and just pointed my DHCP clients directly at domain controllers with forwarders in their config. I was primarily looking for unbound to service a guest VLAN so that guests couldn't perform lookups on internal domains, but instead now I'm just sending them directly to ISP DNS.

Thank you for testing that! I finally found the problem, after redoing the vpn client it showed it binding to the carp ip and port, however on the vpn server side it still showed the WAN ip and random port. Turns out my manual outbound NAT was doing that…I had mistakenly used "This Firewall" instead of 127.0.0.0/8 on my outbound NAT for the firewall.

Tried all of the above suggestions and more with out success. Created a new VM on the same host (CentOS 6.9) using virt-manager and that worked. The not working VM definition had <os><type arch="x86_64" machine="rhel5.4.0">hvm</type></os> Changed this to <os><type arch="x86_64" machine="rhel6.6.0">hvm</type></os> based on the working VM using virsh edit and it now works. There was also a difference in the "feature policy" loaded (invtsc was missing), which I reloaded using virt-manager.

anyway, I can't explain how and why…. but there is no more trace of "strange" traffic in wan firewall log in the last 12h.

Unfortunately, OpenVPN doesn't show that in their status output yet. There is a feature request in to show it when possible. You can look in the logs to see what it selected, but that is not terribly convenient. https://community.openvpn.net/openvpn/ticket/814#comment:3 https://redmine.pfsense.org/issues/7077

Ah, yes, that's my bug! I haven't yet tested on anything but these computers with VLAN, so was assuming it had to do with VLAN. (my bad, DUH!) Thank you for pointing me in the direction of that report! I'll start participating on redmine now.  ;)

https://redmine.pfsense.org/issues/7500

at the end…. I see the light :-) This is my stable configuration (no more crashes in the last 48h) kern.ipc.nmbclusters="1000000" hw.igb.num_queues="0" hw.igb.rxd=4096 hw.igb.txd=4096 in  System/Advanced/Networking: "Hardware Large Receive Offloading" checked (others checkbox deselected) In this way I can reach almost 1Gbps bethween nics i340-t4 ports, seeing cpu load reach around 30% and no warnings/errors in log :-)

I run multiple instances.. One on tcp, one on udp and then one on ipv6 udp.. None of which had any issues.  I just now updated to 2.4.0-BETA (amd64) built on Wed Apr 26 17:54:39 CDT 2017 I show my tcp instance up and running ipv4 only.. [image: vpntcp.png] [image: vpntcp.png_thumb]

Watching it, it almost seemed like it was a race condition when the USB device was detected… it sat and waited (the Root mount waiting for: usbus0 line showed a couple of times), then as soon as the first line for the USB device appeared it continued before the USB device was fully ready for it to continue… so it makes a little sense that a delay would allow it to work. I wonder if it needs to be 10 seconds though, or if even half of that would be fine.

@Ragen: See image. had this happen to me as well, upgrade from 2.3.3_p1 to 2.4 via GUI is problematic for few i guess but had more trouble… On restore one of my packages broke libssl too. ended up re-installing & restoring from modifying config to exclude a few & it works now.

Well I guess I could always take a snapshot and install the portable freebsd 7.5 version and see if it breaks anything.  But not a fan of jumping ahead in what pfsense installs.. This could have unseen consequences, etc. As I said not seeing any issues connecting from a 7.5 client - but curious on why so far back.  if on 7.4 would make more sense, etc.  But 7.2 is getting to get a bit long in the tooth.

I'll give 6.5.0a a try this weekend. Thanks!