Beiträge von ceLeXo

Zitat von DoPe

Wie die UDMs das Hair Pinning realisieren weiß ich nicht. Bei den USGs und Edge Routern musste man zumindest bei mehreren LANs immer etwas nachhelfen. Da war das ganze eine Mischung aus Source und Destination NAT und ich meine der Traffic ging überhaupt nicht über das WAN Interface und wurde direkt in das entsprechende Ziel Netz umgebogen.

Ich würde einfach mal versuchen die Inter-VLAN-Blockierung etwas aufzuweichen und zumindest den Traffic den Du auch aus dem Internet durch die Portfreigaben zulässt, auch aus den benötigten VLANs zum Ziel (Proxy)) zu erlauben. Den Rückweg nicht vergessen!

Das habe ich bereits getan - dachte ich zumindest.

Ich hab mit Deinem Input einen anderen Ansatz verfolgt und diesmal die entsprechenden Geräte (Mobile Geräte, NAS mit Diensten und RPi mit Proxy) allen je eine Verbindung direkt zu den anderen Geräten untereinander erlaubt (die VLAN-Struktur ignoriert und auch zwischen den Geräten, welche sich im selben VLAN befinden, eine entsprechende Regel erstellt).

Bisher hatte ich den jeweiligen Geräten einfach den Zugriff auf das gesamte fremde VLAN gewährt und für das eigene VLAN keine Regel erstellt, was bis dato jedoch anscheinend nie geklappt hat.

Ich muss jedoch nun zuerst einmal die Firewall-Regeln sauber aufräumen und analysieren, mit welchen Regeln es funktioniert und welche obsolet sind.

Jedenfalls vielen Dank DoPe ich bin nun schon ziemlich nah an die Zielstrecke gekommen

Edit:

Folgendes habe ich nun noch eruieren können.

> Erlaubenregel für Mobile Devices (VLAN3 Tech) Traffic zu komplettem VLAN 1 Default
--> Verbindung zu NAS-Diensten (Fotos, Musik, Bitwarden) via DynDNS/Proxy schlägt fehl

--> Verbindung zu NAS-Diensten (Fotos, Musik, Bitwarden) via direkter IP oder Hostname funktioniert

> Erlaubenregel für Mobile Devices (VLAN3 Tech) Traffic direkt auf NAS (VLAN 1 Default)

--> Verbindung zu NAS-Diensten (Fotos, Musik, Bitwarden) via DynDNS/Proxy funktioniert

--> Verbindung zu NAS-Diensten (Fotos, Musik, Bitwarden) via direkter IP oder Hostname funktioniert

Weiss jemand, warum oben beschriebenes Verhalten auftritt? Mir erschliesst sich die Logik dahinter noch nicht...

Der Proxymanager sowie die DynDNS sind nicht Bestandteil dieser testweise angepassten Regel, sondern nur Handy, NAS bzw. VLAN1.

Zitat von swag

Keine Ahnung ob es relevant sein könnte aber hast Du IPv6 aktiv ? Frage mich ob in dem Fall die externe route abgekürzt wird. Stichwort Doppeltes NAT im Internetzugang bei IPv4

Meine beiden WAN-Anschlüsse haben beide die Einstellung "IPv6 deaktiviert"

Gemäss meinem Eröffnungspost habe ich kein doppeltes NAT, da ich auf ein ISP-Modem verzichten konnte und direkt mit Glasfaser auf die UDM Pro fahre.

Ich überlege mir, testweise den Proxy vom Docker im VLAN 3 neu auf den Docker im VLAN 1 umzuziehen, vielleicht würde dies bereits den von mir ungewollt blockierten Traffic vermeiden.

Vielen Dank DoPe für Deine Inputs.

Der lokale DNS wäre wohl ein Lösungsversuch, wenn ich dies nicht auf diesem Wege zum Funktionieren bringe.

Ich verstehe aktuell jedoch noch nicht, woran es scheitert.

Ja, zum Thema NAT Loopback (oder auch NAT Hairpinning) habe ich diesbezüglich auch ein wenig gelesen und recherchiert.

