Messages

Can we stop the ranting now about UX that's already been fixed? If people want to talk about how esoteric and abstract network device names are they can open a new thread in general discussion.

And if people don't give feedback during development releases we gladly receive feedback in community release. That's all there is to it.


Cheers,
Franco

Franco,  OPNsense is an awesome platform for many reasons and I spent alot of time looking for a new standard for my clients and chose this over PFsense and other brand named solutions because I saw the potential.
I am sure the development team work very hard to address issues, add function and produce an awesome product overall which for many is free to boot  ;)

I am providing critical feedback as a result of having just had to fire fight a situation with a critical failure in the boot process, after the 22.1 upgrade, at a large client where we have a number of VLANs and where I only had console view.

I am not aware of the development cycle or input process, I am busy with business matters not monitoring detailed development aspects; I assume development decisions around networking would follow general standard practices.  Suddenly finding out, during a fire fighting critical down event and recovery process, as to these changes is why the reaction and response is coming.

I have not seen how VLANs are listed at the console level yet under the new platform 22.x however I have seen how they are at the GUI level and this is why I provided a visual feedback and comment - mostly for other Users  who are starting out or as with me restoring from backup to a new and dis-similar hardware and having to recreate VLANs.

"UX that's already been fixed?"  are saying they have addressed this issue? or are you saying that since we are in production release no changes can be made?

My posts are really simply to express shock but mostly to provide guidance as well to those who have not encountered VLANs yet or who are rebuilding like me... that is all.

I love the product and can work around this .. but I can tell you, when you are monitoring down time by the minute ... having to do VLAN ID to interface/tag translation is not fun.. and if adding the vlan tag in the description simplifies things, then let's let people know :)

I thank you for any your support and knowledge you share with the community.

This may be a long-shot, but after the upgrade to 22 from 21 when I powered down the opnsense system (pressing the power down button), it rebooted.
This was reproducible, and there was no apparent reason why this would occur.
I then reset the bios.
The reboot issue has gone (fingers crossed!!)
This issue did not occur with 21, so I wonder if 22 modifies the bios in some way?

Thanks for the suggestions... I was onsite in an emergency capacity with the entire accounting office not able to work as many of their programs required web authentication to verify subscriptions (stupid especially in tax season if internet goes out) ...

The immediate solution I found thanks to a forum post was to use the CTRL+C to cancel the archive load retry attempts and the box booted fine and is seemly fully functional... but if it has a reboot for any reason it will get stuck again and require console mode intervention...

I have backed up the config and setup a new box which is also an upgrade and once I do the swap tomorrow I will try your suggestions on the old box to see what happened and what can make it work great again :)

Cheers

Why not just use/pick the tagged ID that the user enters as the deviceId? I do understand the silly naming convention but coming from the networking and coding side you never want to use something and call it something else.

banana = "pickle"

VLAN05 = 99

????

OMG - I thought this was a little issue but if you do not name / description the  VLAN and include the VLAN tag, then the interfaces listing shows the device ID and you cannot tell what the TAG is unless you go into the VLAN section and look. 
I get the reasons why not to use the interface reference, I just dealt with it, while I restore the clients configuration on new hardware but this is a messy way to resolve that issue, in my opinion.

Just saying to others who are reading this, make sure you put the TAG in the Description, you are going to be thankful one day ...

LOL - still love the platform but the upgrade to 22.x has been painful - yet I learned a lot restoring to new hardware.

Why not just use/pick the tagged ID that the user enters as the deviceId? I do understand the silly naming convention but coming from the networking and coding side you never want to use something and call it something else.

banana = "pickle"

VLAN05 = 99

????

::) - that seems to make a lot of sense, I mean you are not going to have two vlans with the same tag.  I am just restoring a client's UTM to new hardware and discovered what @lilsense meant.  My VLAN 20 has a device ID of vlan03; see attached.  This could be messy when one is onsite dealing with an emergency and in the console trying to match vlan id's with vlan networks.

<side note> awesome job on backup - download config - exports all incl.  openvpn stuff - so powerful.  Was so proud of this platform when I saw that and everything just works after adding the plug-ins.<end side-note>

How hard would it have been to simply to code the platform to use the inputted tag instead of using a sequential generator.  Having symmetry across the naming convention just make simple sense however... I am not a coder/programmer just a glorified end user with 24 years in the business and seen a lot. 

Well, lets hope during an emergency support session this doesn't blow up in my face; with the current failure, we were monitoring downtime of the OPNsense router in minutes with the Named Partner of the firm watching over my shoulder as his entire office could not work during tax season.

22.1 was installed and it rebooted the device after the install and things came back online.  (upgrade done from GUI)

However the appliance was rebooted and then failed to start.  I had to go onsite urgently for the client and through the console view saw the system booting and then looping on Archive tar failure and re-trying.

This device has been running for about a year and we only encountered this issue after the 22.1 upgrade; of course it maybe coincidental.

I found a thread where someone said you can CNTRL+C to skip and this worked, THANK GOD.

But now I am reading I should perform a clean install and restore::: any suggestions appreciated.

I also do not see a clean / simple way to backup the device configuration including OPENvpn users and certificates - any thoughts / suggestions appreciated.