Messages

Thanks for the help, all. I can confirm that adding a UUID to the VLAN in config.xml and reconfiguring fixed my issue.

I can only assume that the age of my VLAN, remaining untouched for multiple main version upgrades of Opnsense caused it to never receive a UUID at all. I suppose I should file a bug, now... sigh.

I feel ignored 😉

I'm sorry, but I didn't see anything in your post which required a reply. It was obvious from the beginning that UUIDs were used to identify the VLANs, as all API methods were referencing UUIDs - the issue being that the UUID for my VLAN changed every time it was retrieved.

I think I missed an apply. I suspect the same could happen the other way (deletion fails because the assignment is still present).

I had no reason to believe any of this applied to me. I had a fully functioning VLAN for years, I obviously didn't miss clicking apply. And my VLAN was not assigned.

You should be able to find the operation that "corrupted" the configuration by looking at the history.
Hopefully you didn't mess that up when you edited in the config file by hand.

I have never edited my config file before today. Hell, I had to ask in this thread where it was!

My oldest backup has my vlan in its current state - that is, without a UUID. It was from 6 April 2023.

Btw, what version OPNsense are you running, my test was on 25.7.a_36.

OPNsense 25.1.1-amd64.

For it to be reported I guess it would be helpful to know the current OPNsense version and if possible get an idea of the upgrade path taken (e.g. "started with OPNsense 1 in 1889 and went from there" :) ) and best the full config file (minus all privacy sensitive data). Somewhere along the upgrades the UUIDs should have been added but wasn't.

I'm afraid I haven't the foggiest when I installed Opnsense. I'd guest 2022...? But I've at least run this install through the last 3-4 major versions.

The config file is huge, I wouldn't feel comfortable sharing it publicly even if I had tried to clean it up.

It's funny, I had the same idea to reimport the xml, modified - but I was a little scared that importing a settings backup would clobber other settings.

Here's my VLANs from my config backup. It looks a little different :)

<vlans version="1.0.0">
    <vlan>
      <if>em0</if>
      <tag>10</tag>
      <vlanif>em0_vlan10</vlanif>
    </vlan>
  </vlans>

Presumably the lack of stored UUID explains the UUID changing every time the VLAN list is requested.

If you're comfortable with the SSH shell, after making a backup remove it from the config.xml and reload the services "(11) Reload all services".

Actually, that's the option I would prefer, if it's safe. If I make the changes to the configuration manually, I can be more assured that whatever backup restoration logic won't clobber anything unrelated. Where exactly is the config.xml?

But your browser is not talking to an API. It's talking to a web application which is running just fine. Even when there was no bug and it would correctly display "VLAN not found" or some such, you would see a perfectly well rendered UI with an error message box in it. That's HTTP 200 in my book.

It's not the browser in question, but rather the application running on the browser. The browser is just a platform, like the java runtime - it doesn't do anything on it's own, and it doesn't interpret http status codes (except for rendering errors when the main document fails to load). The codes exist for the convenience of the application, typically making error handling easier and more general.

After all, you said it yourself - the application should show errors from the server as an error message. But Opnsense is *not showing the error*! It's failing silently! Which is why I had to break out the devtools to find out what went wrong!

So if the Opnsense server-side reported errors in the standardised way, using http status codes, then the Opnsense front-end could be programmed to automatically show error messages whenever an API request returns a failure code. That's what they're for!

Anyway, this is getting off-topic. The primary issue is that I am stuck with an unremovable VLAN, and all the error messages in the world won't rid me of a useless VLAN.

- Interfaces > YOUR_VLAN - uncheck "prevent interface removal"
- Interfaces > Assignments - delete the interface assignment
- Interfaces > Devices > VLAN - delete the VLAN

Thanks for the reply, but I did state in the first post that I did unassign the interface first. I didn't touch a checkbox called 'prevent interface removal', but presumably that no longer applies if the interface is unassigned?

Just no. 404 is when the web server cannot find anything mapped to a particular URL not when an application cannot find a managed entity inside that application. HTTP error codes are concerned with the HTTP protocol only, not with anything you drive over HTTP.

We're going to have to agree to disagree. In a REST protocol, both HTTP verbs and status codes are for the use of the application programmer, and are very useful in the creation of a predictable and easy-to-use API. Without use of status codes, the client-side has to do a bunch of complex validation logic on all replies from the server to ensure that the operation succeeded, ensuring that valid JSON and the correct 'success' message were passed.

