Verbindung zwischen VLANs via DynDNS

Es gibt 11 Antworten in diesem Thema, welches 1.674 mal aufgerufen wurde. Der letzte Beitrag () ist von DoPe.

    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

  • Zum Hilfreichsten Beitrag springen

    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?

    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.

    Auch meine erste Idee: Situation 1 herstellen und dann mit nslookup auf der Console prüfen, wie / ob die jeweiligen Adressen aufgelöst werden.

    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!

    Ich denke mal das liegt am NAT Loopback (oder einen der tausend anderen Bezeichnungen dafür)... Der DDNS Host sollte ja auf die WAN IP zeigen, sonst geht der Zugriff von Aussen nicht. Sieht so aus als ob das NAT Loopback nur in einem VLAN funktioniert oder die Firewall blockiert da was ... kannst Du aus VLAN 3 den Proxy erreichen und auch vom Proxy das VLAN3?


    Ich für meinen Teil mache bei sowas gerne Split DNS, lasse also den DNS der im LAN verwendet wird, für den DDNS hostnamen gleich die korrekte LAN IP (in dem Fall vom Proxy) ausspucken. Dann wird gleich direkt kommuniziert ohne von wildem SNAT/DNAT und Maskieren des Routers am WAN Port abhängig zu sein.

    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 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.

    • Hilfreich

    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!

    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 :smiling_face::thumbs_up:



    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... :thinking_face:

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

    Hmm sieht auch erstmal nicht so logisch aus. Was hast Du denn so an Firewallregeln für Traffic von VLAN 1 nach VLAN 3? Ist im NAS irgendwas an Firewall aktiv?


    Da müsste man wohl Wireshark bemühen um evtl. zu ermitteln wer da eigentlich wirklich mit wem kommuniziert und was da an den Paketen wie auch immer SNATet und/oder DNATet wird. Allerdings muss ich zugeben mit Wireshark hab ich mich noch nie befassen müssen und es ist für mich ein Buch mit 7 Siegeln.


    Aber ansonsten macht doch der 2. Versuch genau das was Du möchtest und hat sogar den Vorteil, dass Du nicht den Zugriff auf das komplette VLAN1 erlauben musst. Ist jetzt halt nur die Frage warum ist das so, ist das auch wirklich sicher und ist das evtl. auch nur irgendein BUG.