Messages

Now I upgrade from 24.7.12 to 25.1 as the dashboad suggested.

Again, it only begins installing or reinstalling 197 packages after the second reboot, in a stage when network interfaces are down.

I can only see what happens via the console.
The hardware is a Dell Poweredge R440.

I expect another service interruption of two hours or more.

Luckily I am inside the firewall and can watch the console. I would despair if I were outside and could not get in during hours, while not seeing what was happening.

I cannot login while it is in that intermediate state during an upgrade. Network interfaces were down
But now it has rebooted, and is on 24.7.1

It is now updating from 24.7.1 to 24.7.12
NOW the extracting of the new packages is again slow, but it happens before any reboot, so that
the firewall is not inactive during this time.

This is as it should be, but was not in the previous upgrade.

I am upgrading opnsense 24.1.18 to 24.7
I arrived after one or two reboots at a stage when it is upgrading packages.
For many of the 169 packages the Extracting step is extremely slow.
I never observed this before.
I am now at it over one hour and it is at step 68/169

Can I interrupt and somehow reboot to the previous version?

No users can connect while the firewall is down

I set up another opnsense firewall, this time as bridge.
Can I copy the existing firewall rules to the new machine?
I do NOT want to copy the complete configuration.

I found the reason myself.
I had another, more general rule allowing incoming ntp packets. That rule took priority over the blocking rule.

I have had a recent problem when one of our servers was incorrectly configured for ntp, and then was abused for
NTP Amplification DDoS Attack.
Because it gets ntp broadcasts from the Lan, it does not need to receive ntp packets from the Internet.

I have created a firewall rule, which on the WAN side blocks all incoming ntp packets to this server's IP, udp port 123.

But when I use tcpdump on the server to see incoming udp packets port 123, I still see massive amounts of them.
It seem that the firewall rule does not work.

What could be going on here?

Updated from 19.1 to 19.1.7 without problem.
Hardware is Dell R410

I am happy to announce that I upgraded without problem from 18.7.10 to 19.1.1 through the normal upgrade process
on my Dell Poweredge R410 system.

I had feared upgrade problems due to report from others with similar Dell machines, but everything went fine.

...assign new interfaces (via vga or serial console) on reboot after restoring the config.xml backup, if the interfaces differ between the two installs. ;-)

Is it like this?

On the new machine I get  only default configuration.

I have to assign the interfaces and IPs to them. Now I have network connection.

Then I can reload my previous 18.7 config file from the system where it is backed up (not from Google, because I will not have opened the WAN connection yet).

Now I get the wrong interface names from the backup which was from different hardware. Network connection will be lost.

I have to edit the interface names, and will have network connection again and all the other firewall etc. configuration details.

@Aloist

Maybe if it is such an ultra critical device for you you should invest in a CARP cluster; possibly with the Dell as slave for the new device for example.

It is only the office firewall. But I work a lot outside of the office.

I like to trust that if I do a software update in a device in the office, it reboots and after a few minutes it will be up again.

If the system software update is so bad that at a reboot it ends up in a kernel panic, it comes never up again. I would have to be physically there, and reinstall from cold. This is what I fear, not a hardware failure.

We use RAID disks on all essential systems, because disk failure is the most frequent hardware failure. Typically after several years of 7/24 use. All else, i.e. power supply, RAM, CPU fails much more rarely, in my 40+ years IT experience.

I am going to have a new firewall device running Opnsense 19.1

My current firewall runs 18.7 on different hardware. I do not dare to upgrade as I fear kernel panic after upgrade.
(has been discussed in a different thread).

How can I transfer the Opnsense configuration from the old hardware to the new hardware?

I have a spare R410 lying around. The RAM in it is dead. If you can hold out until I can buy new RAM (within a week or so), I'd be happy to test out on my (currently dead) R410.

That is kind of you, thank you.
But as I have now ordered the appliance from Deciso, I will move from the Dell R410 (we have a lot of older Dell Poweredges) to the supported hardware.

I would not be able to rely on your test, because originally, when I first installed Opnsense 18.7 on the R410, kernel crashes also happened, most likely due to Raid controller issues. I documented what I did to fix this:

Code Select Expand

Have trouble installing opensense on w99, it crashes, most likely due
to driver issues for the Dell PERC
I can catch the USB boot process and enter menu option 3, to set boot
parameters.
There, I add
set hw.mfi.mrsas_enabled=1
and boot.

It may work. Afterwards, I must login as installer, pw= opnsense

It worked. After reboot, I can enter shell and see with
dmesg|more
that the Megaraid SAS driver is active.
With command
mfiutil show config
I can see then the raid configuration is properly recognized.


It is a pity to give up the R410, as it has completely new disks and would have run for many years to come. Still, I have other work to do and cannot spend time with unstable support situations for an essential piece of hardware.

The Deciso hardware has no RAID and no dual power supply, is therefore inferior on that side.

I may keep the R410 as a backup. Once it is no longer a critical component, I can afford to risk version upgrades on it.

I have given up, as it is not possible to get support for upgrading Opnsense on the Dell Poweredge R410 which I am running.

I have a paid support subscription, but only got this answer:
"We do not have a Dell R410 to test. We have tested it on the hardware we sell and on these the upgrade works well. "

I do not consider this professional support and had actually expected better, when I decided to move from Cisco to Opnsense.

Now I have bitten into the bitter apple and ordered "hardware Deciso sells" to run Opnsense on it, as this seems to be the only safe way of have a system which can be kept up-to-date.

You can always boot 19.1 from a stick in live mode and test things out without changing anything on the box.

If things look good you can even do a new install importing the config in the process.

How do I get my current configuration onto this boot stick?

And what if the boot problems of the new FreeBSD release are related to the Raid controller or Raid configuration in the Dell hardware? That will not become apparent by booting from a stick, when the disks are not involved.

Since the update to 18.7.10, Insight shows 'no data available'.
What happened?

How do I get the data display back?