Thank you very much Sir !!! I now have access to the Gui and an internet connection. Onwards and upwards to the next hurdle.

Found the issue should anyone else find this in the future. Our IPV4 was set with the BIT value instead of the CIDR. Really, I'm surprised anything worked but I'll take it.

@jpns: Welcome to pfSense 2.3.4-RELEASE on the 'nanobsd' platform… rm: /usr/local/etc/ipsec.d: Read-only file system rm: /usr/local/etc/ipsec.conf: Read-only file system rm: /usr/local/etc/strongswan.conf: Read-only file system /usr/local/libexec/pfSense-upgrade: cannot create /usr/local/etc/pkg.conf: Read-only file system /usr/local/libexec/pfSense-upgrade: cannot create /usr/local/etc/pkg.conf: Read-only file system Is a reinstall the only way to fix? Reinstall is one way. There is a chance that booting to single user mode and running "fsck -y /" a few times until the scan finds no errors may help. Though if your system is capable of running a full installation, it would be a perfect time to reinstall and migrate away from NanoBSD.

I wonder if an A0 image can be made available? According to the marketplace, the A0 images have a free licence, so there's no tax to collect for AU customers.

On the server side you could use one of the SG1000's as only a openvpn server.. Client(1) > – switch -- > wanrouter(3) > internet  > wanrouter(4) > -- switch -- > SQLserver(6)                 ^                                                        ^                 |                                                        |               sg1000(2)                                                sg1000(5) So client could still use its wanrouter as the default gateway. And the client(1) or the wanrouter(3) could then configure a extra route to the sg1000(2) when it wants to connect to the sql-server.. Then the sg1000(5) could be using outbound-natting to translate traffic from its vpn-clients to its own ip and the company network would need no changes at all.. But sql-server and other logfiles would show all clients connecting with sourceip of the sg1000(5). Or instead of using outbound-net the wanrouter(4) or SQLserver(6) would need a route for the lan-network of client(1) to point to sg1000(5).. Or you could install regular openvpn clients on the client pc's, (use openvpn export package from pfSense to create its config and possibly a Windows installer.) And not use the sg1000(2) at all.. It all depends on what you want want/need ;). usually pfSense becomes the edge router of the network, but if you want to push decent bandwidth, and also run VPN's over them the sg1000's might not have the processing power (ive never seen one in action.)..  Also maybe a 128 bit cipher might offer better performance over the vpn.. but provides a little less security i guess.. Also is the VPN going to push 2Mbps over a 10MBps internet line in which case i 'think' the sg1000 should be able, or do you want to use 100Mbit internet while also using 50Mbit of VPN traffic or bigger numbers in which case it might not..? But again ive got no numbers to back these thoughts up.. Its just the feeling from what i read/remember of comments made around the forum about these devices.

A CD that would offer this : @k.p.k.gupta@gmail.com: ….always up-to-date list of packages …. ;D

What do you need to do?

It depends what you're using Snort for. If you use it to collect data on traffic and aggregate that somewhere centrally you might not need to block that. Most people would have it in blocking mode though. Once you have the ruleset tuned you should not see many false positives. I usually recommend you run it in non-blocking mode for a week or so and review the logs. Whitelist or disable the rule on anything that shouldn't be alerting. Then go to blocking mode. You can also set the block time to something low enough that it will restore in a reasonable time. Steve

The updates are delivered via pkg, so they have to show as being available that way. pfSense-upgrade does some extra things that make sure it all goes smoothly. You could, in theory, update most if not all things via pkg, but it's not ideal to do it that way since the kernel package will be locked (which pkg tells you if you run it directly), and you could potentially have some weirdness with having a mismatched kernel and base. For a minor update like 2.3.4 to 2.3.4-p1 it wouldn't cause you much if any harm to do it via pkg, but we still recommend using pfSense-upgrade. And yes, pkg is the standard for FreeBSD but, though the pfSense distribution is based on FreeBSD, it is not FreeBSD, so expectations must be adjusted accordingly.

You want this one: https://nyifiles.pfsense.org/mirror/downloads/pfSense-CE-memstick-ADI-2.3.4-RELEASE-amd64.img.gz 4GB is not that large but it will do fine with a default install as long as you don't go nuts with packages, caching, and logs (including package logs). If the 4860 is still serving your needs it takes an mSATA. You might consider investing $60 in one and having 120GB SATA storage instead…. https://www.amazon.com/dp/B00CG8GTPO/

When DNS fails like that it's usually because the clients are using one of the DNS servers on pfSense and that is not configured to use both WANs. By default pfSense runs Unbound in resolving mode. In that configuration Unbound itself always uses the default route so if that was the Comcast link in this case it would have failed and no clients using it could resolve IPs. To avoid that either use forwarding mode in Unbound or switch to the DNS forwarder and make sure you have upstream DNS servers defined against both WANs in System > General. Or alternatively enable default gateway switching in System > Advanced > Misc. Using DNS forwarding is usually preferable to avoid traffic on the wrong WAN after a failover. Steve

Sounds similar to what I was seeing after 2.3.4_1 when browsing the Suricata menus everything is working I submitted my crash reports

@johnpoz: yes every network has a broadcast IP 192.168.0/24 would be 192.168.0.255, but what MAC address do you think that goes too?? See attached is a broadcast to the network broadcast address .255 - look at the MAC.. That is a directed broadcast, but dhcp would be a full broadcast to 0.0.0.0 same all F's mac.. How exactly are you going to run 2 dhcps on the same wire on pfsense??  So even if you deny all on one, and reversed the deny on the other so your devices could only get their reservations.  Pfsense will not let you run them in such a borked configuration.. If you want to do the borked config vs doing it correctly, then you would have to setup static IPs for everything.. Or run the second dhcp on something else other than pfsense and then limit what the dhcp servers will hand out IPs for.. If your going to go to all of that trouble - prob just be easier to setup static IPs on the devices themselves, etc. Good luck! Yes exactly that's what I wrote more or less as well. :) So not really worth doing right now but will have to do some thinking on what I should do. Thanks for your help.

Are you able to post screenshots of the issue you were having? The easiest thing there is just to reboot the install though. 2.4 now uses the FreeBSD installer so things are different there. You may want to try that to see if whatever issue you hit is still present. Steve

ive logged a bug on this issue:  https://redmine.pfsense.org/issues/7730

The only section of the config that should ever be restored individually in the versions are different is system. That's the only section that contains the version information required to run to appropriate update scripts. Can we see the console log showing the exact point it stops booting? The most common reason for that is some console setting in the restored config changing the output such as serial speed or serial/video console. Steve

I'm running pfsense 2.3.4 on ESXi 6.5. I'm using VM version 13, Open-VM-Tools package 10.1.0,1 and VMXNET 3 NICs. All that is working well for me.