Messages

[no_proxy=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.unseredomain.de]

Nach Tagen der Fehlersuche lag es dann schlicht und ergreifend an den Anführungszeichen.
Also hier für Alle, die zukünftig auf das Problem stoßen!


Korrekt funktioniert folgendes: no_proxy=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.unseredomain.de


Im OPNcentral muss es wie folgt konfiguriert werden:

# /usr/local/opnsense/service/conf/configd.conf.d/proxy.conf

Code Select Expand

[environment]
HTTP_PROXY=http://10.19.241.33:3128
HTTPS_PROXY=http://10.19.241.33:3128
http_proxy=http://10.19.241.33:3128
https_proxy=http://10.19.241.33:3128
FTP_PROXY=http://10.19.241.33:3128
ftp_proxy=http://10.19.241.33:3128
NO_PROXY=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.unseredomain.de
no_proxy=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.unseredomain.de


Beste Grüße und viel Erfolg!

[In der Konsole /root/proxy.sh, für Zugriffe wie wget o.ä.]

Hallo liebe OPNsense-Community,

ich bin auf der Suche nach Hilfe in folgender Angelegenheit.

OPNsense hinter einem Proxy ist soweit ich es recherchieren konnte, eher ein schwieriges Thema, da es sich an verschiedenen Stellen angeben lässt, aber nicht jeder Service diese Settings unbedingt auch nutzt. Wir benötigen den Proxy aktuell für Updates sowie den Upload von Backups in eine Nextcloud Instanz. Dies funktioniert aktuell auch soweit.

Aktuell setzen wir den Proxy an folgenden Stellen:

In der Konsole /root/proxy.sh, für Zugriffe wie wget o.ä.

Code Select Expand

PROXY_URL="http://10.19.241.33:3128" 
KEINPROXY="10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.unseredomain.de" 
 
HTTP_PROXY=$PROXY_URL 
HTTPS_PROXY=$PROXY_URL 
FTP_PROXY=$PROXY_URL 
NO_PROXY=$KEINPROXY 
 
http_proxy=$PROXY_URL 
https_proxy=$PROXY_URL 
ftp_proxy=$PROXY_URL 
no_proxy=$KEINPROXY 
 
export HTTP_PROXY HTTPS_PROXY FTP_PROXY NO_PROXY http_proxy https_proxy ftp_proxy no_proxy

# /usr/local/opnsense/service/conf/configd.conf.d/proxy.conf

Code Select Expand

[environment] 
HTTP_PROXY=http://10.19.241.33:3128 
HTTPS_PROXY=http://10.19.241.33:3128
http_proxy=http://10.19.241.33:3128
https_proxy=http://10.19.241.33:3128
FTP_PROXY=http://10.19.241.33:3128
ftp_proxy=http://10.19.241.33:3128
NO_PROXY="10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.unseredomain.de"
no_proxy="10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.unseredomain.de"

#  /usr/local/etc/pkg.conf

Code Select Expand

PKG_ENV {
    http_proxy = "http://10.19.241.33:3128"
    https_proxy = "http://10.19.241.33:3128"
    ftp_proxy = "http://10.19.241.33:3128"
}

Das Problem besteht nun darin, dass unsere OPNcentral Instanz (10.18.23.250) die API-Anfragen, die für die Provisionierung der Firewalls rausgehen, auch über den Proxy schickt. Daher habe ich die Einstellungen in der # /usr/local/opnsense/service/conf/configd.conf um no_proxy ergänzt.

Rufe ich nun über die Console

Code Select Expand

curl -v https://firewall1.unseredomain.de:4444/ auf, klappt das wie gewünscht und

Code Select Expand

curl meldet brav, dass es die Proxy Settings aus dem Environment verwendet:

Code Select Expand

root@opncentral:~ # curl -v https://firewall1.unseredomain.de:4444/
* Uses proxy env variable no_proxy == '10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.unseredomain.de'
* Host firewall1.unseredomain.de:4444 was resolved.
* IPv6: (none)
* IPv4: 10.18.11.251
*   Trying 10.18.11.251:4444...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
*   CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:

Im Livelog korrekt zu sehen, kommt die Anfrage von 10.18.23.250 und geht zu 10.18.11.251 auf Port 4444:
You cannot view this attachment.

Setze ich im OPNcentral über die WebUI einen Diagnoseping ab, kommt der an und wird auch im Log korrekt dargestellt.

Führe ich nun jedoch im OPNcentral über die WebUI eine Provisionierung aus oder rufe die Firewalls über das zentrale Management ab, wird die Kommunikation scheinbar durch den Proxy geleitet und es antwortet (glücklicherweise) ein entfernter Router und schickt die Anfrage zurück. Damit stimmt die Absenderadresse natürlich nicht mehr und es hat etwas gedauert zu verstehen, warum ein Zugriff nicht erfolgreich stattfinden konnte. (Hier war die Firewallregel natürlich nicht darauf ausgelegt). Im Screenshot zu sehen ist als Quell-IP nun eine 10.19.241.242. Damit hat die Anfrage das lokale Netz verlassen und ist über einen entfernten Proxy wieder zu uns zurück.
You cannot view this attachment.


Nun meine Frage: Gibt es noch eine Stelle, an der Proxysettings und Ausnahmen eingestellt werden können? Übersehe ich etwas? Mache ich etwas falsch?


Vielen Dank vorab!

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.