@jimp:

@Music:

yes that works fine i also did that. But i have a few custom files for my DNS resolver. So when reinstall and then do the config i still need to copy certain files to the correct directory otherwise Unbound etc will not start.

Then you can utilize the "Backup" package to easily get an archive of those files to restore later.

Also if you put use a glob to specify your files in the advanced options of the resolver (e.g. "custom*.conf") then unbound won't fail if it can't find the files.

Or you could get even trickier and use the System Patches package to store them in config.xml create them for you, but that's not quite so easy to maintain.

ok thank you will look into that

Thanks!

If either one of your WANs is PPP, then default gateway switching can fail in this way. It's a known issue we've tried fixes for over the years but always ended up backing them out because something else failed.

You must have a default gateway, however. It's possible that in the past the PPP gateway was becoming default even when it wasn't set to be.

Ooops, I found the problem…. I have used the wrong VM. I had updated my Pfsense to x64, but misnamed the VM... :(

Now uing the correct x64 vm and the update worked.

Thnx for the tips!

Finally it was a good opportunity to move pfSense on VMware and of course it worked just fine while I have now one more NUC for my cluster. Moving next: clone it and use CARP for redundancy.  :)

I enabled power daemon and set it between all the modes, the fan slows down a little depending on the selected mode, but usage remains the same for the acpi task. I updated the bios to see if it made a difference as well, but no change. I’ve chalked it up to something with acpi and this version of the kernel in FreeBSD that’s beyond my ability to figure out and rolled back to 2.3.4.

Thanks for the suggestion.

Just wanted to finalize this thread and say that this worked perfect even without manual editing of the file. I'm amazed at just how easy it is to work pfSense especially going from different devices and even different versions.

The only, ONLY issue I had was that I had to change the temperature probe setting from AMD to Intel.

Thanks again,
Adam

The file doesn't necessarily have to exist by default. In some cases it's unnecessary so it's empty. Just create a new file /boot/loader.conf.local and put your custom settings there if you need them.

Ugh, total fail on my part for lack of being thorough. Thanks, working as expected…

Fast PiBa!! Thank You!

I disabled the Host recources under snmp modules -> this does the trick!

Thank you very much!


@ptt:

Maybe a browser cache related issue,(clear / ctrl+F5 )

First thing I tried, didn't help. However I just did a "refresh FireFox" and that did the trick. Thanks.

That's weird!
I'm using pppoe on 2.4 (sg-1000) - so it's not an upgrade from 2.3.x
But it works fine for me.
Have you tried deleting and re-creating the pppoe config?

http://files.atx.pfsense.org/mirror/downloads/old/

@remzej:

Ok I just found the cause of this problem. Official upgrade cannot be done if we had installed unofficial repos like WPAD. To be able to update simple edit the unofficial.conf file located in /usr/local/etc/pkg/repos/

Change these code:

FreeBSD: { enabled: no } Unofficial: { url: "pkg+https://github.com/marcelloc/Unofficial-pfSense-packages/raw/master/repo",     mirror_type: "srv",     enabled: yes}

to these code:

FreeBSD: { enabled: no } Unofficial: { url: "pkg+https://github.com/marcelloc/Unofficial-pfSense-packages/raw/master/repo",     mirror_type: "srv",     enabled: no}

By disabling the unofficial repo the system update will work.

AHH!  That's it - WPAD. I remember I had to kludge something via an "unofficial" repo but I couldn't remember exactly what it was.  thanks for the info - this helps a bunch.

So how does traffic shaping work for ipv6 traffic then? its practically bridge, right?

Don't know how to use limiters when there are some bridge users that need as much bandwidth as possible per 24h but at the same time I need to give multiple NAT users proper bandwidth when they are occasionally using internet. traffic shaper has been working excellent for us giving everyone their fare share. I really don't like bridge myself at all but some users just need that. period.

Anyway, this obviously needs a complete new approach and lot of testing and developing before we can introduce 2.4 to our sites. very frustrating.
so for the time being have to get back to previous releases. Is there any place where to download previous releases?
I only found 2.4.0 release and up from download site.

@mlsbraves:

I have a LAB environment and several boxes of models we use at productions sites. Generally, before I push an upgrade to a production site I test each of these units here to make sure I don't see any issues. Would it be a good idea to also install an old copy of pfsense (eg. 2.1, 2.2) and then preform the upgrade to current to see if  any obsolete setting cause issues in the future?

You can't go straight from 2.2 to 2.4, you have to stop at 2.3 in between. So you can do that if you want, but at the moment we're only testing 2.3 to 2.4.

Today I reinstalled 2.4 used a backup config. Problem still there. Then I reinstalled 2.3 again with the same backup config and everything is working again. So for me no 2.4 yet.

Hi there,

For quick full pfsense backups and recoveries this is what we do with our telecommuters. It works quite well. Hopefully the idea can also benefit you.

First, make sure that your router hardware can boot from an external USB hard disk drive in "legacy BIOS boot" mode. If for some reason the BIOS doesn't allow it scrap the idea. Also if you do not have 3 USB ports on your pfsense hardware, make sure that you have an external powered USB hub with 3 ports.

Then, get/make yourself a bootable USB flash-drive with some flavor of Linux on it that you are comfortable with.
For instance, it could be a live Linux Mint 18.2 disk, or BootRepair live disk, or still bitdefender live disk.
Whatever you pick ensure that it is GUI based. Something that's capable of booting up your router hardware and allow you to run a terminal window and a utility like dd, or dcfldd or yet dc3dd (these are all raw disk copy tools for command line use).

Next, get yourself a couple of identical, top quality Flash disks no larger than 16GB, (or a couple of small size SATA SSDs that you get from AliExpress for cheap and convert to external USB drives by using cheap enclosures).

Regardless what kind, ensure that the drives are not larger than 16 (or at most 32) GB. The reason for size limit is that, as a matter of routine backup you will be performing an image copy of the entire disk drive, and the larger the drive the longer the copy time will be.
A nanoBSD based pfsense system is a lightweight system and it fits on a few gigabytes at most. So, my assumption is that 8, 16 or 32GB will be more than enough for your situation. But on the other hand larger USB flash drives are faster than smaller ones, so that's why 16GB is probably the perfect size/performance point.

Now, install pfsense 2.4 on one of the USB flash disks (no ZFS, no UEFI, just basic ufs in legacy bios boot mode). Configure it and use it as if you are in normal operational mode.

At your intended, periodic backup time, simply shut down pfsense, plug in your Linux USB flash disk mentioned at the beginning, get a terminal session going and run a dcfldd copy of the entire pfsense flash disk onto your backup flashdisk of identical physical size. Typically this would take a few minutes.

So, basically you will be running pfsense off an external USB flash drive and when you decide to run a backup, you go into linux mode and copy one flash drive onto the other in raw copy mode. This will result in absolutely identical, physically separate pfsense disks that you can swap as needed.

Performance wise the USB flash disks won't be worse than any nanoBSD solution, but obviously you won't be able to run "heavy" stuff like squid cache etc. But I gathered that that's not what you're looking for based on the fact that your starting point is nanoBSD.

The beauty about this solution is that if you need to restore, you simply switch to the other flashdrive, there is no need to copy anything.
Again, this is something that we have been doing with many telecommuters (50+) at large with different levels of technical knowledge and all kinds of pfsense hardware, and the cornerstone of our logic has been that regardless how expensive the hardware, the firewall/gateway would eventually fail, so quick recovery, high level of safety and painless but guaranteed backup were all necessary.

So hopefully this will also help you. Good luck.