Problem is, its not with the freebsd/pfsense side of things. an IMG file is recognized by just about all other vm system except hyperV apparently. I hated it when they were demoing and starting core development back when it was still virtual pc and they used it for the xp backporting on windows 7. I have had zero issues with any bin, img, or iso file on VMware vCenter/workstation.

JimP, I am sorry I didn't get to it earlier, but I was out of town. I just upgraded this morning and everything is working correctly as it should. Thanks for getting this fixed.

Limiters seem to be fixed in the latest version, thank you.

same problem on 2.4.2_1

Fixed in the next snapshot (1.16.11)

I am, for the first time, seeing 502 Bad Gateway. Upgraded today to the latest snapshot on my SG-3100.
I do still have internet service so I will wait a bit until someone says they have an idea.

Restarted via console, loaded very latest snapshot and now waiting to see if the issue pops up again.

As of 8PM, its an issue again. I guess I need to revert to a previous release and wait a bit for the snapshots.

Definitely up for that once I get my box stable again… it is being naughty at the moment.

7.x switches from interpreter to JIT compilation like HHVM, which could be useful.

2.4.3 is a release version of pfSense. If you're having problems with OpenVPN, you might want to post in the appropriate forum for that. This forum is for reporting issues with pre-release snapshots of pfSense, currently at version 2.4.4.

https://github.com/pfsense/FreeBSD-src/commit/6fd5da7f06d3412cef113820f484da4551ee8ab7

I guess that would make sense. The simplest implementation of TLS would be to just create a new connection per request. Connection pooling adds a fair bit of complexity. If using an HTTPS library, you get that for free.

@maverick_slo:

I think this could be resolved simply with setting unbound to start a little later…

The term is "race condition". If it's what you think it is, which is also what I was thinking, it's not an issue of making it start arbitrarily later, but it should start after the interface is ready. The kludge of starting later may work in an arbitrary test case, but there will always be another case where the interface still isn't ready and Unbound will start too soon.

But I do agree with you from a practical aspect. I was not being critical of your answer, just making sure you had the vocabulary and clarifying the fundamental issue in case it wasn't completely concrete. Having the correct vocabulary not only helps with communication, but it helps with thinking. The brain actually uses the same structures for words to encode memory and thought. Thoughts are very much limited by our words.

@BearTM:

The important detail for you is exactly what I added in the NOTE at the end:

"NOTE: I am also using QEMU/KVM PCI passthrough running on a Ubuntu host, dedicated server - Gigabyte GA-H170N-WIFI motherboard."

Since pfSense needs to directly control the hardware, this method will only work as a bare-metal or PCI Passthrough to the VM.

Because you bridged your adapter to the host, there is no WiFi card for pfSense to access in hardware.

Remove the WiFi card from your host (blacklist), add it as a PCI Passthrough to the VM in QEMU, and then it will work.

I tried once again to add it as a PCI Passthrough and I found out that my adapter is not 8260, it is 8265 :(
They already merged the kernel module into the version 12 of freebsd, but not for version 11.
So I guess I will have to wait until I can make this work

Not related. NRPE needs work on 2.4.4, the NRPE2 ports were removed from FreeBSD, so it needs some slight adjustments for nrpe3, mostly changing some filename/path references from nrpe2 to nrpe3

my config.xml file had <dns5gw>NORDVPN_DHCP</dns5gw>
despite having no DNS entries in System/Advanced

changed it to <dns5gw>none</dns5gw> and problem solved!

I would like to thank the source code for helping me narrow down the problem.

https://forum.pfsense.org/index.php?topic=145902.msg793316#msg793316

@th112211:

It's working very good

It really, really wasn't. In very small sample sizes you may not have encountered many problems, but overall it had significant issues inherent to the platform. There was no way to properly fix it, and the hardware that originally needed NanoBSD has been EOL for a long time.

There are more detailed answers to this question on the blog, in various release notes, here on the forum, and elsewhere. It was a decision made years ago, there was plenty of forewarning.

The issue has been fixed server-side. Sorry for the annoyance.

So I ran into this problem aswell.. I caused it by changing my bios date/time, and  I fixed it by deleting the rrd data files, then restoring that "area" from a backup that I did a few minutes before (i did an update from 2.4 -> 2.4.2)

boom fixed..

thought it should be documented.

James