Anscheinend soll die UDM Pro mit der aktuellen Firmware diese Funktion einwandfrei beherrschen.

Tut es in meinem Fall eigentlich auch, wenn ich dies richtig einschätze.

Ich kann vom PC aus (VLAN 1) die DynDNS von Bitwarden aufrufen und der Dienst wird mir angezeigt. Dabei rufe ich eine externe Adresse auf und gehe ich via Gateway und via Proxy (VLAN 3) und komme ans Ziel (NAS, Docker, im VLAN 1). Daraus schlussfolgere ich, dass in diesem Fall NAT Loopback funktioniert.

Mache ich dasselbe einfach von meinem Smartphone aus (VLAN 3), der restliche Weg bleibt eigentlich derselbe, funktioniert es nur wenn ich

a) die Blockieren-Regel für allen Inter-VLAN-Traffic deaktiviere oder

b) bei aktivierter Blockieren-Regel anstelle der DynDNS direkt die lokale IP des NAS / Port des Dienstes Bitwarden angebe

Ich kann von meinem Smartphone (VLAN 3) jedoch jederzeit (egal ob Blockieren-Regel für inter-VLAN-Traffic ein oder aus ist) mein NAS (VLAN1) anpingen.

Dies macht Sinn, da ich bei Lan In eine Erlauben-Regel gesetzt habe, welche u.a. meinem Smartphone (VLAN 3) die Verbindung zum NAS (VLAN 1) erlaubt. Die Ports werden dabei nicht eingeschränkt, sie sind bei Quelle und Ziel auf "jegliche" eingestellt.

Eine gleiche Regel habe ich auch für den Proxy (VLAN 3) gesetzt, damit dieser ins VLAN 1 kommunizieren kann.

Ich schliesse daraus, dass meine Verbindung (Smartphone - DynDNS - Proxy - NAS) einen Weg nimmt, der mir nicht schlüssig ist und ich mit der Blockieren-Regel des inter-VLAN-Traffics diese Verbindung kappe.

Meine Annahme zum Trafficverlauf in meinem Problemfall:

- Smartphone VLAN 3 Aufruf einer DynDNS >

- Gateway VLAN 3 (UDM Pro) / NAT >

- www / DynDNS Client >

- meine öffentliche IP / WAN-Schnittstelle meiner UDM Pro (Gateway) >

- Proxy Manager VLAN 3 >

- NAS / Bitwarden-Dienst VLAN 1 (Ziel)

Oder habe ich da was ausser acht gelassen?

Zitat von RenWin

Nim mal ein Laptop oder PC und gehe in das VLAN 3 damit.

Mach hier nun mal ein NSLOOKUP unter Windows und schau, ob du die Adresse aufgelöst bekommst.

Wenn du den intervlan Traffic Block mal pausierst, geht es dann?

Vielen Dank für Deine Inputs!

Ergebnis zum Test mit NSLOOKUP

Wenn ich für die beiden DynDNS (Synology Fotos Dienst und Bitwarden Dienst) je ein nslookup auf meinem Laptop im WLAN Technik (VLAN3) durchführe UND inter-VLAN-Traffic Blockregel aktiviert ist, erhalte ich folgende Auflösung:

Nicht autorisierende Antwort:

Name: meine DynDNS für Bitwarden

Adress: meine aktuelle WAN-IP

Nicht autorisierende Antwort:

Name: meine DynDNS für Synology Foto

Adress: meine aktuelle WAN-IP

Ergebnis zum Test mit inter-VLAN-Traffic Blockregel aktiviert/deaktiviert

Regel aktiviert:

Bitwarden-Dienst ist nicht erreichbar

Synology-Foto-Dienst ist nicht erreichbar

Regel deaktiviert:

Bitwarden-Dienst ist erreichbar

Synology-Foto-Dienst ist erreichbar

Meine Folgefragen aus diesen Tests:

a) Der Traffic vom Laptop (oder Smartphone) verlässt folglich mein lokales Netzwerk nicht nach aussen, sondern wird intern vom Smartphone via Gateway direkt auf mein Dienst umgeleitet.

