Hello from new User and some questions about UX weirdnesses

[part_time_nerd]

Hi all,

some time ago I decided our home network would need a bit more structure than just a Wifi Router with Merlin on it. So I replaced our three switches with vLan capable units and a piece of hardware with four intel GBit ports for a router and created a plan on how to put family, guests, kids, home automation and shady china hardware into separate networks for better manageability. I just had no experiency with any OSS router distro so I went searching. After some reading I decided to try opnsense. I downloaded and installed the 17.1 into a KVM guest with 3 of the network interfaces directly attached. It installed flawlessly, I created the required interfaces and routing and put it into the closet and I am still able to write this little story. So far, it was a success.

Unfortunately, shortly after installing the router, the opnsense GUI started to act strangely. I am using the default root user which I did not alter in any way (except the pw of course).

• For example, in the dashboard, the GUI shows the IDS (suricata) as running (also, the console mentions it starting on boot). When I go to Services/IDS, it is "off". No rules are shown and no alerts. When I try to switch it to "on", the spinner in the "Apply" button starts spinning forever and that is it.
• When I go to "Reporting/Insight", there is no graph drawn. The drop down in the lower graph shows two items: "401" and "Authentication failed". Resetting the RRD Data in Setttings did not fix it, but caused Reporting/Health to fail. with a JS Alert "Error while fetching RRD list". Maybe the latter is temporary.
• When I go to "System/Firmware/udpates" I can click on the "Check for updates" button. It then says "Checking... (may take up to 30 seconds)" ... forever. When I go to the "Packages" tab, I get "No packages were found on your system. Please call for help.". At this point I made a backup of the VM and went to the console, selecting "upgrade from console". It went on and installed roughly 50 packages (I did not recognize any suspicious error messages scrolling by \o/), effectively moving opnsense from 17.1 to 17.1.3 and rebooted. However all the GUI errors mentioned above are still present, which makes me wonder how to deal with this.
• I found several other flaws which I will report separately.

[franco]

Hi there,

Just quickly: none of those are normal. How much RAM and disk space does the VM have? Can you provide a screenshot of a defect of your choosing? :)


Thanks,
Franco

[part_time_nerd]

none of those are normal. How much RAM and disk space does the VM have? Can you provide a screenshot of a defect of your choosing? :)

Thanks for answering so promptly. Of course, I can provide you with any information you desire.

The machine has 2 exclusive Cores, 1GB of RAM and 10GB of disk available.

root@router:~ #   df -h
Filesystem           Size    Used   Avail Capacity  Mounted on
/dev/ufs/OPNsense    9.7G    1.1G    7.8G    13%    /
devfs                1.0K    1.0K      0B   100%    /dev
devfs                1.0K    1.0K      0B   100%    /var/dhcpd/dev

[fabian]

This looks like some JavaScript files are not loaded / missing. Can you check the data sent and received by the scripts?

BTW: you can try to reinstall the GUI with "pkg install -f opnsense"

[part_time_nerd]

HAHAAA! I think I found the root cause (bug)!

That is quite a funny one!

@fabian, since I just upgraded opnsense today (see above) , the package had been reinstalled already and I left this one out.

But I decided to look at the network debugger in FF and see if I spot something. Aaaand there, in my FF session with the debugging extension, everything suddenly worked as expected!

This promptly caused me compare the request- and response-headers of the affected vs the unaffected instance. Et voila... since opnsense just replaced my old router, it had inherited its hostname "router". And for that name, my day-to-day FF session has some stale BASIC-AUTH data stored, which it still sends along with every request! Apparently some component in opnsense that is not invoked in every request (probably XHR only because of the dreaded API, which really seems to haunt me in a way!) tries to make (opn)"sense" of that data and fails. These requests are then not properly answered, hence the weird appearance. And that also explains why the interface suddenly stopped working properly once it was actually productive.

The proper fix should probably be to ignore a failed BASIC AUTH in XHR API requests as long as a valid PHP session cookie is also available.

[fabian]

you could clear your cache in such a scenario if you like