Messages

Hi zusammen,

habe bereits mehrere Varianten gesehen um für die jeweiligen Interfaces eine "erlaube alles außer private IP-Adressen"-Regel zu erstellen.

Nur eine Allow-Regel mit invertiertem RFC1918-Destination-Alias zu erstellen würde doch nur IPV4-Verbindungen blocken, oder?

Ich habe aktuell eine IPv4+IPv6-Regel mit invertiertem Destination-Alias, das alle meine Networks enthält, also z. B. __lan_network, __opt1_network_, ___opt2_network, usw. (WAN- und Loop-Interface müssen hier nicht rein, oder?).

Die einzige Gefahr, die ich darin sehe ist, dass sich die Rule nicht bei einem neu hinzukommenden Interface automatisch aktualisiert. Gibt es auch Lösungen die absolut failsafe sind?

Danke :-D

Hast du z oder y oder Sonderzeichen im Passwort und es ist ggf. nicht das deutsche Tastaturlayout eingestellt?

Hallo,

ich habe inzwischen mein OPNSense zufriedenstellend aufgesetzt und kümmere mich nun um die Trennung meiner VLANs.

Ich möchte meine gesamten Amazon-Geräte (Echos und Fire-TV-Sticks) ins IoT-VLAN packen, allerdings soll weiterhin ein Streaming von User- und Guest-VLAN möglich sein.

Ich habe das mDNS-Repeater-Plugin bereits installiert und alle 3 VLANs eingestellt und testweise alle Verbindungen aus dem User-VLAN auf den Fire-TV-Stick erlaubt (protocols: any, ports: any).

Folgendes funktioniert:
Starte ich die Youtube-App auf dem Stick, wird der Fire-TV-Stick auf dem Smartphone in der Youtube App angezeigt und das Streaming ist möglich. Vorher, im gleichen VLAN, musste ich die App auf dem Fernseher gar nicht starten, aber damit könnte ich leben.

Allerdings funktionieren sonst keine Streaming-Dienste. Prime Video findet den Fire-TV-Stick, zeigt mir nach Auswahl des Sticks sogar an, dass das Streaming auf dem Fernseher/Stick läuft, dem ist aber nicht so.

Ich habe testweise in der Firewall auch alle Verbindungen vom Stick zum User-VLAN zugelassen, das brachte aber keine Abhilfe.

Gibt's hier einen Trick? wäre ein externer Avahi-Server besser als der mDNS-Repeater oder brauche ich noch irgendetwas anderes?

Klasse, Danke euch. Schön langsam wird's.

Jetzt muss ich mich um eine logische VLAN-Trennung kümmern, da bisher alles noch in einem läuft.
(Schon faszinierend, womit man sich beschäftigt, nur weil man das Thema interessant findet - ob es im Heimnetzwerk wirklich notwendig ist, wage ich sehr zu bezweifeln, aber man lernt viel. :-D )

Habe ein Problem mit dem Streaming auf z. B. den Fire-TV-Stick, aber hierfür mache ich der Übersichtlichkeit halber einen neuen Thread auf.

Abend/Morgen,

mein Problem scheint wohl nicht zu sein, dass ein DNS vom ISP verwendet wird, sondern dass Unbound alle IPs eines Clients auflöst und da OPNSense ja auf allen Interfaces lauscht, werden mir dessen IPs von allen 7 VLANs mitgeteilt. Wenn ich im Browser dann opnsense über den Hostnamen aufrufe, wählt er zufällig eine IP und die Firewall blockt den Zugriff entsprechend, wenn es nicht das VLAN ist, in dem ich mich befinde.

ein "nslookup opnsense" ergibt bei mir 14 IPs, 7 IPv4 und 7 IPv6.

Gibt es eine Lösung hierfür?

Scheint zu klappen. Die Geräte erhalten gar keinen IPV6-DNS mehr, aber die Auflösung von ipv6 Domains (z. B. Google.de) klappt problemlos.

Auch die Smartphones verbinden sich jetzt mit den Omada APs innerhalb von Sekunden und haben auch ipv6-Konnektivität.

Danke euch :)

Für SLAAC muss ich quasi RAs nutzen, diese auf "unmanaged" stellen und dort einfach keinen DNS eintragen?

Falls ja, werde ich das mal probieren und prüfen ob die Omada APs dann keine Probleme mehr machen.

Alle meine Geräte sind IPv4-fähig bzw. Dual-Stack.

Heißt ein ausschließlicher DNS über IPV4, dass die Geräte keinen Internetzugriff per IPV6 haben oder kann man das entsprechend in OPNSense konfigurieren?

Ich weiß, dass ich IPV6 wahrscheinlich komplett deaktivieren könnte, aber irgendwie wehre ich mich dagegen... Inzwischen sind manche Dienste ja nur noch per IPv6 erreichbar (ein Beispiel das mir dazu gerade einfällt, das mich zwar nicht akut betrifft, wäre ein Fernzugriff auf eine Fritzbox über deren MyFritz!Net-Server).

Abend,

habe inzwischen EAP-APs im Einsatz und diese scheinen wohl ein Problem mit Router Advertisement zu haben. Wenn sich clients erstmalig oder nach längerer Zeit wieder verbinden, ggf. auch noch in Kombination mit Randomized MACs, dauert es 10 bis 20 Sekunden, bis der IPv6-DNS zugewiesen ist.

Alles was ich bisher zu Telekom DSL und WAN-Konfiguration gefunden habe, hat darauf abgezielt einfach nur Track WAN einzustellen und nur ein Prefix per DHCPv6 zu beziehen.

Ich habe das RA jetzt nochmal rausgenommen und komischerweise funktioniert nun doch noch alles (also vor allem die interne Namensauflösung). Entweder der Windows PC fängt erst später zu spinnen an, oder es lag am Reboot von PC und OPNSense, nachdem ich die Einstellungen entsprechend gesetzt habe.

Edit: Konnte es gerade reproduzieren. Die DNS-Probleme treten auf, wenn ich OPNSense reboote, aber den Windows PC nicht bzw. den Ethernet-Adapter nicht resette. Nach einem Neustart/Reset funktioniert der DNS wieder.

Moin,

stehe vor folgender Herausforderung:

Mein gesamtes System läuft nun zufriedenstellend und ist folgendermaßen aufgebaut:

- OPNsense-Router (nur ein LAN-Port) (Trunk Port 1)
- Proxmox Server (Trunk Port 5)
- TP-Link SG2008P Switch
- Telekom DSL Modem (Port 2 - Tagged VLAN 1+7)

Im Proxmox werden die VLANs den jeweiligen VMs/LXCs zugeordnet.

Nun habe ich mir dort einen Omada Controller installiert und möchte den bereits eingerichteten Switch adoptieren. Leider wird sich dieser beim adoptieren ja zurücksetzen, womit ich dann auch keinen Zugriff mehr auf das Management-Vlan des Controllers haben werde.

Gibt es irgendeinen Trick (außer einen zweiten Switch zu verwenden)?

Hätte überlegt, übergangsweise alle anderen VMs herunterzufahren und Proxmox ein untagged VLAN1 zuzuweisen, auf welchem dann ja auch der Controller liegt. Anschließend den switch adoptieren, der dann ja auch standardmäßig auf VLAN1 liegen sollte und anschließend die Konfiguration der VLANs wieder vorzunehmen, inkl. Management VLAN.

Aber vielleicht geht's auch einfacher?

Danke :)

In jedem einzelnen Tutorial das ich mir angesehen habe und auch im OPNsense Wiki wurde auf diesen Punkt nicht eingegangen bzw. sogar erwähnt, dass keine weiteren Konfigurationen diesbezüglich notwendig sind.

Dachte, dass die Option "Allow DNS server list to be overridden by DHCP/PPP on WAN is unchecked." reichen würde.

Deshalb wollte ich mich nochmal vergewissern, dass ich nichts falsch gemacht habe. :D

Dankeschön 😇

Hi,

habe OPNSense mit einem DSL-Modem am laufen. Bisher hat eigentlich alles gut geklappt, allerdings wechselt mein Windows-PC ständig den DNS, was zu fehlerhafter oder langsamer Hostnamenauflösung intern führt. Ich denke das Problem betrifft alle IPv6-fähigen Geräte.