Ist diese Schlussfolgerung korrekt?

b) Für diesen Weg (Mobile Devices aus VLAN3 zu VLAN1) habe ich extra eine Erlauben-Regel VOR der Block-Regel (inter-VLAN-Traffic) erstellt, welches meinen mobilen Devices (Smartphone, Laptop) erlauben sollte, eine Verbindung von VLAN3 auf VLAN1 zu erstellen. Die getesteten mobilen Devices werden via Gateway alle mit fixen IPs versorgt und die Clients erhalten auch die vorgesehenen und in den Regeln erlaubten IP-Adressen.

Was habe ich dennoch falsch gemacht und/oder falsch überlegt?

Ich danke RenWin und razor für Euren Support!

Zitat von JakB

Ich habe von einem PC, den ich auf den gleichen Eingang des Switches gesteckt habe, in dem vorher der AP steckte, den Cloud-Key gescannt und definitiv Port 8080 als offenen Port gesehen. Lediglich Port 10001 gibts beim Cloud Key nicht. Und das ist just der Port laut Deiner freundlicherweise verlinkten Liste, der für Device dicovery genutzt wird. Ich denke, hier liegt der eine Hase im Pfeffer (zu dem zweiten Hasen komme ich gleich noch).

Ich denke jedoch nicht, dass es am Port beim Cloudy-Key gelegen hätte, wäre dieser wirklich geschlossen, so hätte der Cloud-Key auch keine anderen Geräte gefunden und nie ein Gerät einbinden können.

Zitat von JakB

Wenn ich um eine Neuanschaffung nicht herumkomme, was kann man empfehlen? Ich habe momentan bewussten Cloud-Key und ein USG, das auf WAN1 DSL und auf WAN2 LTE reinbekommt.

Ist eine etwas übewr 200,-€ Investition in den Cloud-Key Gen2+ das sezten auf einen alten Gaul?

Die Dream Machine Professional hat nur einen WAN-Port. Kann man den WAN2 über einen SFP+-Schacht mit einem entsprechenden RJ45-Modul stressfrei einbinden? Klappt da Load-Balancing mit Routing von bestimmten Netzteilnehmern fest auf einen bestimmten WAN-Port?

Klar: Mit der DMP kann ich den Cloud-Key und den USG ersetzen, jedoch ist mal eben so 400,-€ über die Theke reichen auch nicht jedermanns Sache. Daher meine Fragen-Flut.

Ich habe gerade erst von USG auf UDM Pro gewechselt, allerdings weil ich eben direkt mit SFP-Anschluss vom Anbieter nicht noch via einen Mediakonverter führen wollte. Auf dem WAN2 RJ45 habe ich einen 5G-Router als Failover angeschlossen, was super funktioniert (wie auch mit der USG vorher). Ich kann keine Langzeiterfahrung zur UDM Pro benennen, bis jetzt bin ich jedoch zufrieden damit. Ich habe aber evtl. auch nicht so hohe Anforderungen wie andere an das Gerät.

Eine preiswerte Lösung wäre z.B. den Controller in einem Docker extern eines UniFi-Gerätes laufen zu lassen, z.B. Docker auf NAS oder Docker auf einem Raspi, diese Geräte sind häufig schon vorhanden, bzw. ein Raspi 3B+ kostet fast nix mehr aber die Lösung ist nicht so elegant und sauber wie direkt auf einem UniFi-Gerät.

Edit:

Zitat von Ronny1978

Da gebe ich dir recht. Ich habe vor einiger Zeit auf einen Mini PC mit OpnSense gesetzt. Ich bin leider von der UDM Pro / UDM SE nicht ganz überzeugt und der UDR ist mir zu schwankend in seiner Performance bzw. noch etwas Firmware "anfällig". Das "Feld" der Möglichkeiten ist aber groß.

Ronny1978 Kannst Du mir kurz mitteilen, inwiefern Dich die UDM nicht ganz überzeugt hat? Ich frage aus Neugierde und Interesse als neuer UDM Pro Besitzer

