Tha worked for me and has fixed the issue, Thanks.

Thanks Jim! Every thing is working as expected now.

If the upstream device is handing out an address in 192.168.1.*/24 then that will conflict. Well. I'm stupid. Thanks for that; moved it to my testing VLAN and it now hands out 192.168.x.x with out issue.

Not on a business package here, but the superhubs should have a modem mode option in the GUI* Unless there is a difference between business and home user versions of the superhub, it should be there. both the original superhub v1, and our recent v3* had/have this **I am very glad for this, the hardware is nice but it's software is utter garbage (hard-coded LAN 192.168.0.x IP range and broken port forwarding)

Hello 2 all. Really its a magic… For a few days after this trouble, i download the same image and make clean install again... All working fine without any errors. I am stuck. But problem is solved.

Define problem please. Error? Specific issue? Computer slapping your hand when trying to boot it? pfSense is actually easy to put in ESXi. Make sure the 2 cards are recognized in ESXi (Configuration-Networking, Configuration-Network Adapters). Add each as an E1000 type ethernet card. One card connected to the Internet, the other to your local LAN switch. Once installed and connected, install the Open-VM-Tools package.

wow - i post this and like magic it starts working :) haha love it! Thanks for the magic fix forum!

Where is the source for /usr/sbin/gnid? Can't seem to find much about it.

Thanks!

You could try PXE booting mfsbsd and then fetch pfSense. Maybe I'll try and set it up out of curiosity…

Actually you can PXEboot mfsbsd. Once booted, you can fetch pfSense over the network and try and install it.

That's what I thought… Well, I guess it also depends on the packages installed. I was running Squid, but am quite sure I had offloaded the writes to a traditional HD that was also installed in the same server. All logs were going to a syslog server on the network. That's why I was puzzled when the firewall started failing recently. The Nanobsd install has been running flawlessly for a week now so it definitely was an HD problem. Also, that SuperMicro SATA-DOM I'm using is only 16GB, so I have less room for errors, and that's why I want to make sure I don't lessen IT'S life. When it fails, I'm going back to a quality SSD drive and will simply use the RAM disk just to be safe. Thanks all. Good to know for the future.

thanks  ::)

So you restored a config from when you had packages installed? Squid can behave oddly when installed and not configured on occasion. Check the system log to see if it's continually restarting. Steve

PfSense doesn't have man(1) and the related utilities but the packages still want to run the indexing tools on install. It's a bit broken but we have to do with what the FreeBSD ports offers.

At least I am not alone in the world. Another nanoBSD with the same "stuck on p16": https://forum.pfsense.org/index.php?topic=129994.msg716584#msg716584

I ended up just re-installing 2.3.3-p1 on it and will test more tonight. Thank you for the suggestion.

Reinstalling the package seems to have fixed it.