Messages

Die Berichte für Unbound und auch Unbound sind deaktiviert.
Ich forwarde auch keine Reverse lookups für private Netze in meinem DNS Pihole und auch nicht in OPNsense.

Soweit wie ich jetzt sehen konnte betrifft es nicht nur die 192.168.30.1er Schnittstelle, sondern auch die 192.168.20.1er.
Blöd nur, ich hatte die Paketaufzeichnung auf der 30er Schnittstelle laufen, aber der PTR Spam kam jetzt von der 20er, lol.

Hallo zusammen,

ich checke nicht, warum und weshalb eine Schnittstelle jede Stunde einen PTR Spam zu meinem DNS ausführt.
Vielleicht kann mich jemand erleuchten.

Dankeschön

1. Also ist das normal, dass man nur eine Subdomain anlegt?
Z.B.:
IP - Hostname -> FQDN
192.168.10.68 -> pihole -> pihole.alexanderb.de

Es macht also keinen Sinn intern und extern zu trennen, indem ich für intern sowas mache:
IP - Hostname -> FQDN
192.168.10.68 -> pihole -> pihole.home.alexanderb.de



Da hab ich scheinbar ein Verständnissproblem. Ist das dann so, dass man eigentlich immer mit aktiviertem VPN mit seinen Geräten unterwegs ist und stetig per VPN mit seinem System zu Hause verbunden ist, bevor man z.B. ins Internet geht oder seine im VPN "lokalen" Dienst nutzt?

2. Ich weiß nicht was ich von ULA halten soll. Ist denn eine ULA überhaupt notwendig, wenn ich die LLA im lokalen Netz verwenden kann und die GUA von extern?
 c) - OPNsense-DynDNS den Dienst "xyz.alexanderb.de mit der per assistertem SLAAC GUA bei Hetzner eintragen funktioniert bei mir schon einwandfrei. Das ist doch eigentlich die beste Lösung, oder?

4. die Statistiken von pihole gefallen mir aber besser als Unbound und meine Filterlisten sind in pihole irgendwie schöner eingebunden, daher wollte ich den als erstes verwenden.
Ein Problem was ich da aber habe ist, dass ich nicht sehe welche Hosts da anfragen stellen, sondern nur die IP von OPNsense sehe ich da. Gibt es dafür Lösungen? Steht nicht in der DNS Nachricht, welcher Host das anfragt?

6. Das muss ich mir auch noch genauer ansehen.

7. Ist Wireguard Road Warrior Setup ein zero knowledge system? Ich hab mich da noch nicht eingelesen, aber weiß schon, dass ich bei VPN, nicht von einem externen Dienstleister der irgendeine knowledge hat, vertrauen darf.

Hallo zusammen,

das ist jetzt keine spezifische OPNsense Frage, aber es ist bestimmt ein Netzwerktechniker hier, der sich im Detail auskennt.

Mein Netz ist wie folgt aufgebaut

 WAN / Internet
            :
            :
            :
      .-----+-----.
      |  Modem    |
      '-----+-----'
            |
        WAN | PPPoe- + DHCPv6-Einwahl
            |
      .-----+------.     
      |  OPNsense  +
      '-----+------'
            |
            |  Netz 1        .----------------------.
            |----------------+ Name: Infrastruktur  | - Hier auch Pihole drunter
            |  192.168.10.1  '----------------------'
            | 
            |
            |
            |  Netz 2        .----------------------.
            |----------------+ Name: Services       | - Services die lokal und aus dem Internet erreichbar sein sollen
            |  192.168.20.1  '----------------------'
            |  IPv6 (LLA + GUA)
            |
            |
            |  Netz 3        .----------------------.
            |----------------+ Name: User           | - Lokale Nutzer
            |  192.168.30.1  '----------------------'
            |  IPv6 (LLA + GUA)
            |
            |
            |---> Noch viele andere Netze
            |

Da ich eine Internet-Adresse bei Hetzner gekauft habe, möchte ich diese im DNS Namenssystem gerne verwenden. Nennen wir diese einmal AlexanderB.de.

Fragen:

1. Kann ich, wenn lokal nach Domain gefragt wird, diese angeben?
   also dass ich zu OPNsense unter Infrastruktur (oder auch den anderen Gatewayadressen) z.B. mit opnsense.alexanderb.de komme.
   Und zum OpenMediavault was z.B. auf der 192.168.20.20 liegt unter Services liegt unter omv.alexanderb.de

   Ist das die Standardvorgehensweise wenn man eine Domain besitzt?
   Oder sollte man noch eine Subdomain hinzufügen um eine Trennung der Verbindung von außerhalb und innerhalb zu haben?
   Also omv.home.AlexanderB.de -> für Verbindungen aus dem lokalen Netz
   Und  omv.AlexanderB.de -> für Verbindungen aus dem Internet?
   Geht das, macht das Sinn? Aus Gründen der Sicherheit und Trennung?
   
   Wie geht man da richtig vor und gibts das überhaupt was ich mir da ausgedacht habe?
   Die Internetseite, von einem lokalen Wordpress-Server (192.168.20.47), soll dann mit der subdomain www.alexanderb.de erreichbar sein.

