1
German - Deutsch / Re: Kea DHCP - Subnetze auf Interfaces verteilen?
« on: May 06, 2024, 05:19:36 pm »
Super, Danke!
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
German - Deutsch / [GELÖST] Kea DHCP - Subnetze auf Interfaces verteilen?
« on: April 30, 2024, 07:45:58 pm »
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?
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?
3
German - Deutsch / Re: PortForwarding, NAT Reflection - Rückweg von intern funktioniert nicht
« on: April 29, 2024, 01:07:40 pm »
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
Firewall -> Settings -> Advanced -> Automatic outbound NAT for Reflection
4
German - Deutsch / [SOLVED] PortForwarding, NAT Reflection - Rückweg von intern funktioniert nicht
« on: April 28, 2024, 06:27:57 pm »
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?
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?
5
Web Proxy Filtering and Caching / Re: nginx: Basic Auth with crypted password
« on: August 19, 2023, 11:41:52 am »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.
6
Web Proxy Filtering and Caching / nginx: Basic Auth with crypted password
« on: August 17, 2023, 09:32:50 pm »
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:
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.
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]
$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.
7
German - Deutsch / Re: Apple Homekit Zentrale - IPv6 intern/extern blocken bzw. steuern?
« on: January 24, 2022, 05:12:58 pm »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.
8
German - Deutsch / Re: Apple Homekit Zentrale - IPv6 intern/extern blocken bzw. steuern?
« on: January 24, 2022, 10:58:20 am »
Rein zum technischen Verständnis hier noch ein paar Anmerkungen:
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.
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.
Was meinst du mit "das alles" ?
Du kannst mit OPNsense:
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.
Quote
> 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.
Quote
> 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.
Quote
> 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.
9
German - Deutsch / Re: WAN Regel für Internet Zugriff
« on: January 19, 2022, 01:13:22 am »
> 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.
"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.
10
German - Deutsch / Re: Config Backups zu Nextcloud verschwunden
« on: January 16, 2022, 10:12:04 pm »
okay, danke. muss ich wohl übersehen haben. plugin installiert und es läuft wieder.
11
German - Deutsch / Config Backups zu Nextcloud verschwunden
« on: January 16, 2022, 11:45:44 am »
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.
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.
12
German - Deutsch / Re: Zugriff interner Server auf Public IP der Firewall funktioniert nicht
« on: June 08, 2021, 08:42:45 pm »
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.
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.
13
German - Deutsch / Re: Zugriff interner Server auf Public IP der Firewall funktioniert nicht
« on: June 02, 2021, 11:05:05 pm »
> 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.
> 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.
14
German - Deutsch / Re: Zugriff interner Server auf Public IP der Firewall funktioniert nicht
« on: June 01, 2021, 02:26:35 pm »
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.
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.
15
German - Deutsch / Re: Zugriff interner Server auf Public IP der Firewall funktioniert nicht
« on: May 31, 2021, 09:11:10 pm »
> 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.
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.