I did what was recommended. Removed the raid in bios and did a gmirror in the installer. Working a treat, thanks chaps! My Modem arrived earlier so I've got all the settings in place for the swap over later this evening, hoping it will go smoothly. Will let you know :D

Enabled the CPU tempreture built in widget and its showing theres no values? any ideas? It isn't connected up to the wan yet so not sure if its gonna pull some files down once its connected along with some updates? (i hope its as easy as that)

@mrrodge:

I tried to boot again and again, using the FreeBSD options for other kernels, none of which worked.  Starting to panic that it was the SSD failing, I downloaded the USB installer and used the option 'Rescue Config.xml', which said it succeeded, BUT, where the hell does it rescue the xml to?!  I tried booting a live CD for GhostBSD and mounted the USB, the Config file isn't there.

The "Rescue config.xml" option reads the configuration from the drive into memory, and then copies it back to the target drive when installing. To use it when swapping in a new disk, you'd have to have the old disk and new disk both connected, then pick the old disk to rescue from and choose the new disk when installing. If it worked, the new drive would have the configuration in the proper place after the installation finishes and it would come back up properly afterward.

The down side is that on 2.3.x and before, that option was not very robust. You'd have to try it 2-3x or more before it would work, if it worked at all. I've rewritten how it works in the new 2.4 installer and it now works every time I've tried it. That said, if the old drive really is dead, it still couldn't help.

Thanks, I will try.

@heper:

https://doc.pfsense.org/index.php/Upgrade_Guide#pfSense_2.3_Upgrade_Guide

read that very carefully. lots of stuff has changed from 2.2.x –> 2.3.x

Thank you.

I have already read that and was looking for user input in their experience.

It isn't a supported upgrade path.

If you have a 64-bit system, you will want to reinstall with a full installation anyhow. 2.4 doesn't support NanoBSD, and requires 64-bit. So you need to get to a full install and away from NanoBSD while also switching to a 64-bit install.

Currently that can only be done via a wipe+reinstall.

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.