Wie sehen Deine Firewall-Regeln aus? Hast Du nach dem Erstellen der VLANs entsprechende Regeln gesetzt (Erlauben und Verbieten) oder einfach die Standardregeln belassen? Bei letzterem Fall wären bei UniFi eigentlich gar keine Einschränkungen zwischen den VLANs vorhanden und die Kommunikation müsste auch mit dem PC funktionieren.

Wie genau versuchst Du denn Deinen PC und womit zu erreichen? Kannst Du ihn anpingen?

Hallo JakB

Vor längerer Zeit hatte ich auch einmal ziemlich Mühe mit dem Einbinden (entweder war es ein AP oder die USG), jedenfalls wollte dieser einfach nicht - ärgerliche Sache.

- Wie lange hältst Du den Reset-Button beim HW-Reset gedrückt? Wenn ich richtig informiert bin, gibt es mehrere Stufen des Resets. Versuche einmal sicher mehr als 15 Sekunden den Reset-Button gedrückt zu halten.

- Ich hatte noch einen alternativen SSH-Befehl zum resetten versucht: "syswrapper.sh restore-default"

--> ich bin zwar der Meinung, dass es keine Rolle spielt, ob der Soft- oder Hardware-Reset durchgeführt wird. Der Zustand des Gerätes sollte danach derselbe sein. Aber es könnte evtl. sein, dass eine Variante nicht (mehr) sauber arbeitet.

- Als ich Probleme hatte, habe ich nach dem Reset manuell die aktuellste Firmware aufgespielt

- Hast Du allenfalls im Controller etwas anderes bei "set-inform" eingetragen? Falls ja diese Eingabe entfernen, bzw. richtig stellen mit der IP des Controllers

- Wird allenfalls ein benötigter Port für die Kommunikation mit dem AP zu Deinem Controller blockiert?

Hier eine Auflistung der benötigten Ports für UniFi-Geräte

Diese Anleitung hatte ich damals ebenfalls abgespeichert, als ich selbst Probleme mit der Einbindung hatte.

Wenn es gar nicht geht, versuch einmal einen zweiten Controller, z.B. auf dem PC zu installieren und schaue, ob eine Einbindung dort möglich ist.

Danach dort beim allenfalls erfolgreich eingebundenen AP unter Einstellungen auf Froget bzw. Ignorieren klicken.

Mehr habe ich leider auch nicht auf Lager.

Viel Erfolg beim weiteren Einbinden!

Hallo zusammen

Nachdem ich zwecks Problemlösung gemäss meinem ersten Post (Link) den Controller (UDM Pro) neu aufgesetzt habe, wollte ich zugleich die Netzwerkstruktur überarbeiten und erneuern.

Dies hat soweit ziemlich gut geklappt, ich bin jetzt auf ein Problem gestoßen, welches ich bis dato nicht selber lösen konnte. Ich hoffe ich habe soweit alle relevanten und wichtigen Informationen geteilt, ansonsten bitte nachfragen.

Folgendes Problem habe ich aktuell mit meinem Netzwerkaufbau.

Edit: Wichtiger Hinweis, welcher ich vergessen habe, ist, die DynDNS-Adressen für Synology Fotos und Bitwarden werden via HTTPS auf meinen Proxy-Manager geleitet und von dort Netzwerkintern an die richtigen Stellen weitergeleitet.

Situation 1

Wenn ich von meinem Mobile Device im WLAN (Technik VLAN 3) via DynDNS-Adresse (z.B. Eingabe in einem Browser) versuche auf Synology Fotos oder Bitwarden zuzugreifen, funktioniert die Verbindung nicht und es lädt eine Zeit lang, bis danach die Fehlermeldung "Die Website ist nicht erreichbar", bzw. ERR_CONNECTION_TIMED_OUT erscheint.

Situation 2

Wenn ich von meinem Mobile Device ohne WLAN im öffentlich Netz via DynDNS-Adresse (z.B. Eingabe in einem Browser) versuche auf Synology Fotos oder Bitwarden zuzugreifen, funktioniert dies einwandfrei.

