OPNsense interface assignment persistence after changing an interface

[binaryanomaly]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• [x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

OPNsense interface assignment persistence after changing an existing interface

When changing the interface configuration i.e. removing an obsolete one, OPNsense "forgets" the whole interface assignment and configuration. This in many cases renders OPNsense useless after the next reboot because the random interface assignment rarely gets it right. To fix this one has to boot into console and assign interfaces manually again.

Describe the solution you like

OPNsense should remember the assigned interfaces and only remove/change the impacted one in order to ideally keep functioning.

Ideally also the orphaned interface configuration could be exported and deleted. Currently the configuration remains but is not accessible from the UI. In some cases this causes problems afterwards.

Describe alternatives you considered

Manual interface assigment from console after broken OPNsense setup. Manual config file clean up.

Additional context

This issue has been discussed in the forum already: https://forum.opnsense.org/index.php?topic=27023.msg160714#msg160714 https://forum.opnsense.org/index.php?topic=38126.0 (most recent feature suggestion)

[AdSchellevis]

Renaming using mac addresses can easily be offered via a plugin, maybe better move the ticket there. If it turns out to be useful in the long run, we can always move it. A pull-request to discuss would be helpful. (We are not planning to make renumbering of interfaces standard as it has side affects too)

[fichtner]

I think this also pertains to how recovery is handled on mismatch when interfaces are not locked... the topic is a bit of a hit and miss always as removing an interface will always have unintended consequences and the system cannot assess how harmful it was/going to be anyway.

I'm all for better ideas and PRs here. The topic comes up every year but compared to the user base I'd say this isn't something we should be sinking a lot of time in "perfecting".

Cheers, Franco

[binaryanomaly]

Thanks for your feedbacks. What I'd suggest is a very basic solution: --> OPNsense should remember the unchanged interfaces and only drop the removed/changed interface.

In the best case OPNsense keeps running and you can login to the webui and configure what may be required. Whereas today OPNsense drops the complete assignment and you have to do a full interface assignment and configuration from scratch from the console which would in many cases not be necessary.

[AdSchellevis]

You mean don’t auto detect if one or more interfaces in the configuration still match?

[fichtner]

That’s what happens when you lock your interfaces.

more often than not regaining access through standard means may be more useful than hoping the system will continue working (tm) yet I don’t mind changing the default but someone needs to figure out what to do on a factory reset or when migrating to a new hardware which is the bigger issue of a simple solution.

[binaryanomaly]

Hmm, maybe locking does indeed what I was looking for. I just would have never looked there for this and would have intuitively expected this to be the default behavior.

Factory reset or completely new hardware should imho trigger a complete re-assignment. However since this rarely ever correct without manual intervention it probably does not even matter that much whether this is triggered automatically or initiated manually via the console?

[fichtner]

I'm picking this up for 24.7 initally and some discussion internally about how to proceed but no promises. The problem is we only know people are happy with the way it is now until we've angered them by changing it. This topic is rather quiet compared to the number of installations that we have.

Cheers, Franco

[binaryanomaly]

Thanks Franco. Tbh it might be more of a UI/UX thing.

"Lock interface" seems to do exactly what I want it just wasn't clear to me and I'd rather have expected it to be the default behavior than having to activate it explicitly.

The other issue observed is that configurations particularly dhcp of automatically removed interfaces seem to remain persistent (hidden unchangeable from UI) and in certain cases block new configurations. These settings should become inactive or be removed for consistency.