Messages

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

Alter... Wald.. Bäume. Bretter am Kopf...

Das hab ich nicht gesehen. Vielen Dank!!

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?

Same issue with Business Edition 24.4 and ESXi virtualization :-\ Looping packages sounds right...  have imported a  snapshot version from before and will investigate this next week. I don't know what I need to reconfigure yet.

Thanks to @mimugmail here is the answer:

The exception only works for existing addresses, meaning if 185.199.108.0/22 is actually an entry in Firehol, it would be removed from there. However, there is no scripting logic that takes out the entire network and checks whether individual entries fall into this net. Handling this in a dynamic list is unfortunately difficult.

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?

It's been a while since this thread but in case anyone stumbles across it: https://gist.github.com/derhelge/1ce6d31f106beea37dfcb36591ac63a7 There is a small Powershell script. We use it to be able to continue using WOL via SCCM / configmgr.

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"?

Ja klar! NAT-Reflection!
Danke! Damit funktioniert es wie gewünscht und war nur ein Klick entfernt.

Vielen Dank!

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

Ah OK. Mir war nicht klar, dass ich mehrere "NOT-Regeln" anlegen kann... Danke für die Info!

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