Messages

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?

Did anyone succeed with booting 19.1 on a Dell Poweredge R410?
I am reluctant to upgrade not knowing that it will work on my hardware.

A question in that context: is there a way to make a full backup of all files, before an upgrade attempt, and go back in case the upgrade fails?

I assume just booting an older kernel might not work, as a lot of system files, besides the kernel, will have been replace by the upgrade, and they may no longer work with the older kernel.

I am rather new to Opnsense.
From my general experience with operating systems over more than 40 years, I have learned that it is wise not to update immediately when a new release is offered, like now with Opnsense 18.7.9.

In this context I wonder:
If one does an early update to a new release and finds a new problem, can one revert to the previous version?

The solution was provided by the (paid) support of Opnsense/Deciso, and is simple:

for routing the subnet 10.1.2.0/24 and the desired extra WAN IP of 10.1.2.254 on the OPNsense firewall, you only need to add a virtual IP, like this: