VLAN CIFS Verbindung blockiert durch Firewall Regel "Block inter VLAN Routing" obwohl Portfreigabe vorhanden

Es gibt 6 Antworten in diesem Thema, welches 574 mal aufgerufen wurde. Der letzte Beitrag () ist von ragman1976.

  • Hallo,


    ich habe eine Syno DS218+ in einem VLAN (Service, ID=5) mit der IP Adresse 192.168.5.13. In einem anderen VLAN (IoT, ID=14) habe ich einen Homeassistant Server als VM (Proxmox) laufen.


    Ich möchte die HASS VM via CIFS/SMB mit der Syno verbinden, was auch mit der entsprechenden Firewallregel funktioniert (Regel siehe Allow CIFS.jpeg).

    Sobald ich aber eine Regel Block Inter VLAN Routing (siehe Block inter VLAN Routing.jpeg) nachschalte, wird die Verbindung blockiert.


    Das Blockieren wird mir auch im Trigger-LOG der UDM angezeigt /siehe LOG.jpeg), aber komischerweise wird dort der Port des Clients (HASS VM) mit 34909 angeben. Das erklärt zwar das Blockieren durch die Regel Block Inter VLAN Routing, aber ich verstehe nicht warum überhaupt der Port 34909 verwendet wird, CIFS/SMB läuft doch über die Ports 138,139, 455, welche über die entsprechende Port Gruppe freigegeben sind (siehe Ports.jpeg.


    Hat jemand Rat?


    Gruß und Danke


  • Bei einer Verbindung gibt es am aufrufenden Client einen Quellport und am Zielsystem einen Zielport. Der Zielport ist auf dem System festgelegt also z.B. 445

    Der Quellport des Clients wird fast immer ausgewürfelt. Also ein hoher gerade nicht benutzter Port dafür verwendet. Dieser ändert sich auch. Daher filtert man höchst selten nach dem Quellport. Das Auswürfeln erfolgt, da sonst zum Beispiel bei gleichzeitigem gegenseitigen Zugriff von zum Beispiel 2 Fileservern die Pakete beider Verbindungen auf dem gleichen Port laufen. Da dann der Remote Port bei beiden Verbindungen auch noch identisch wäre, hätte man ein bisschen nöte die Paketen den eigentlichen Sessions zuzuordnen.

  • Bei einer Verbindung gibt es am aufrufenden Client einen Quellport und am Zielsystem einen Zielport. Der Zielport ist auf dem System festgelegt also z.B. 445

    Der Quellport des Clients wird fast immer ausgewürfelt. Also ein hoher gerade nicht benutzter Port dafür verwendet. Dieser ändert sich auch. Daher filtert man höchst selten nach dem Quellport. Das Auswürfeln erfolgt, da sonst zum Beispiel bei gleichzeitigem gegenseitigen Zugriff von zum Beispiel 2 Fileservern die Pakete beider Verbindungen auf dem gleichen Port laufen. Da dann der Remote Port bei beiden Verbindungen auch noch identisch wäre, hätte man ein bisschen nöte die Paketen den eigentlichen Sessions zuzuordnen.

    Erstmal Danke für die Antwort...soweit verstanden. Die Initialisierung erfolgt über Port 445 (was auch immer funktioniert, das sehe ich im HASS LOG; wird dann aber abrupt abgebrochen), der Austausch dann über einen zufällig ausgewürfelten Port. Dieser wird aber dann von der Regel "Block Inter VLAN Routing" blockiert. OK.


    Gibt es dann überhaupt eine Möglichkeit eine CIFS Verbindung dauerhaft herzustellen und den Verkehr zwischen den VLANs (Block Inter VLAN Routing) zu unterbinden?

  • Der Client würfelt Port 43567 aus und connecten zu Port 455. Der Server schickt seine Antwort von Port 455 an Port 43567 zurück.


    Du musst also nur erlauben das neue Pakete an Port 455 und Quellport ANY aus VLAN A nach VLAN B (oder gerne auch die entsprechenden Quell und Ziel IPs) dürfen. Und natürlich muss erlaubt sein related und established Pakete zwischen beiden VLANS auszutauschen.


    Dahinter dann die Block Regel für Inter VLAN Routing

  • Der Client würfelt Port 43567 aus und connecten zu Port 455. Der Server schickt seine Antwort von Port 455 an Port 43567 zurück.


    Du musst also nur erlauben das neue Pakete an Port 455 und Quellport ANY aus VLAN A nach VLAN B (oder gerne auch die entsprechenden Quell und Ziel IPs) dürfen. Und natürlich muss erlaubt sein related und established Pakete zwischen beiden VLANS auszutauschen.


    Dahinter dann die Block Regel für Inter VLAN Routing

    Aber genau das habe ich ja gemacht und es funktioniert nicht. Oder habe ich da noch einen Verständnissfehler?



    Und an allererster Stelle in den Firewallregel steht Allow established and related:


  • Sieht soweit erstmal ok aus. Wobei ich bei den Regeln die TCP flags etwas genauer setzen würde. Also unten auf manuell und dann nur new anhaken bei neuen konkret erlaubten Verbindungen.


    Bei der related und established dann entsprechend nur die beiden Haken. Das sorgt dafür das in deinem Fall schonmal alle Antworten können und mit den konkreten Regeln mit new erlaubst Du den Zugriff.


    Die Drop invallid ebenfalls manuell und dort nur invallid anhaken und die regel kann ganz nach oben. Da wo sie jetzt ist landet man im Zweifelsfall nicht weil Du vermutlich in allen erlauberegeln die flags nicht benutzt hast und somit alle 4 statis greifen.


    Funktionieren die ganzen anderen Regeln auch nicht? Du hast ja da noch einige zur DS und auch welche mit NFS statt smb - wäre ja von der Logik her analog.

  • Jetzt funktioniert es. Kann zwar nicht 100%ig nachvollziehen warum, bzw. was vorher "faul" war, aber ok..nehme ich.


    Danke für die Unterstützung.

    Einmal editiert, zuletzt von ragman1976 ()

  • ragman1976

    Hat das Label von offen auf erledigt geändert.