Routing Probleme nach Update von UDM Pro auf Version 4.2.4.

Hat jemand hier einen Tipp für mich?
Das Setup:
Ich habe eine Dream Machine Pro als Gateway meines kompletten Netzes - hinter einer FritzBox. (der Primary WAN-Port der DMPro geht zur FRITZBox)
Switches und Access Points werden über UDM Pro verwaltet: USW Lite 16 PoE, 2x US 8, U6 Enterprise, 3x U6 Pro
Das Netzwerk ist in mehrere Zonen aufgeteilt - relevant hier die die "Default" und "InternSecure"
Im Default-Netz VLAN-ID 1 (10.10.10.0/24) (Default-Gateway: 10.10.10.1) befinden sich die DM Pro und alle relevanten Clients
Im "InternSecure" VLAN-ID 20 (10.10.20.0/24) (Default-Gateway 10.10.20.1) die anzusprechenden Server (2x QNAP) (beschrieben ist das Problem am Zugriff auf die Web-Oberfläche, SMB ist aber ebenfalls davon betroffen)

Ausgewählte Clients aus der „Default-Zone“ sollen nun Zugriff auf die Server bekommen.
Dazu erlaubt eine Zonen-Firewall-Regel den Zugriff der gewünschten Clients aus der Zone "Default" in die Zone "InternSecure" mit allen Ports und allen Protokollen - für die Gegenrichtung ist "Auto Allow Return Traffic" aktiviert (diese Regel durch eine eigene "Allow All" zu ersetzen hat die Situation nicht verändert)

Zunächst hat dieses auch einwandfrei funktioniert, bis zum Update der Unifi-Netzwerksoftware auf Version: 9.1.96 (oder, dem resultierenden Neustart...) - danach gingen viele Datenpakete verloren und die Verbindung war unbrauchbar (aber vorhanden). Eine vorübergehende Lösung war die Verbindung der Clients über ein eingerichtetes WireGuard für einige Tage (Unifi-Zone VPN - hier gibt es dann eine eigene "Allow All-Regel", die erlaubt hier allen VPN-Clients den Zugriff auf das Secure-Netz). Nach dem zuletzt erfolgten Update (oder, dem erneut erfolgten reboot) der Gateway-Software auf Version 4.2.4. funktioniert aber auch diese Verbindung der Clients zu den Fileservern, nicht mehr "nutzbar".
Eine mögliche Auffälligkeit: Wenn ich mich richtig erinnere, war bei meiner zusätzlich angelegten Zone (vor dem Update) die Unifi-Default-Regel aus der (Unifi )VPN-Zone in Richtung meiner neuerstellten "InternSecure-Zone" auf "Allow All" (wie bei allen anderen von Unifi angelegten Zonen) - nun nach dem Update ist der Unifi-Default hier "Block All Traffic"
(möglicherweise könnte das jemand verifizieren, der das Update 4.2.4. noch nicht gemacht hat - wäre ein Indiz?)

Um die (beschriebene "vorhandene aber nicht nutzbare Verbindung") zu konkretisieren habe ich mir die fehlerhafte Verbindung einmal auf Netzwerkebene angeschaut - Zwar bin ich kein Profi auf diesem Gebiet, aber eine Analyse mit Wireshark zeigt denke ich, das Problem: "(TCP Out-Of-Order) 443" und "(TCP Previous segment not captured) 443" - es gehen also offenbar Datenpakete verloren - Ein wenig habe ich das Routing im Verdacht, dann hätte aber die DMPro Routingprobleme mit ihren eigenen Netzen - und im Internet würden sich vermutlich viel mehr Beschwerden finden

Ob meine Probleme wirklich mit dem Update zustande gekommen sind ist für mich nicht ganz sicher, da die ganze Lösung erst seit wenigen Tagen in Betrieb war.

Habe ich beim Routing einen Denkfehler? (Defaultgateway ist in allen Netzen die DMPro, mal die 10.10.10.1 dann die 10.10.20.1)
Gibt es eine Möglichkeit das "echte" Routing des Gateways auszulesen? Hat jemand eine Idee?