Situation 3

Wenn ich von meinem PC im verkabelten Netz Default VLAN "1" via DynDNS-Adresse (z.B. Eingabe in einem Browser) versuche auf Synology Fotos oder Bitwarden zuzugreifen, funktioniert dies einwandfrei.

Eigentlich sollten doch alle relevanten Geräte miteinander sowie mit dem Internet kommunizieren können. Welchen Punkt übersehe ich hier?

Mein Netzwerkaufbau

• Netzwerkgeräte
  • Internet = ab FTTH direkt auf UDM Pro (kein doppeltes NAT)
  • Gateway = UDM Pro
  • Switch = 1x USW 8-60W, 1x TP-Link TL-SG109E
  • AP = 3x AP AC Pro
• Netzwerke
  • VLANs = Default (VLAN "1")
  • Technik (VLAN 3) / + WLAN Technik (VLAN 3)
  • (sowie weitere, nicht relevante Netzwerke für diese Problemstellung)
• Relevante Clients in Default (VLAN "1")
  • Alle UniFi-Geräte (fixe IP via Gateway)
  • PC (fixe IP via Gateway)
  • Synology NAS, u.a. mit Synology Fotos und Docker u.a. mit Vaultwarden (fixe IP via Gateway)
• Relevante Clients in Technik (VLAN 3)
  • Mobile Devices
  • RPi mit Docker (NGINX Proxy Manager)
  • (IoT und weitere... nicht relevant)
• Firewall-Regeln (Schnittstelle "WAN In")
  
  • Erlaube Verbindung ab Internet (IPv4) via HTTP/HTTPS auf lokale IP Proxy Manager
• Firewall-Regeln (Schnittstelle "LAN In")
  • Erlaube bestehende und zugehörige Verbindungen
  • Default VLAN "1" hat Zugriff auf alle VLANs
  • Proxy Manager aus Technik VLAN 3 hat Zugriff auf alle VLANs
  • Mobile Devices aus Technik VLAN 3 haben Zugriff auf Default VLAN "1"
  • Am Schluss: verbiete jeglichen Verkehr zwischen allen VLANs
• Firewall-Regeln (Schnittstelle "LAN Lokal")
  • Erlaube PC und Laptop Zugriff auf Gateway (Web UI und SSH)
  • Erlaube Smartphone Zugriff auf Gateway (Web UI und SSH)
  • je VLAN: Verweigere Zugriff aus VLAN auf alle Fremd-Gateway-IPs
  • je VLAN: Verweigere Zugriff aus VLAN auf Gateway (Web UI und SSH)
• Portweiterleitungen
  • HTTP 80 ab WAN / Gateway auf Proxy Manager (RPi mit Docker)
  • HTTPS 443 ab WAN / Gateway auf Proxy Manager (RPi mit Docker)
• Einfache Skizze des Netzwerkaufbaus
  • 
    

Zitat von anton

bei der Ausgangslage (USG + Docker) würd ich kein Backup nehmen, sondern neu einrichten. Wie du ja sagst, der Fehler kam erst mit einspielen des Backups

Nachdem es bei dieser einzigen Rückmeldung geblieben ist und ich diese Option auch bereits vorher im Hinterkopf bereit hatte, führte ich diese nun durch, mit dem Ergebnis, dass diese Fehlermeldung nicht mehr angezeigt wird.

Problem konnte mit manueller Neueinrichtung des Netzwerk-Controller behoben werden.

Hallo liebe UNF-Community

Ich bin neu hier im Forum, betreibe jedoch bereits seit einiger Zeit / Jahren gewiss UniFi-Geräte in meinem privaten Netzwerk zu Hause.

Um meinen "Wissensstand" etwas besser einordnen zu können, hier einige, weitere Infos über mich.

Ich komme aus der Schweiz und arbeite beruflich seit mehreren Jahren als Projektleiter in der Gebäudeautomationsbranche und habe daher in diversen technischen Bereichen zu tun.