With use of the 404 code, the client side could do simply set a default error handler for a set of status codes which displays the error to the user. This can be done globally for every request in the application with a single line of code.

And this thread proves my point - the Opnsense frontend does not validate the server response, and thus when the operation fails unexpectedly, no error is presented and I have to dig into the devtools to find out what went wrong.

Besides, if the application doesn't make use of status codes, literally why do they even exist? Apart from the main document request, where the browser displays HTTP errors, any failures to requests initiated by the page or JS are completely silent - unless the user looks in the devtools. So why do they exist? They exist for the application to use, to report errors from the backend to the frontend in a simple and standardized way.

How did it not work, error message in the GUI?

Sorry, I should have been more clear. As the thread title said, it fails silently. No feedback whatsoever. That's why I delved into the devtools, as I had no idea what was happening.

And I'm sure you are aware what the HTTP return codes refer to. And since you do, you know that 200 means the HTTP request was successful; which it was. The API call on the other hand returned a sensible answer too, "not found".

That's a very... interesting... opinion as to the purpose of http status codes. In this case, the correct code would have been 404, entity not found. Using them in this way can dramatically simplify error handling on the client side, allowing client side code to confidently assume the operation succeeded on a return of 200 and confidently assume failure on a non-2xx return.

Hi all,

I've been running Opnsense for a number of years on an ISP which required all traffic to be tagged with VLAN 10. I've now changed ISPs, and no longer have to tag my traffic. So, I unassigned the VLAN device in Interfaces>Assignments, and went into Interfaces>Devices>VLAN to delete the VLAN. This doesn't work.

In the browser devtools, the delItem call returns http 200 "not found", always a good sign. Oddly, the UUID which is sent in the delItem call is different from the UUID returned in the immediately following searchItem call. I tried to delItem the UUID manually, but that didn't work either.

The cause was immediately obvious. I re-ran the searchItem call, and the reported UUID for the VLAN changed. It is being re-generated every time it's requested.

For this reason, editing the VLAN fails, as the getItem calls fail with the error code http 200 and empty body.

(You can tell this is quality, secure software with the way they very securely return 200 for all http reqs, and don't report errors to the user.)

The VLAN certainly still exists, is available for assigning and appears in ifconfig output.

I've tried forcing a deletion by putting the ifname in /tmp/.vlans.removed and running #configctl interface vlan configure, which correctly reports a failure to delete the interface by printing... 'OK'. (I'm noticing a pattern here) It does clear the file in /tmp/.

Any ideas?

Just noting here that I did a firmware update recently and that fixed this problem, and I could configure caddy to update my certs again. Bit of a mystery, but oh well.

Please see my attachment. There are no tabs. Other pages in the caddy plugin, such as Reverse Proxy, have tabs.

I'm using the default theme and there are no hidden HTML nodes, I checked with devtools.

EDIT: Yes, I just updated everything today.

***GOT REQUEST TO INSTALL***
Currently running OPNsense 24.7.1 at Tue Aug 20 23:03:14 NZST 2024
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
Updating mimugmail repository catalogue...
Waiting for another process to update repository mimugmail
All repositories are up to date.
The following 2 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
   caddy-custom: 2.8.4.2.0.4.2.2_2 [OPNsense]
   os-caddy: 1.6.2 [OPNsense]

Hi all, I recently discovered that there is now an official plugin for Caddy, so I've been migrating my old setup from the migumail one.

However, I can't find any way to set up DNS provider API cert validation. The official docs specify "Services ‣ Caddy Web Server ‣ General Settings ‣ DNS Provider", but I don't have any 'DNS Provider' option under General Settings.

Thankfully Caddy works by picking up my old cert from my previous installation, but this will break in a couple of months. I can't use standard cert validation, as I don't expose caddy on WAN. What's going on?

Hi all,

A few days ago, the terrapin attack on SSH was disclosed. https://terrapin-attack.com

OpenSSH 9.6 includes a new automatic strict KEX mode to mitigate this attack, but both client and server need to support this. As OPNSense ships OpenSSH 9.3, are there any plans for either an OpenSSH update or a targeted patch?

See the PFSense discussion: https://forum.netgate.com/topic/184941/terrapin-ssh-attack/

FreeBSD advisory: https://www.freebsd.org/security/advisories/FreeBSD-SA-23:19.openssh.asc

It seems upstream has already patched.