Messages

https://github.com/opnsense/core/issues/10842

If you think its a bug please open an issue on github here:

https://github.com/opnsense/core

I opened an issue on github: https://github.com/opnsense/core/issues/10842

I'd first check whether the certificate object is actually included in the OPNCentral provisioning payload, not only selected in the GUI. If the target never gets it into the certificate store, the Web GUI assignment can't happen either, so the issue is likely before the final WebGUI config step.

A couple of things worth trying: remove and re-add the certificate selection in the provisioning profile, save/apply, then trigger provisioning again; also confirm the cert includes the private key and is not just a public cert/CA. If possible, test with a newly created/imported dummy certificate to rule out a broken reference to the old cert object. If that still does nothing and there are no logs on either side, this may well be a regression in os-OPNcentral 1.12_2 and should be reproducible for the plugin maintainers.

Thank you, RaphaelAlbrecht, for your response. Of course, we had already tried all of that. We attempted to distribute the certificate centrally in countless configurations.

As a result, we reached the same conclusion as ig-it1342. The distribution only takes place when a setting in the WebGUI has also been changed manually. Only then is the certificate activated accordingly and distributed at the same time. The underlying mechanism works as described in the documentation. The WebGUI is simply provisioned only when any other value has been changed.

This means that I have to access each firewall individually and adjust one of the aforementioned settings so that it differs from the setting in OPNcentral. Only then can I centrally "push" a certificate and configure it at the same time. I would describe this behavior as unintended, since it contradicts the idea of centralized management—namely, being able to manage everything centrally from OPNcentral.

And I believe this unexpected behavior might actually be a bug.


Best regards, 
Stephan M.

Maybe there is a bug in the logic of OPNCentral related to certificate comparison?
Anyways, thanks for the help

Hello everyone,

As ig-it1342 mentioned, we experienced exactly the same issue in our OPNsense Business Edition environment. I think this is an unknown bug. If everything is configured correctly, the provisioning process does not detect any changes. In this case, the certificate is neither pushed nor installed.

For example, changing the session timeout under System > Settings > Administration from the default value of 240 to 241 and saving the change causes the provisioning process to detect a difference. It then pushes the certificate and activates it as expected.

+1


Best regards,
Stephan

Der Plan ist es, dass es irgendwann in der GUI möglich ist.
https://github.com/opnsense/core/issues/7522


Ansonsten config.xml backup bearbeiten und halt sehr aufpassen und dann importieren.

Vielen Dank @Monviech (Cedrik), das werde ich probieren. Klingt aber nach einer guten Option. Vermutlich muss man dann aufpassen, dass opt7 dann überall ersetzt wird durch wan.

Hallo,

ich vermisse eine Funktion, um die WAN-Schnittstelle auch als Identifier wan statt in unserem Fall opt7 zuzuweisen, da wir eine umfangreiche zentrale Firewallkonfiguration vorhaben und dabei die Adapter (Identifier) identisch sein müssen. Daher ist es erforderlich die Identifier der jeweiligen Interfaces im Assignment entsprechend einheitlich zuwiesen zu können. Jedoch scheint es keine Funktion über die WebGUI zu geben eine Schittstelle als WAN mit dem Identifier wan zu belegen.

Der Versuch über die Konsole ermöglicht dies, hat aber zur Folge, dass alle anderen Adapter aufgelöst werden. Vermutlich wird über die Konsole ein Status-quo erzeugt, also alle bisherigen Adapter, die an dieser Stelle nicht erneut zugewiesen werden, werden entfernt.

Hat jemand einen guten Tipp, welche Möglichkeiten es geben könnte, den aktuellen Adapter opt7 in wan umzubennen, ohne die bisherigen 7 Inferfacezuweisungen (HA, MGMT, VLANs, usw.) aufzulösen.



Danke im Voraus!

Beste Grüße
Stephan M.

[ofm01]

Hi everyone,

I'm reaching out because I'm facing an issue with OPNcentral. First, a bit of background.

We have 12 Deciso firewalls that we want to manage centrally. To achieve this, we spent a significant amount of time evaluating OPNsense and built a separate lab environment where we recreated and tested nearly every scenario we could think of. The testing was extensive, we learned a lot, and we were able to implement the environment exactly as intended in the lab.

We then started deploying everything in production. All the knowledge we gained from the lab was incorporated into the rollout, and the deployment is in progress.

We now have a dedicated management appliance, ofm01 (DEC-2770), which is used exclusively for centralized management. It is properly licensed, has only a single active interface configured with the LAN address 10.18.23.250/21, and the WebGUI port has been changed to 4444. Appropriate firewall rules (NEW) have been created to allow the required communication. According to the live firewall log, however, the Anti-Lockout rule is handling the traffic. Additionally, LDAPS is configured successfully, and OPNcentral has been set up according to the documentation, except for certificate distribution. Certificate validation is currently disabled (the corresponding checkbox is unchecked).

We also have two firewalls (DEC-4280) also properly licensed, fw03 (10.18.23.251) and fw04 (10.18.23.252), which are fully configured as well. They are accessible via https://10.18.23.251:4444/ (and the corresponding address for fw04). All three systems have been configured successfully. Both firewalls are running in an HA configuration and synchronize successfully via a scheduled cron job. At this point, all three systems are running Business Edition 26.4.

The hosts were added to OPNcentral, and centralized provisioning worked flawlessly for several weeks—until about four weeks ago, just before I went on vacation. After I returned (and nobody had made any changes in the meantime), OPNcentral was no longer able to communicate with the managed hosts. Every connection attempt now times out, and I only receive a cURL error 28 after 20 seconds. As a result, centralized firewall rule management—the primary feature we intend to use—is no longer possible.

Here are the troubleshooting steps I've already performed:

* All firewalls are directly accessible WebGUI from using the configured URL from OPNcentral without any issues.
* I successfully tested ICMP connectivity using the Diagnostics tools between ofm01 and fw03, as well as between ofm01 and fw04. Both tests completed without packet loss.
* For troubleshooting purposes, there are currently permissive ANY firewall rules in place, allowing traffic from any source via any protocol to This Firewall on any port.
* I generated a new API key for the existing OPNcentral API user — no change.
* I created a completely new API user along with a new API key — also no change.
* I updated all three systems to Business Edition 26.4.1p2 (current patch level) and rebooted them.

None of these measures made any difference.

I've spent several days trying to identify the root cause, but without success. In our lab environment, the exact same OPNcentral setup—with the same IP addresses and configuration—has been working flawlessly for many weeks. Unfortunately, I can't get the production environment working again.

I'm hoping someone here may have an idea or can point me in the right direction.

Thank you very much in advance!


Best regards,

Stephan M.