Bin für alle Tipps dankbar...da das Netz produktiv ist, kann ich nur nicht mit beliebigen Unifi-Versionen testen und rebooten.

Tom

PS: Auch inzwischen mehrere durchgeführte Reboots haben die Situation nicht mehr verändert

Quote from DoPe

Was heisst denn das echte Gateway? Die UDM hat in beiden Netzen eine IP, kennt also die Netze und somit stehen die in der Routing Table drin (nachzuschauen per ssh auf der UDM). Wenn deine Server und Clients die jeweilige IP der UDM aus ihrem Netz als Gateway nutzen und nicht irgendwelche zusätzlichen fehlerhaften statischen routen im OS eingetragen haben, dann ist soweit vom routing her alles in Ordnung ...

Ansonsten kann ich deinen Ausführungen nicht folgen ... zuviel Text der irgendwas beschreibt und Dinge die schleierhaft sind .... Was ist die Default Zone und internSecure, dann heißen die Netzwerke auch so ... ?!? Da sagen Bilder mehr als tausend Wort.

Was die Änderung der Default Traffic Rules angeht, da stand in irgendnem Update was zu, meine ich mich zu erinnern.

DoPe Ich hatte die Benennung der Zonen in der Beschreibung ein wenig vereinfacht um es nicht unnötig komplizierter zu machen Ich habe nun einmal ein kleines Bild erstellt - ich hoffe es wird nun etwas deutlicher
PS: natürlich sind da Firewallregeln zwischen allen Zonen - habe aber nur einmal die eingezeichnet, die im Augenblick wichtig erscheinen

Hi all,
es gibt ein Update - leider, wird die Sache dadurch nicht einfacher - ich lasse das Thema hier trotzdem einmal stehen, möglicherweise hat ja jemand ein ähnliches Problem.

Das Routing scheint zu passen, da ein per Kabel über den Switch verbundener Client das beschriebene Problem nicht hat! (er also "fehlerfrei" aus dem "Default-Netz" (ID-1) in das "InternSecure" (ID-20) zugreifen kann)
Das Problem tritt also nur auf, wenn der Zugriff per WLAN über den Accesspoint (U6 Enterprise oder U6 Pro - verhalten sich hier gleich) auf die Server versucht wird.

Die reine Performance der Accesspoints ist dabei aber nicht das Problem - es muss mit dem Tagging der Netze in Verbindung stehen.

Begründung: (bitte nur lesen, wer bis hier noch nicht verwirrt ist )
1. Das Problem tritt unabhängig von der Last an einem der Accesspoints auf und der U6 Enterprise hat ausreichend Ressourcen
2. hinter einem weiteren per Mash verbundenen Access-Point befindet sich ein Switch (US 8 - ein hier per Kabel angeschlossener Client (Port getaggt auf ID-20 "InternSecure") hat ebenfalls keine Probleme beim Zugriff (diese Verbindung geht dann über den gleichen Accespoint (bzw. sogar einen 2. U6 Pro im Mash), nur ist der Client an einem getaggten Port)

Wenn jemand gute Ideen hat, bitte gerne bei mir melden
Tom

Quote from Peterfido

Evtl. Client - Isolierung aktiviert? Microsoft hat bei Windows auch bissel was geändert. Man kommt seit neuestem nicht mehr auf Netzwerkfreigaben, welche ohne Passwort gesichert sind, was beim Public-Ordner eines NAS generell vorkommen dürfte.

Entweder Passwort einrichten, oder per GPEDIT / Registry "wieder" erlauben. Auch war bei mir die Netzwerkfreigabe deaktiviert. Warum Microsoft sowas ohne Meldung mit Updates eunführt, ist mir ein Rätsel.

Danke für die Info, hatte ich tatsächlich noch nicht mitbekommen - mein Problem hier ist allerdings tatsächlich auf Netzwerkebene - im Fall von SMB kommt in der regel sogar eine Kommunikation zustande, die dann aber so inperformant ist, dass sie abbricht.
(habe das Problem vorübergehend mit dem Umzug des Servers in das Clientnetz und der lokalen Firewall umgangen)