Messages

Hi,

I ran into this problem quite a lot already, particularly when running opnsense as a VM and when changing underlying virtualized interfaces which is well why you run it virtualized ;)

For explanation let's assume I have 4 interfaces, 1 passthrough physical, 3 virtual ones (vtnet0-2).
Now we remove vtnet1:

How opnsense behaves today:
- opnsense forgets all interface assignments and starts randomly assigning interfaces similar like when on initial setup
--> In many cases you end up with a totally unusable opnsense installation unless you boot into console and start manual interface assignment again

How opnsense should imho behave:
- vtnet1 is removed assigned settings are deactivated (or removed best if it's asked somewhere) the remaining interfaces remain assigned as they were
--> Like this - one can deal with the specific changes only but opnsense remains usable if not the core LAN interface was removed

Thanks for considering. Though I'd write it down before I forget it again ;)

This is the way...  8)

Looks like there's no way around doing this.
Might leverage the selective backup restore capability in order to minimize risks.

Ah. For that, from the console you should be able to re-assign interfaces after boot and it will put the right names in the right places in the config file.

That's what I did.

But it nevertheless caused some configurations to be lost and or/wrong.
Out of 4 interfaces only 1 really changed effectively but it was enough to confuse opnsense completely. Worse it usually does some autoassignment as a fallback which is almost ever completely wrong. This might be the root cause for what I'm currently dealing with.

I think some handle it a bit better. I have to analyze the config file first.

But to make it short: Replacing a NIC on a server triggered a new interface assignment (only 1 changed) which kind of made a mess of my opnsense. It mostly recovered by now and I reconfigured some things but I still don't trust it fully without verifying it.

Things such as static dhc assignments, fw rules, etc. where just lost afterwards.

Yes that's certainly an option. Quite time consuming but an option...

Haha, unfortunately that's also socially hard to sell...  8)

Guess this may end in:
the pitcher goes so often to the well that it is broken at last
*OPNsense

I have an OPNsense installation that is now a bit older ~2 years. I did some hardware changes and reconfigurations along this.

Now I have the feeling that my config file probably accumulated quite some stuff that may not be ideal anymore.
On the other hand I'd want to avoid time consuming setup from scratch. OPNsense is a critical piece of my infrastructure and longer internet downtimes are socially not acceptable ;)

On the other hand some times OPNsense config pages load slow. In general they're fast but sometimes they just keep loading which let me believe some clean up would be beneficial.

Manually cleaning out the config file seems to be a bit dangerous as well.

Any recommendations regarding low-risk OPNsense house-keeping? How does everybody do this?
Thx

If I recall correctly this was an error message in dmesg of the vmhost.

The root cause of all of this packet loss was a bad ethernet cable. It took me weeks to identify though since there we no clear error messages or indications and I only had breaking problems intermittently.

I had in the meanwhile switched on suricata again shortly after and have deactivated it again since ca. 2-3 months because suddenly strange failures occured that were even crashing the vmhost without any logs or hints.

Also the UI to configure suricata is imho not very good in terms of usability.

With both the above I currently do not see any value or benefit of activating suricata again.
I used to use zenarmor as well but couldn't find any value in addition to the DNS and L3/4 blocklists I am already using.

I think suricata could be a powerful component once the performance, stability and usability issues are addressed but I it's likely going to take years until we're there.

I'm not 100% sure for OPNsense but in Linux you could solve it by creating a bridge spanning both interfaces with one IP. I suppose the same is possible with BSD/OPNsense.

Thanks understood. Some problems solved, some newly created...

Thanks. That's so far also my understanding.

But doesn't that kind of also make it impossible to restrict outgoing traffic ip based when the outgoing ip is constantly changing?

Hi,

I'm playing around with IPv6 and start asking myself how I can at all work with firewall rules that are specific for a single host while privacy extensions are active.

Privacy extensions are probably wise to use to not expose to much information.

But it seems that I am loosing the ability to i.e. open up specific ports for single hosts when the ipv6 address is constantly changing.

Any thoughts / advice on this?

Thx

Look at the screenshot I just posted before.

There's 4 cores and 16 GB RAM assigned to OPNsense.
My system has more cores and more RAM. And the overall system load is different.

Nah this is not true.
Proxmox reports resource usage of the to a VM assigned resources. Therefore they should be the same.