Note down the interfaces and their purposes exactly Dump the config Wipe the box Install ESXi Create the networking (vSwitches) Enable allow Promiscuous mode on the vSwitches that pfSense might need it Create a new VM (FreeBSD 64 bit) with the correct number of NICs (VMXNET3) Copy the pfSense ISO to the datastore Mount the ISO and boot off it Note the MAC addresses of the vNICs and which vSwitch they are connected to Install as usual At the console set at least the LAN address Connect your browser to it Restore the config Re-assign the interfaces Reboot Job done Cheers Jon

If you have a notebook available to be repurposed that can be a really inexpensive route (pun).  And as a bonus includes UPS and console.

Thanks for the direction! :) Bummer though its not compatible just for anyone else interested.

Yeah it was. Changed with 2.2.

That configuration is the opposite of ideal.  Also, how are you measuring latency?

Well I set my clients to 8.8.8.8 and 8.8.4.4 when I had them disabled, and I have no issue when I use the schools wifi. I used both resolver with forwarder (setting) and just the forwarder. Was upgrading from 2.2 to 2.2.1. Resolver settings: Default + I had enable DNSSEC, Forwarder, DHCP reg, Static DHCP. I have been using pfsense at my school for that last 2 and half years with no issue (did change hardware from a netbook after the first year), I have always had all the settings setup to handle double NATing, and I so get a reserved IP (10.X.X.X) and it comes from just a jack in the wall. Update: I disabled DNSSEC (even though google supports it) and the seems to help though it might have been mostly pasubio since I re-enabled it and nothing has really changed. After a few days the problem has seem to have mostly gone away. Something will take a little bit longer to load or some elements will still go through the can't find, then found cycle. It almost like the DNS cache was wiped and then it had trouble re-populating it.

You already posted this in the Cache/Proxy forum, and I asked you for your cache.log.

Ah, lol… I though you have 5 VMs on one box and are messing with (virtual) NICs in there or something. :D

Yeah - I think they are being hidden here >  http://files.nyi.pfsense.org/mirror/downloads/old/

I think your solution is common sense unless you are a dev trying to find an issue and fix in the pfsense release.

Hi, I think i am having the same issue. Any chance you have figured out what was happening?

I advise you to re-install pfSense.

@kwiksilver: If I post some logs/screenshots would that help? It looks like a similar issue with mine, as already stated: https://forum.pfsense.org/index.php?topic=90903.0 please perform further investigations (see again my post) and if the issue is close enough start to post there too so the experts have everything in one place.

Verifying free space on nanobsd would be utterly pointless. The entire slice is overwritten.

My point is that several people recently reported Bitten Fruit products to behave like nuts regarding DHCP. Notably when both wired and wireless was enabled on them. Traffic logs did not show anything unusual. ORLY? You consider renewing IP lease multiple times per second normal?  :o Find the offending device in the NDP table and unplug it. After than, you will probably need to delete the dhcpv6 leases file manually to get back to sane state.

Actually we had a need for those RFCs the last 2 weeks. A remote site in Gamgadi, Mugu was off-line for 2 weeks. The first week was town hydro power plant maintenance - no power all week and the Telecoms does not have enough solar, so no phones or internet. The second week was some internet "maintenance" thing. They had phones but no data services. It came back up yesterday. If pfSense at least implemented RFC 1149 then we could have used an RFC 1149 backup link to get some data throughput. And with RFC 2549 we could have even given Sykpe messaging priority. Maybe I should work on the code for it, if someone can do the hardware design of the necessary electronics<->pigeon adapters.