Zu Hause betreibe ich mein eigenes kleines Heim-Netzwerk mit grössenteils UniFi-Komponenten. Netzwerktechnik ist eines meiner Hobbies, bei welchem ich mich ab zu mal in ein Thema einlese. Ich habe folglich ein Grundwissen, ebenfalls jedoch auch stellenweise Halb- oder gar kein Wissen über gewisse Bereiche oder Themen.

Ebenfalls habe ich mir den Leitfaden bei Netzwerkproblemen durchgesehen, soweit ich dies selber einschätze, bringt ein vollständiges Ausfüllen dieses Fragebogens keinen Vorteil für mein Anliegen / Problem und poste folglich die aus meiner Sicht relevanten Informationen. Ich lasse mich jedoch gerne eines besseren belehren .

Ausgangslage bis Freitag, 15.09.2023

ISP-Anschluss: FTTH bis auf Schweizer OTO-Dose (LC - APC) im Haus / Speed UP/Down: 1'000 Mbps

Gateway:    USG 3P / RJ45-Patchkabel ab Mediakonverter / kein doppeltes NAT (bei meinem ISP besteht die Möglichkeit, den Anschluss ohne ISP-Modem zu beziehen)

LWL-Kupfer-Konverter: Drittanbieterware: Billiger Mediakonverter mit SFP-Adapter (Single Mode LC - UPC) bis 1.25G / LWL-Patchkabel 1m Single Mode LC - APC / LC - UPC

UniFi-Controller:   Docker-Container (Synology-NAS) mit jacobalberty/unifi (v7.3.83)

Ausgangslage ab Samstag, 16.09.2023

ISP-Anschluss: FTTH bis auf Schweizer OTO-Dose (LC - APC) im Haus / Speed UP/Down: 1'000 Mbps

Gateway:    UDM Pro mit Drittanbieterware: SFP-Adapter (Single Mode LC - UPC) bis 1.25G / LWL-Patchkabel 1m Single Mode LC - APC / LC - UPC / kein doppeltes NAT (bei meinem ISP besteht die Möglichkeit, den Anschluss ohne ISP-Modem zu beziehen)

LWL-Kupfer-Konverter:    entfällt neu

UniFi-OS:   UDM Pro / v3.1.16

UniFi-Controller:   UDM Pro / v7.4.162

Problemstellung

Ein wichtiger Punkt vorab: Grundsätzlich funktioniert bei mir soweit alles, daher ist mein Anliegen (aktuell) nur kosmetischer Natur.

Ob nun mit alter oder neuer Ausgangslage trat dasselbe, nachfolgende Problem auf.

Bei alter Ausgangslage in meinem UniFi-Controller und bei neuer Ausgangslage auf dem UDM-Pro Display, in der UniFi-OS Übersichtseite sowie auf der UDM-Pro Loginseite wird mir dauern angezeigt, dass keine Verbindung zum Internet bestehen würde. Fakt war und ist jedoch, dass ich sehr wohl mit dem Internet verbunden bin. Ich beziehe vom ISP direkt eine öffentliche WAN-IP, kann mich normal im Internet bewegen und der Speedtest zeigt ein zu erwartendes Ergebnis an.

Interessanterweise zeigte sich gestern beim Einrichten der UDM-Pro folgendes Verhalten:

Als ich diese wie oben beschrieben via LWL mit dem ISP verbunden habe, kam diese Fehlermeldung nirgendwo. Danach führte ich mehrere Firmwareupdates von v1.x bis zur aktuellen v3.1.16 durch. Auch danach wurde der genannte Fehler noch nicht angezeigt. Nachdem ich jedoch mein Backup vom bestehenden UniFi-Controller auf die neu eingerichtete UDM Pro aufgespielt habe, erschien auch die Fehlermeldung über die fehlende Internetverbindung.

Ich vermute, dass irgend ein Setting aus meinem bestehenden Controller heraus dafür verantwortlich sein muss, bis dato habe ich (wie auch bei der alten Ausgangslage) die Ursache jedoch nicht herausgefunden.

Meine Frage an Euch:

Kennt jemand dieses Problem oder weiss jemand, woran es liegt und wie ich diesen Fehler beheben kann?