2. Wie trage ich reine IPv6 Adressen in mein lokales DNS ein? Die per SLAAC bezogene GUA ändert sich ja. Muss ich dann lokal nur die LLA eintragen und global mit DynDNS diese Adresse an Hetzner ins DNS weitergeben, damit Hetzner diese dann richtig global auflösen kann?

   Dann habe ich zwei DNS Register, eins lokal im pihole und eins bei Hetzner für global. Ist das der richtige Weg, oder geht das besser?

3. Kann ich meinen pihole (192.168.10.68), allen Teilnehmern so als DNS mitteilen, oder ist der Standardweg, dass man das Gateway mitteilt und dieses leitet die Anfragen an pihole weiter?
4. Wird es Port-Konflikte geben, wenn ich Unbound in der OPNsense als Upstreamserver dem pihole mitteile? Wie konfiguriert man die Ports dann richtig?
5. Und vor allem wie geht das dann mit IPv6? mDNS hatte ich am Rande mal gehört.
6. Verstehen dann alle Dienste, wie z.B. SMB das DNS? Also reicht es dann den Namen vom OpenMediaVault-Server einzutragen?

7. Vielleicht etwas Off-Topic, aber wie erreiche ich es, dass mein Handy den Weg ins Internet über meinen pihole zu Hause macht? Sodass ich mobil auch meine Blocklisten und meine DNS Einträge, sowie mein lokales Netz erreichen kann?

Ich weiß, VPN ist dann auch notwendig und das muss ich noch angehen. Das bedeutet, das ganze DNS System muss auch unter VPN Bedingungen funktionieren.

Die Erreichbarkeit von extern, soll nur mit IPv6 ermöglicht werden, da das die einfachste Variante ohne zusätzliche Dienste ist. IPv4 ist bei mir hinter CG-NAT.

Schade, selbst mit der neuen Version und meiner Konfiguration ist der Bug nicht behoben.
Das heißt, kein sequenzielles Update, sondern ein statisches.
Klasse, nun darf ich dann doch meine gesamte Konfiguration komplett neu per Hand aufsetzen. Oder ich bearbeite das Backup, aber auf ein korrektes Einspielen der Konfiguration ist ja leider kein Verlass, somit ist das eher die schlechtere Idee.

Also alles was nicht explizit auf die Firewall darf, ist bereits verboten indem dafür keine Regel existiert.
Bis auf die automatischen Regeln, hast du im Auslieferzustand keine Freigaben in irgendeiner Richtung und Schnittstelle.

Das bedeutet, jeglicher Traffic (bis auf der, der bereits durch die automatischen Regeln erlaubt ist), den du irgendwann einmal freigeben willst, dafür musst du spezielle eigene Interface Regeln erstellen.

Und du wirst sicher nicht unbeabsichtigt mehr freigeben, als was für den jeweiligen Dienst, den du freigeben möchtest, notwendig ist, oder?

Hi meyergru,

ja kein Ding, verstehe schon was du meinst und ich bin mir diesbezüglich vollständig im Klaren.

Wie ich auch schon Herrn Hausen erklären musste wie SW-Entwicklung geht, kann ich dir hier auch versichern, dass es nicht die Komplexität der OPNsense ist, die mich überfordert. Das aktuelle Problem ist einfach schlechte Programmierung. Und das ist das was mich überfordert, weil ich neben den vielen anderen Projekten, sicher nicht noch hier einsteige und den Leute erkläre wie man es richtig macht.

Ach hör mir mit KI auf, das ist das letzte was die Menschheit gerade noch gebraucht hat.

Ich setze jetzt einfach alles neu auf und muss eben bei OPNsense doch mit so einigen kleinen Softwarefehlern rechnen. Thats life.
P.S. Schön auf jeden Fall, dass der Bug im Installer der neusten Version bezüglich UFS behoben ist. Das ist doch schon ein Lichtblick :)

Was willst du mit dieser Regel erreichen?

Es scheint mir so, als wenn man wirklich viel Hand anlegen muss bei OPNsense.
Die Backup-Strategie muss dann also jede kleinste Konfigurationsänderung plotten, denn bei Bedarf muss man wer weiß wie weit zurück und dann muss man natürlich wieder alle Änderungen durchführen die durch den Rollback verloren gegangen sind.

Nicht zu unterschätzen das Risiko, dass es nach dem Rollback und der erneuten Konfiguration trotzdem nicht funktioniert.

Ein simpler DHCPv4, nicht produktionsreif. Traurig

So, jetzt hab ich die Kiste auf Werkseinstellungen zurückgesetzt und meine Konfiguration eingespielt.

Leider immer noch der Bug drin.

Kann ich also auch die Sicherungen der Konfigurationen wegschmeißen.

Toll, lol

Ich hab das os-firwall-legacy plugin wieder deinstalliert, weil nichts zum export vorhanden ist und der Migrationsassistent nur ein schwarzer Bildschirm ist.

Ja die Schnittstellen haben ihren DHCP Bereich.

Soweit ich gelesen habe ist "DNSmasq DNS & DHCP" das Leichtgewicht und der Rest für sehr viele Clients.
Ich habe aber keine tausende Teilnehmer, daher benötige ich nichts großes.

