Topics

Environment:
- OPNsense Version: 25.4.3 Business
- API Documentation: https://docs.opnsense.org/development/api.html
- Python requests library with proper authentication

The firewall rule API endpoints exhibit two critical issues that prevent proper automation of firewall rule management.

Problem 1: searchrule API only returns enabled rules
Only enabled rules are returned. Disabled rules are completely omitted from the search results, even when using `"show_all": True` parameter.

Code Select Expand

search_data = {
    "current": 0,
    "rowCount": 1000,
    "sort": {},
    "interface": "lan",
    "show_all": True,
}

r = requests.post(
    f"{remote_uri}/api/firewall/filter/searchrule",
    auth=(api_key, api_secret),
    json=search_data,
    verify=certifi.where()
)

Problem 2: toggle_rule API fails with "result": "failed"
The endpoint consistently returns {"result": "failed"} regardless of valid UUID and state parameters.

Code Select Expand

r = requests.post(
    f"{remote_uri}/api/firewall/filter/toggle_rule/{valid_uuid}/0",
    auth=(api_key, api_secret),
    verify=certifi.where()
)
# Always returns: {"result": "failed"}

Additional Context:
- API key authentication works correctly for other endpoints
- UUIDs are valid and obtained from successful searchrule calls
- Similar issues reported in community forums without resolution
- Documentation examples do not work as described


Your help is appreciated :-)

Hello everyone,

In the documentation [1], I read about how custom configurations for unbound can be stored. But how can entire zone files be included in the chroot environment?

Background: I want to do DNS RPZ zone transfer with a shared secret. Since Unbound apparently cannot do this on its own, a workaround via dig [2] is necessary:

Code Select Expand


shell:
dig -y "hmac-sha512:rpz.nlnetlabs.nl.:<key>" @nlnetlabs.nl rpz.nlnetlabs.nl AXFR > rpz.nlnetlabs.nl


A config extension should include the following points:

Code Select Expand


server:
module-config: "respip validator iterator"
rpz:
name: rpz.nlnetlabs.nl
zonefile: rpz.nlnetlabs.nl


But how do I get the zone files copied to /var/unbound?

Many thanks,
Helge

[1] https://docs.opnsense.org/manual/unbound.html#advanced-configurations
[2] https://github.com/NLnetLabs/unbound/issues/336

Hallo zusammen,

ich habe einen OPNsense Cluster als zwei Nodes. Der Config-Sync funktioniert grundsätzlich ohne Probleme. Beim HAProxy wird allerdings nur die Konfiguration übertragen aber nicht angewandt. (Auch nicht beim manuellen Synchronize im HA-Status). Hat das einen technischen Hintergrund? Ich bin da leider schon mehrfach reingetreten und wundere mich, dass die Änderungen beim haproxy nicht auch automatisch angewandt werden.

Viele Grüße
Helge

Hallo zusammen,

in der Dokumentation [1] habe ich gelesen, wie custom-Konfigurationen abgelegt werden können. Wie können aber ganze Zonen-Dateien mit in die chroot-Umgebung?

Hintergrund: Ich möchte DNS RPZ Zonentransfer mit Shared Secret machen. Da Unbound das offenbar nicht selbst kann, geht ein Umweg über dig [2]:

Code Select Expand


shell:
dig -y "hmac-sha512:rpz.nlnetlabs.nl.:<key>" @nlnetlabs.nl rpz.nlnetlabs.nl AXFR > rpz.nlnetlabs.nl


Eine Config-Erweiterung müsste folgende Punkte beinhalten:

Code Select Expand


server:
  module-config: "respip validator iterator"
rpz:
  name: rpz.nlnetlabs.nl
  zonefile: rpz.nlnetlabs.nl


Wie bekomme ich aber die Zonen-Files irgendwo nach /var/unbound kopiert?

Viele Grüße
Helge

[1] https://docs.opnsense.org/manual/unbound.html#advanced-configurations
[2] https://github.com/NLnetLabs/unbound/issues/336

Hallo zusammen,

ich möchte den opnsense HA-Cluster gerne als DNS-Resolver für Clients in einem heterogenen Netz nutzen. Bisher wurden die Active Directory Domain Controller (ADDC) als Resolver genutzt.
Die Domains des ADs habe ich als forward-zone eingetragen usw.

Allerdings habe ich ein Problem mit der Umsetzung der opnsense unbound Konfiguration was die Erreichbarkeit der Firewall angeht:

Es werden automatisch alle eigenen Interfaces als local-data in host_entries.conf geschrieben. Das ist deswegen für mich unglücklich, weil die Firewall selbst nicht auf allen Interfaces erreichbar ist und local-data höher priorisiert wird als forward-zone.

Wie kann ich vermeiden, dass Interfaces in host_entries.conf geschrieben werden?

I use an alias map "firehol_level3" URL table connected to a rule on my interfaces. Unfortunately, github is blocked within this Blocklist from time to time. I have therefore created an alias map "Network group" "firehol_leve3_without_exclusions" , which contains two entries:
- firehol_leve3
- firehol_exclusions

"firehol_exclusions" is a network alias map. Content is e.g:
!185.199.108.0/22, !185.199.111.133/32

The problem is that a connection to 185.199.111.133 is correctly possible, but a connection to 185.199.108.133 is blocked.

If I look at the https://github.com/opnsense/core/issues/4318 on github, this should be possible as done?

Hi,

using os-etpro-telemetry there a lot blocked entries in /ui/ids#alerts:

Alert   ETPRO EXPLOIT Microsoft Protected Extensible Authentication Protocol RCE xbits set, noalert (CVE-2023-21690)
Alert sid   2853519

From my understanding, these packages should not be blocked? But the table says "blocked"?

Ich habe folgendes Problem: Ich habe einen Dienst (Webserver) mit der IP Adresse (hier 10.0.0.2). Ein externer Zugriff ist möglich, weil der Dienst per One-to-One NAT veröffentlicht wurde (hier 198.51.100.2).

User greifen per DNS zu: web.example.com zeigt im internen DNS auf 10.0.0.2 und in einem public DNS auf 198.51.100.2.

Das Problem entsteht, wenn User im Home-Office IPv6 aktiviert haben und der IPv6 DNS Server höher priorisiert ist. Wenn die User dann ins VPN wechseln, welches noch kein IPv6 hat, erhalten Sie vom public DNS 198.51.100.2.

Leider kommen die User dann nicht auf den Webdienst zu web.example.com sondern auf die opnsense Firewall.

Irgendwie fehlt mir der Ansatz was ich konfigurieren muss, damit 198.51.100.2 auch von den internen Netzen korrekt auf 10.0.0.2 zeigt.

Langfristig sollte es mit IPv6 im internen Netz natürlich auch funktionieren.

Viele Grüße
Helge

Hallo zusammen,

ist es in OPNsense möglich, eine Liste von Netzbereichen zu erstellen, bei denen nicht geNATted werden soll? Also 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 zB. Aber auch durchaus Adressen aus nicht-RFC1918-Bereichen. Habe bisher nichts dazu gefunden...

Viele Grüße
Helge