Just affirming phil's instructions that you can edit the interface names fairly easily in the .xml config file; I just did my last soekris->sg-xxx upgrade and this time instead of going the console method I just saved (backup) the prior configuration, edited the xml file to change the <if>blah</if> entries as appropriate, then restored from that modified configuration onto the new hardware. Worked fine. I would resist the temptation to change anything else that you don't need to change "while you are there". I started to reorganize my choice of opt1 vs opt2 etc and quickly realized that had many other implications (e.g., rules); so of course I reverted all that and started over with discipline to just update for the emX -> igbX changes. Which method (console vs edit the xml file) you prefer seems to be a matter of preference; both are pretty simple.

There has been a lot of discussion about this but I don't see any advantage in using PCI passthrough. VMware have their view of course and you can take that whatever way you want  ;)

One word of wisdom:  Make sure both devices are on the same patch level. I did not heed this wisdom and found out the hard way how difficult it was to re-import the settings.  I don't remember which versions I did this with, but it was a few in between. I recently did a pfSense hardware migration following the above advice, and it went flawlessly.  In my case the interfaces lined up perfectly.

Hi johnpoz, probs approaching 500 all in but its a great build. slightly on the noisy side as most 1U's are but loaded it up with lots of heavy traffic, and its basically still at idle, which is fantastic! In the end i did wipe the hardware raid and go with the pfsense mirror, worked first time, very impressed. Will be putting it live tonight so will keep you all updated, all settings are in place just waiting for the network to quieten down so i can make the switch, hope it goes nice and smoothly.

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/