Messages

Super, Danke!

Bin ich blind oder wie funktioniert das ?
Ich kann in den Haupteinstellungen zwar die Interfaces setzen auf denen DHCP läuft.
Und ich kann auch Subnetze anlegen.
Aber ich kann keine Zuordnung der Subnetze zu Interfaces machen.
Also wie wird das gemapped?

Die Lösung für mich war, in den Einstellungen zu aktivieren, dass automatische SNAT Rules zu jeder DNAT Reflection hinzugefügt werden.

Firewall -> Settings -> Advanced -> Automatic outbound NAT for Reflection

Hi, ich schildere hier mal mein Problem, die Überschrift kann der Situation leider nicht wirklich gerecht werden.

Situation:

auf meiner Sense ist ein Port Forwarding eingerichtet:
Source: * | Dest: WAN-Address
SourcePort: * | DestPort: 443
Target: 10.0.0.6 | Target Port: 443
NAT-Reflection: Enabled

Ich habe eine Domain home.domain.de, dessen A Record auf die Public IP der Sense zeigt.
Port Forwarding von extern funktioniert wunderbar. Von intern klappt es leider nicht.

Durch das Aktivieren der NAT Reflection sehe ich auf dem Target-Server, dass Traffic, den ich im LAN an einem Computer erzeuge, durch kommt. Sprich: Lokales Aufrufen von https://home.domain.de kommt laut tcpdump am Zielserver an. Problem ist, dass der Rückweg leider nicht funktioniert. Wie gesagt, von extern alles kein Problem, nur intern klappt nicht.
Ich sehe in den Logs aber auch nicht, dass die Firewall etwas blockt. Habe ich etwas vergessen oder hat jemand eine Idee wie ich am besten weiter das Problem debuggen kann?

I would discuss with the maintainer the possibility of storing the hash in the config (instead of plain password)

This would also have been my expectation in the first place. Best solution would be allowing to select the exact type of password (plain, bcrypt, whatsoever) when creating a credential. On submit it could then just use htpasswd to generate all stuff and storing that in config.

Hey,

I want to use Basic Authentication without storing the credential's passwords in cleartext.
My first shot was to put a valid encrypted string into the password field like:

Code Select Expand


$apr1$CvlM9gn1$twwsR5.3jglwaFCIv1qKf/

# disclaimer: of course not the used passwort ;-)


but that did not work.

Does it work and I'm just doing something wrong? e.g. using a not supported cipher/hash algorithm

As a possible alternative solution I could use OPNsense integrated accounts using advanced acls. But then I would want to somehow decide WHICH of the local users can access.

Thank you.

Um zur Ursprungsfrage zu kommen, da ich da vorgestern auch drüber gestolpert bin:

AppleTV annonciert sich als Router, und annonciert ein ULA-Prefix damit Geräte im gleichen VLAN per IPv6 kommunizieren können. Das ist zunächst mal nicht schlimm.

Ein paar Links:
https://de.wikipedia.org/wiki/IPv6#Unique_Local_Unicast
https://de.wikipedia.org/wiki/IPv6#Autokonfiguration

Wichtig ist es, an dem Router der den Gateway nach aussen darstellt in "Router Advertisements" die "Router Priority" auf "high" zu stellen.

Stimmt. Irgendwie alles +1 genommen. Habs editiert.

Rein zum technischen Verständnis hier noch ein paar Anmerkungen:

> Wenn man im IPv4 Bereich dann VLANs baut

VLANs befinden sich im Layer 2 des Schichtenmodells
IP (sowohl v4 als auch v6) befinden sich auf Layer 3.

Es laufen also dann beide IP Protokolle über das selbe VLAN.

> und auch gewisse Dinge blockt/nicht erlaubt, dann klappt der Homepod/Apple TV immer noch, weil die ja irgendwie IPv6 ausstrahlen

OPNsense blockt eh alles, was du nicht explizit erlaubst. Ausnahmen sind Anti-Aussperregeln, damit du dich nicht so verkonfigurierst, dass du die Sense nicht mehr erreichen kannst.

Die Homekit-Geräte benötigen Internetzugang (zu iCloud) für Fernsteuerung/Fernabfrage. Lokal bei dir zu hause reicht es, wenn die Geräte im selben Subnetz liegen. Also wenn du VLANs hast, dann drauf achten, dass alle Home Geräte auch im selben VLAN sind.

Auch "strahlen" die Geräte kein IPv6 aus. IPv6 ist kein eigenes Layer 2 Übertragungsmedium. IPv6 läuft ganz normal entweder über LAN-Kabel, oder WLAN.

> Keine Ahnung wie das genau alles abläuft - aber besteht denn überhaupt mit OPNsense die Möglichkeit das alles zu verhindern, bzw. zu regulieren, oder ist man da machtlos?

Was meinst du mit "das alles" ?
Du kannst mit OPNsense:

• verhindern, dass deine Geräte ins Internet kommunizieren (in fast jeder beliebigen Granularität. Auch: Darf überall hin, außer zu Apple Servern als Beispiel
• die Kommunikation der Geräte intern beeinflussen (Beispiel: Die IP, die der Sohnemann kriegt, darf nicht die Rolladen steuern - aber das wäre schon ein komplexes Szenario bei dem man Hintergrundwissen über die verwendeten Adressen/Ports usw. benötigt

Also im Prinzip kannst du da sehr sehr viel regulieren. Man muss halt konkret planen WAS und sich dann an die technische Umsetzung machen.

Du solltest dir die Frage, WAS du genau erreichen willst erstmal ohne Zuhilfenahme von technischen Begriffen und potentiellen Lösungen im Kopf vorstellen.

> Wen ich in der DMZ Regel einstelle, das diese als Ziel nur WAN haben soll, funktioniert der Internet Zugriff nicht. Ich kann WAN IP oder WAN Netzwerk auswählen, macht keinen Unterschied.

"WAN IP" matcht auf deine öffentlichen IPs am WAN Interface
"WAN Netzwerk" matcht auf alle Netze, zu denen deine WAN IPs gehören.

Wenn du also nicht gerade IP Blöcke zugewiesen bekommst, sondern ne einzelne IP vom Internetprovider, dann wird das WAN-Netz wohl IP-Adresse/32 sein, was effektiv der "WAN IP" gleicht.

Mit Ziel "WAN-Netz" sagst du also nicht, dass das Ziel jede IP des öffentlichen Raums ist.

XXX-IP und XXX-Netz funktionieren bei einem "WAN" Interface genauso, wie bei allen anderen Netzen. Es werden keine Entscheidungen anhand des Namens mit "WAN" getroffen. Das WAN Interface könnte auch HASE heißen. Mit dem Namen WAN ist keine Logik verbunden.

Ich behelfe mir stattdessen mit einem Alias, der alle RFC-1918-Netze beinhaltet, alle localhost Adressen und sobald nötig andere nichtöffentliche Adressbereiche. Dann stelle ich ein, dass das Ziel dieser Alias ist, allerdings mit einer NICHT Verknüpfung. Effektiv sage ich ihm damit, dass das Ziel jede Adresse ist, die nicht privat ist.

okay, danke. muss ich wohl übersehen haben. plugin installiert und es läuft wieder.

Hallo,

ich hatte in meiner OPNsense ein Config Backup zu meiner nextcloud konfiguriert.
Es lief jahrelang problemlos. Heute hätte ich mal eins gebraucht. Ich hab dann erschreckend festgestellt, dass keine neuen Backups seit Monaten erstellt wurden.
Ich musste also einen kompletten Server Snapshot wiederherstellen   :-\

Nachdem das durch war, wollte ich schauen, ob die Backup Config stimmt und habe festgestellt: Nextcloud als Backup-Ziel existiert gar nicht mehr.

Was ist denn hier passiert? Aus den Update Changelogs geht da leider nichts hervor.

Interessant, obwohl das ja auf der Hand gelegen hat, hab ich nie ganz tabula rasa mit den forwarding regeln gemacht.
Eventuell hätte das auch geholfen. Da ich mich aber mittlerweile mit der DNS Lösung angefreundet habe, habe ich jetzt auch keine Lust mehr nachträglich noch mehr zu debuggen.

> Wie hinzugefügt?
> Das ist irgendwie unklar.

Du kannst ja grundsätzlich ein Port Forwarding auf mehreren Interfaces zugleich einstellen (multi select).
nachdem meine regel nun an den Interfaces WAN und WEB war, hat es geklappt.

Okay, die Screenshots sagen eigentlich nur folgendes aus:

Ein Port Forwarding an der WAN Schnittstelle mit Ziel "This Firewall", Port 443, weitergeleitet an den Proxy auf Port 443.
Dann hab ich einfach die WEB Schnittstelle hinzugefügt. Das ist das Interface, mit dem die Sense im Webserver-Netz ist.
Nach dem Hinzufügen des WEB Netzes zu dieser Forwardingregel ging es auf ein mal. Wenn ich NUR das WAN Netz drin hatte, ging es trotz Reflection nicht.

Ich habe mich jetzt doch für den DNS Override via Unbound entschieden. Einfach weil es sauberer und durchsichtiger ist, wie du schon sagst.

Danke auf jeden Fall für deinen Input.

> Sagen wir lieber mal: 203.0.113.123/24  (--> https://datatracker.ietf.org/doc/html/rfc5735, IPv4 Doku Netze)

Geh ich konform mit.

> Bleibt nicht hängen, aber ist nicht definiert, wenn dein Port Forwarding/Redirection keine "NAT Reflection" aktiv hat. Ansonsten ist die Weiterleitung NUR von WAN AUS ANkommend erlaubt, aber nicht von innen. Daher passiert auch nichts.

Seltsam. Ich habe alle möglichen Kombinationen mit den NAT Reflection Einstellungen ausprobiert und nichts führte zum Ergebnis. Aber eventuell haben mir da weitere Firewallregeln gefehlt ?!?

Ich habe einen Weg gefunden, der bei mir funktioniert. In Anhang 1 meine DNAT Regel vorher, in Anhang 2 nachher.
Ich weiß allerdings auch nicht genau wie "optimal" das ist.

> Wenn die auf die Domain gehen - was sie sollten(!)

Tun sie!

> dann geht das über einfachen DNS Rewrite bzw. DNS Override in der Sense -> besserer Weg und direkter, weil dann der Host gleich mit sich selbst spricht.

Ja, das ist durchaus ein bequemer und auch sauberer Weg. Nur dass in meinem Fall der Web-Host mit dem Proxy sprechen muss, nicht sich selbst, da der Proxy SSL terminiert und der webserver nicht.

> Warum will man das vermeiden

Ganz einfach, weil dann gewisse DNS Informationen an verschiedenen Stellen stehen und man die bei Änderungen dann immer mit bedenken muss. Ich bin generell ein Freund davon an so wenig Baustellen wie möglich zu arbeiten.