Ich weiß ehrlich gesagt nicht genau was ich jetzt mache. Das nervt mich übelst, denn ohne DHCP auf der Schnittstelle komme ich mit meinen anderen Aufgaben auch nicht weiter.

Ich weiß jetzt jedenfalls, dass das Teil "DNSmasq DNS & DHCP" eine Macke hat und da muss ich mir was überlegen.

Danke

Gut das man Fehler der Technik immer auf die DAUs schieben kann. Sehe ich komplett anders. Wenn der Programmierer es dem DAU ermöglicht, etwas zu konfigurieren, was nicht im Scope liegt, dann liegt das Problem an schlechter Programmierung. So habe ich es jedenfalls gelernt.

Also ich hab Testweise mit "DNSmasq DNS & DHCP" rumgespielt.
Alle Schnittstellen entfernt und das Häkchen bei "DHCP-Firewall-Regeln registrieren" entfernt.
Siehe da, "DNSmasq DNS & DHCP" hat die automatischen Regeln in der Firewall entfernt.
Jetzt hab ich wieder alle Schnittstellen aktiviert und das Häkchen  bei "DHCP-Firewall-Regeln registrieren" wieder gesetzt.
Siehe da, "DNSmasq DNS & DHCP" hat wieder automatische Regeln in der Firewall hinzugefügt.

Was mich jetzt aber wundert ist, dass "DNSmasq DNS & DHCP" wieder nur bei der Hälfte der Schnittstellen in der Firewall die automatischen Regeln hinzugefügt hat und bei der anderen Hälfte nicht.


Wie meinst du eingeschaltet? Also unter "DNSmasq DNS & DHCP" in den Einstellungen die Häkchen auf den Schnittstellen, ja.

Ich merke auch gerade, die Hälfte meiner Schnittstellen hat die automatischen Regeln des DHCP und die andere Hälfte nicht.

Ich bräuchte doch im Grunde nur die Möglichkeit, dass "DNSmasq DNS & DHCP" alle Regeln einmal neu erstellt. Und falls es schon so eine Regel auf der Schnittstelle gibt, soll "DNSmasq DNS & DHCP" diese Regeln nicht erzeugen, sodass keine Duplikate entstehen.

Aber die Frage die sich mir dann stellt ist, wie viele versteckte Bugs mich mit OPNsense in Zukunft noch quälen werden und ob ich alle Konfigurationsänderungen handschriftlich mir notieren muss, falls ich mal ein 1 Jahr altes Backup einspielen muss.

Es gibt nichts zu exportieren, nur "Regeln aus der Automatisierung" und "automatisch generierte Regeln". Der Migrationsassitent ist auch einfach ein schwarzer Bildschirm.

Es sind gar keine Regeln mehr vorhanden, die ich exportieren könnte. Vor der Migration gab es keine "Regeln aus der Automatisierung".
Ja ich sehe, bei mir ist wieder alles schief gegangen und nun ist die Kiste so verbuggt.
komplett neu aufsetzen, na prima. Und wenn ich dann meine Konfiguration von jetzt mitnehme, dann nehme ich hoffentlich nicht die ganzen Bugs mit.

Ich weiß nicht warum du dir so sicher bist, dass dieses Problem, dass die Clients auf der 2ten Schnittstelle keine IP bekommen, nicht an den automatischen Regeln liegt. Obwohl die Schnittstelle wo alles funktioniert, die automatischen Regeln vom "DNSmasq DNS & DHCP", wie auf dem Bild gezeigt, drin hat, und die 2te Schnittstelle, die exakt gleich mit "DNSmasq DNS & DHCP" konfiguriert ist, eben diese Regeln für den Zugang zum DHCP NICHT drin hat.
Im Grunde würde ein Neuaufsetzen genau dieses Problem nicht lösen.

Das ist echt ne mittelschwere Katastrophe. Na mal schauen wie ich da wieder raus komme.

Dann erstmal Danke an alle die hier mir geholfen haben :)

Also, ja ich habe den Migrationsassistenten durchgearbeitet. Aber ich schätze da hat was nicht funktioniert, denn bei der Hälfte war alles weg und auch die Beschreibung. Da dachte ich, huch, das ging aber schnell, ich war noch gar nicht fertig mit lesen.

Jetzt mit dem os-firewall-legacy, führt mich der Migrations Assistent zu einem schwarzen Bildschirm. Schick. Naja, dann geh ich mal auf die Suche was ich noch alles da machen muss. oh mei oh mei.

@patient0
Sorry. Nein nein, das sind zwei unterschiedliche Schnittstellen/VLANs. Eine funktioniert, die andere nicht. Fehler ist höchstwahrscheinlich wegen dem Migrationsassitenten passiert, da einfach die automatischen Regeln fehlen. DNSmasq DNS & DHCP nutze ich und die neuste Version von OPNsense und ja der Haken ist dort gesetzt, dass der DHCP automatisch Firewallregeln zu der entsprechenden Schnittstelle erstellen soll (Was aber nicht funktioniert, so wie ich festgestellt habe).