Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellen
Es gibt 44 Antworten in diesem Thema, welches 3.559 mal aufgerufen wurde. Der letzte Beitrag () ist von DoPe.
Hmm jetzt bin ich irritiert, ich wollte eine neue Regel aufnahmen und nur den TCP und UDP Port 53 für DNS freigeben und habe die erstelle Regel mal rausgenommen (damit ging es jetzt), gestern noch nicht.
Nach dem ich die Regel entfernt habe geht es jetzt für das Private netz trotzdem 
Testweise habe ich es auch für das Gäste Netz eingetragen, dort funktioniert der DNS Server auch, ohne das ich was an Regeln eingetragen habe
Dann geht es vielleicht doch ohne, weil die UDM den "Weg" kennt und als Standard Gateway fungiert. Regel erstmal weglassen und testen!!!
Sry my bad, ich hatte unter Traffic Rules die Regeln kurz rausgenommen um was zu testen und vergessen wieder rein zu nehmen.
Wenn ich folgende Traffic Rule einstelle, dass das Private Netz nicht in das Default kann:
Und dann den DNS Server auf 192.168.10.62 stelle (befindet sich im Default Netz)
Dann funktioniert es nicht.
Habe folgende FW Regel eingestellt:
in den DHCP Einstellungen der Vlans den eintragen und die IP dediziert in der Firewall freigeben. hab ich so gelöst bei mir. Bei mir ist ein Pi mit Pihole und GPS am laufen
Könntest du deine Einstellung bitte posten? Ich bekomme das nicht hin leider
Ich habe es jetzt über eine Traffic Rule realisiert, falls es jemand noch braucht:
Damit klappt es nun
Sollte ich per Traffic-Rule eine Allow Regel einrichten mit den IPs der Shellys für das Default-Netz? Oder würde dies dem Kern der getrennten Netze widersprechen?
Firewall-Regeln sind ja genau dazu da, den Traffic zwischen den VLAN zu regeln, zu erlauben oder eben zu blocken.
Ich glaube aber eher nicht, das die dein Problem mit den 10Sec bei den Shelly beheben wird, aber probiere es aus.
Entweder ist eine Verbindung erlaubt oder eben nicht, aber so verzögert ist merkwürdig.
Ich habe die IPs der Shellys für das Default Netz nun mal freigegeben und die Verzögerung ist nun nicht mehr vorhanden.
Passt das so?
Ich habe die IPs der Shellys für das Default Netz nun mal freigegeben und die Verzögerung ist nun nicht mehr vorhanden.
Passt das so?
Ich finde das Verhalten merkwürdig.
Du trägst die IP's ein und es funktioniert - du lässt die weg und hat 10sec Verzögerung, ich hab ja schon viel mit der UDM erlebt aber das ist äußerst seltsam.
Ich erwarte von einer Firewall das die Traffic durchläst oder konsequent blockiert oder nicht sowas.
Aber ohne die ganz restliche Konfig zu kennen, ist das müssig drüber nachzudenken.
Du greifst auf die Shelly's direkt per IP zu? Könnte hier auch ein mDNS Mechanismus blockiert sein und ein Cloud Fallback greifen?
Die Regeln sollte neue Verbindung ins IOT erlauben und Antworten aus established Verbindung vom IOT. Dann können IOT Geräte keine Verbbindung ins Main aufbauen aber antworten. Bin mir nicht mehr sicher ob die DMP das per default so macht.
Ich denke ich weiß jetzt wo mein Fehler lag, ich hatte noch eine Traffic-Rule die wie folgt aussah:
Hier hatte ich noch das "Default" Netz mit drin. Das habe ich raus genommen und komme jetzt auch auf die Shellys, ohne das ich die IPs noch mal explizit freigeben muss.
Das sollte so passen oder?
Eine Frage noch
so sieht meine Traffic-Rule für das IoT Netz aus:
Wäre diese Traffic-Rule damit nicht überflüssig, bzw. doppelt?
Ich habe mir die ganzen Videos bei Youtube noch mal angeschaut und noch mal geguckt, ob alles dem entspricht wie die es auch eingestellt haben, diese FW-Regeln (neben den Traffic-Rules habe ich nun).
Vllt. könnte bitte noch mal jemand drüber schauen 
Hm ich bin kein Netzwerkprofi aber ich denke nein nicht ganz.
Jedenfalls zeigt die Änderung das es ein Firewall Thema ist
Aber nachdem Du den block vom iot zum default ganz raus nimmt können dann nicht die Iot Geräte sich beliebig ins Default verbinden?
Ich meine Du musst jetzt eine Regel block IOT -> Default für Neu und Invalid hinzufügen.
Allerdings hast Du ja die allow established and related an erster Stelle die das ggf. schon erlaubt.
Warum das zu einem 10sec Delay geführt hat k.A.
Weiterhin ist mir aufgefallen das Du die Regel LAN.local eingerichtet hast.
Soweit es mir bekannt ist.
LAN.in sind Filter die Pakete vom Lackleder Netzwerk in andere Netzwerk eingehen zum Router filtern.
LAN.out diti aber outbound am Router
LAN.local lan Paket Filter die lokal an den Router gerichtet sind zum Beispiel ein DHCP für ein Netzwerk der auf den Router läuft.
Und die Regeln typischerweise lan.in
Ich habe Probleme einen VPN Server aufzusetzen, bin mir allerdings nicht sicher, ob das eventuell am Starlink liegt.
Bekommst du reinkommten keine VPN-Verbindung ?
Soweit ich weiss, nutzt Starlink doch CG-NAT für die Anschlüssen und damit hat sich VPN eh erledigt.
Hab bisher auch nichts anderes gehört. Zumindest in DE gibts bei Starlink die 100er CGNAT Adressen.
Da würde dann also für VPN auch nur der Weg über einen externen "Hilfsserver" möglich sein. In dem folgenden Thread bastelt man wohl sowas.
das hängt von der Hardware ab, zb kann auf einem Switch 10 Geräte mit je 1G dann mit Geräten auf einem anderen Switch auch mit je 1G kommunizieren, und es teilen sich nicht alle bis zu 24 Geräte einen 1G Flaschenhals.
Wenn man nur 1 Switch hat, ist das natürlich nicht so relevant. aber ein 10G DAC kostet keine 20€, und somit lässt sich das auch kostengünstig per 10G (und dazu sehr Stromsparend) verbinden. Denn ein DAC oder LWL ist Stromsparender als eine Kupfer Verbindung (RJ45). Denn selbst 1G kann bis zu 1W brauchen , LWL oder DAC weniger als die hälfte
Ich hab von dem hier 5 Stück im Einsatz, keine Probleme damit, laufen seit anfang an fehlerfrei
zur Zeit sind 70 Mitglieder (davon 2 unsichtbar) und 324 Gäste online - Rekord: 129 Benutzer ()