nslookup gibt dann *****************(ipv6-adresse die bei allen Interfaces angezeigt wird)*******.dip0.t-ipconnect.de aus.

Hier die WAN-Config:

You cannot view this attachment.

Hier die Konfig eines VLANS:
You cannot view this attachment.


So sieht der nslookup aus:

C:\Users\skald>nslookup google.de
Server:  p200300e****************.dip0.t-ipconnect.de
Address:  2003:eb:cf31:***********************

Nicht autorisierende Antwort:
Name:    google.de
Addresses:  2a00:1450:4016:808::2003
          142.251.36.163


Habe in einem anderen Beitrag über Router Advertisements gelesen, aber ich bin mir nicht ganz sicher, ob das nicht doch nur eine Notlösung ist:

You cannot view this attachment.

Damit funktioniert die Auflösung von lokalen Hostnamen immer.

Mache ich hier evtl. etwas falsch?

Du lässt die andere Instanz währenddessen aber nicht laufen oder?

Falls ja, musst du unter Destination Port einen anderen wählen. Z. B. 8124.

Den redirect Port musst du auf 443 ändern, du möchtest dich ja nicht von außerhalb über den http Port (8123) verbinden, den blockt nginx eigentlich bzw. leitet dich auf 443 um, wenn die Verbindung nicht aus dem lokalen Subnet erfolgt. Das klappt natürlich nicht, wenn der 443 nicht freigegeben ist.

Wo siehst du das mit "Externer Zugriff deaktiviert"?

Poste mal einen Screenshot von der port forwarding rule. Ich habe eine port forwarding rule, die port 8123 extern auf Port 443 der Home assistant VM weiterleitet.

Port 443 ist im NGINX SSL Proxy Addon konfiguriert. (siehe Video unten).

Das mit dem deaktiviertem Fernzugriff im Homeassistant ist wahrscheinlich die NABU Casa cloud, das wäre ja die Alternative zum Port forwarding.

Unbedingt auch ip ban nach mehreren fehlerhaften Logins konfigurieren.

https://youtu.be/UZozmfh8QY8?si=7-h7cPnF7dnSaJ1L

Das tutorial kann ich dir ans Herz legen, dort wird auch gleich gezeigt, wie du dir das Letsencrypt Addon installierst um eine sicherer Verbindung ohne lästige Zertifikatsfehlermeldung zu ermöglichen.

Das ist langfristig auch der Plan. Die APs sollen dann von Unifi oder TP-Link kommen (Letzteres würde sich evtl. anbieten, da mein Switch bereits ein Omada-Switch ist).

Auch die IoT-Geräte sollen isoliert werden, hier muss ich mich aber einlesen, wie ich das alles trenne, sodass es nachher noch funktioniert (MQTT, APIs über verschieden VLANS, etc.). Gerade denke ich mir aber, dass es evtl. mehr Sinn macht, den Home-Assistant auch einfach ins IoT-Netzwerk zu den Smart-Relays, Amazon Echos usw. zu schieben und nur intern eine HTTP-Portfreigabe auf das Trusted-VLAN zu machen, um per App und PC Zugriff zu haben. Dann wäre ja wieder alles VLAN-intern, ohne sicherheitsrelevante Geräte im selben VLAN.

Dann wäre auch die HTTPS-Port-Freigabe von WAN auf das Home Assistant Webinterface auch nicht mehr so tragisch, denn wenn ein Hacker mir tatsächlich mal die Christbaumbeleuchtung ein- und ausschaltet wäre mir das herzlich egal, kritische Smart-Home-Geräte habe ich (noch) nicht. Wobei der Home Assistant sowieso per Fail2Ban und 2FA abgesichert ist und ich da eher optimistisch bin, dass sich kaum einer den Aufwand macht, dort einzudringen.

Smartphones ins IoT finde ich persönlich jetzt z. B. kritisch, da sich auf diesem ja auch etliche sensible Daten befinden (Onlinebanking, etc.).