Messages

I feel like going offline for a few years now, going hide under a rock :-D

Thanks for keeping the patience and clarifications

There is no 26.7 BE, only 26.4 with 26.10 expected soon.

XX.1 - community
XX.4 - business
XX.7 - community
XX.10 - business

And since you cannot downgrade, you cannot get from 26.7 to 26.4 ...

well, i completely missed that since 26.4 BE kept suggesting upgrading to 26.7 BE so I blindly downloaded 26.7 assuming that would be the BE iso
I missed this particular post between reboots so thanks for the clarification.

You need to start with 26.1 and switch to 26.4 if you want to run the current business edition.

I came from 26.4 which failed to upgrade the VM so i started with a new VM and did a fresh install from 26.7

26.10 hasn't been released yet so the message is expected.


Cheers,
Franco

you mean installing 26.7 business edition from ISO has as a logical outcome that 26.10 community is selected as a non-changeable default and that's expected behavior?
the license key is configured and 'business' is selected as a well as a commercial mirror, it proves impossible to change to 26.7 from 26.10 no matter what, and that's expected behavior too?

[https://opnsense-update.deciso.com/${SUBSCRIPTION}/FreeBSD:15:amd64/26.10]

> installed 26.7 on a new VM
> imported the 26.4 configuration on 26.7
> did an update check
> found 26.10 was contacted for updates not 26.7
> license key is and was correct, unable to set to business
> tried changes in config files, rebooting, no change
> updates are stuck with 26.10

Type	opnsense
Version	26.7
Architecture	amd64
Commit	821598263
Mirror	https://opnsense-update.deciso.com/${SUBSCRIPTION}/FreeBSD:15:amd64/26.10
Repositories	OPNsense (Priority: 11)
Updated on	Mon Jul 13 17:01:42 CEST 2026
Checked on	N/A
Licensed until	2026-11-12

> loosing all logs ?

Strictly speaking you can only import /conf if you even chose to do so.  The logs in /var are always deleted anyway with the rest of whatever happened to be on the disk before.


Cheers,
Franco

I have a hard time understanding what you mean with "if you even chose to do so" You mean like people are expected to manually reconfigure the entire firewall after each forced reinstall?

Try to wipe the disks, first.

loosing all logs ?

using 26.7 DVD ISO I'm trying to install on the OPNsense VM, choosing auto-install ZFS shows 'no disks detected' while choosing manual install shows both disks and partitions

I don't understand how this possible and cannot find anything extraordinary hinting at a reason why.

dnsmasq : disabled : configured dhcp + dns

kea dhcp: enabled : configure dhcp, uses unbound for DNS (so no host resolved), this gives leased and DNS lookups work except for LAN, as expected

switching to dnsmasq, disable kea, disable unbound, enable dnsmasq
no leases are handed out by dnsmasq

so, same firewall configuration, no leases
in 'live view' i do see bogon network detection + a drop, these are multiple drops for dnsmasq while a single drop for kea
dnsmasq = no lease, kea = lease

please, your thoughts and recommendations

@meyerguru thanks for the follow up.

However, i feel the need to follow up since you keep responding besides the point and refuse to acknowledge to this.

The point being the mac addressed were shuffled across interfaces, that was entirely unrelated to the interface renaming.
Trust me on that.

[reoccurring bug]

This has been going on since quite some time. The fix reported is to 'delete all netflow data' which does not sit well with me.

This looks like a reoccurring bug ? Not few posts on this board signal this error happened in the past.

flowd_aggregate.pyflowd aggregate died with message Traceback (most recent call last): File "/usr/local/opnsense/scripts/netflow/flowd_aggregate.py", line 162, in run aggregate_flowd(self.config, do_vacuum) File "/usr/local/opnsense/scripts/netflow/flowd_aggregate.py", line 80, in aggregate_flowd stream_agg_object.add(copy.copy(flow_record)) File "/usr/local/opnsense/scripts/netflow/lib/aggregates/source.py", line 69, in add super(FlowSourceAddrTotals, self).add(flow) File "/usr/local/opnsense/scripts/netflow/lib/aggregates/__init__.py", line 187, in add self._update_cur.execute(self._insert_stmt, flow) sqlite3.DatabaseError: database disk image is malformed

/var/netflow shows no broken files or lock files left behind

work-around with data loss

Code Select Expand

cd /usr/local/opnsense/scripts/netflow/
./flush_all.sh all

BUG report created https://github.com/opnsense/core/issues/9499

Thanks @meyerguru for the informative response, none of that is on topic in this case.

The Proxmox cluster was not given any changes, neither was OPNSense given any chances.
I'm familiar enough with both and with networking, OS and such to consider this a possible bug lurking.

On investigation of the outage I could only conclude the interfaces were shifted, meaning vtnet0 had two mac address (one mac and one ethernet address) and vtnet1 had the mac address of vtnet0, vnet2 had the mac address of vtnet1 and so on.

I remember seeing an unusual error on Promox networking some time ago but this did not result in any notable issue, that was weeks if not one or two months ago.

The reason I mention the renaming as a fix was because runinng the below command, resolved the issue.

Code Select Expand

pve-network-interface-pinning generate
This command renamed the interfaces from enpNNsNfN to nicN
That's it.

No other changes were required to fix an outage taking over 12 hours to (casually) analyse and attempt to pinpoint.
The fact the OPNSense VM interface were scrambled/shift concerns me as this suggests an OPNSense VM to be really weak.

I'm now preparing to shifting away from use of virtio to see if this offers more stability in the long run.
To memory this is the 2nd time this kind of workaround is required and I never see any cause in the logs.
No errors, no warnings etc.

For the n-th time I found Proxmox+OPNSense to get into trouble.

Each time it takes a long time to get to the issue which is essentially 'rewriting' interface names.
Yes, I did not bother to go look for configuration files, yet, there was no indication the config was wrong.
Neither for Proxmox neither for OPNSense the config changed in recent months.

What appears to happen and is observed as a progressive issue is ... first some disruptions, eventually in Proxmox the OPNSense VM shows normal config on the outside but on the inside the interface MAC from the VM is assigned to a different interface or as a secondary MAC (yeah, i know)

I'm now swithching the WAN from virtio to e1000 to see if that makes any difference.

To me this is a mind numbing issue. At one point the OPNSense admin interface was no longer reachable while this is over a dedicated interface with a direct connection over UTP.

The fix was to use a Proxmox feature to rename the interfaces, last time I did something similar manually, this also worked.

Specific to OPNSense I'm worried Proxmox can simply reassign MAC and this doesn't revert, for OPNSense to allow for multiple MAC or a MAC which is not matching the configured vtnetX interface is concerning.

Hoping for your feedback, available to work on analysis if possible.

For some appliance central log collection is not an option and the log query features are not superb.

Would it be possible for me to use a database tool to query the opnsense logs as if it were a database ?

[SOLVED]

SOLVED, thanks to the articles below,

Main reason assumed is MAC address are the same for all vlan (obviously) as the Debian page documents

auto LIF
iface lif inet manual
        bridge-ports eth0
        bridge-setageing 0
        bridge-stp off
        bridge-fd 1
        bridge-vlan-aware yes
        bridge-vids 401 402 901 1500
        mtu 1422


I'm not certain if the MTU reduction is required, should not matter much.

on the switch the port is now again set to General - accept tagged only

inside OPNSense the vlan interface has the MAC of the parent set, no other modification was made to the vlan interface
at this point i don't think that really matters

I also set this tunable to 1 : Select the tunable net.link.bridge.pfil_bridge and set the value to 1

https://docs.opnsense.org/manual/how-tos/lan_bridge.html#step-six