Beiträge von frank_m

    Danke für den Tipp. Wenn ich die VLAN ID auf 330 ändere, dann lassen sich gar keine SIP-Accounts mehr verbinden, auch nicht die von meinem bisherigen DSL-Anbieter.

    Das lässt sich vermutlich ändern, indem du in den DSL VoIP Accounts einen Haken bei "Anmeldung immer über eine Internet Verbindung" setzt.


    Und da auch direkt die Frage: Wie hast du den Haken bei den anderen VoIP Accounts gesetzt?

    dann müssen wir warten, bis die 7.27 Physik aufbauen kann und noch mal testen.

    Das wird nichts. Noch mal: Es ist normal, dass keine physikalische Verbindung angezeigt wird. Die Box verfügt nicht über die Infos, den GPON Stream zu ver/entschlüsseln. Vermutlich wird dir im Glasfaser-Status eine gelbe Linie angezeigt, richtig? Da fehlt kein Licht, da fehlen die passenden Zugangsdaten.


    Das Ziel der Eingaben der Daten des anderen ONTs ist es doch, genau diese physikalische Verbindung aufzubauen. Es muss also quasi erst mal nicht funktionieren, damit die Versuche überhaupt Sinn machen.

    elnx: Genau so ist es. Beim Betrieb "kundeneigener Router" wird "vor dem ONT" die VLAN ID 362 benutzt, die am Kupferausgang rausgefiltert wird. Kundeneigene Router am Kupfer des ONTs brauchen sich mit VLANs nicht mehr abzugeben.


    Im Modus "DG Router" ist es anders. Dort werden "vor dem ONT" die VLAN IDs 360 und 330 benutzt, wie bei HubeBube beschrieben, aber die bleiben dort auch "nach dem ONT", also am Kupfer erhalten. Jedenfalls wird die DG 7590 mit den entsprechenden VLAN IDs konfiguriert.


    Das ist bei AON so, aber ich könnte mir gut vorstellen, dass es bei GPON auch so ist.

    Ich kann mir gut vorstellen, dass sich die Standardregeln ändern, wenn man die Policy umstellt. Ich vermute, das ist bei dem Kollegen der Fall, denn er schreibt in seiner Anleitung:

    Zitat

    Hierzu bei „IPv6 WAN eingehend“ erst entsprechende Regeln für jedes Zielgerät und den entsprechenden Ports erstellen. Falls es mehrere sind, können auch Portgruppen oder Adressgruppen erstellt werden.

    Danach eine Regel erstellen, die jeglichen IPv6 Zugang auf allen Ports verbietet.

    Der fett gedruckte Teil wäre eigentlich nicht nötig, wenn die Default Policy "drop" ist, sehr wohl aber, wenn sie "accept" ist. Bei default Policy accept hingegen sind die Standard-Regeln, die ihr hier postet, unnötig, und können wegfallen. Es würde zuverlässig erklären, warum ihr davon ausgegangen seid, dass die Firewall offen ist für IPv6 und warum das Regelwerk anfänglich nicht funktioniert hat.


    Sollte das der Fall sein, wäre das ggf. noch mal ein Hinweis für die Verbesserung seines Howtos, denn in die Falle tappen bestimmt viele. Er sollte kurz auf die Policies in seiner Firewall eingehen. Deshalb hat er auch vermutlich dieses unterschiedliche Feedback auf seine Anleitung: Bei einigen gehts sofort, bei anderen nie. Die, bei denen es nie geht, sind die, bei denen die Policy nicht zur Anleitung passt - warum auch immer.

    Das wurde mir bspw aber auch mal von einem Lancom Mitarbeiter gesagt.

    Das die Ubiquiti Firewall generell erstmal alles offen hat. und bei Lancom sei erstmal alles auf deny all, bis man die Dienste jeweils freischaltet?

    Was auch immer der LANCOM Kollege damit erreichen wollte. Ich hatte ja extra die Dokumentation verlinkt, aus der hervorgeht, dass die Default Policy "drop" ist.

    Im Screenshot oben sieht man, dass die UDM-Pro praktisch nichts von außen annimmt. Für ein erfolgreiches "Ping" müssen ICMP Echo Requests von außen zugelassen werden: für "In", wenn Geräte im LAN anpingbar sein sollen, und für "Local", wenn die UDM-Pro anpingbar sein soll. Ansonsten müssen eben die Dienste freigegeben werden,

    Tja, siehe Beitrag #2 und #4. Wir hätten uns den ganzen Thread also sparen können, wenn die Hinweise da schon befolgt worden wären.


    Wie hast du ihn denn im Chat davon überzeugt, dass er Hand anlegen muss und sein Netz nicht "offen" ist? Mit wollte er es ja nicht glauben.


    Ich frag mich auch, was der Kollege aus dem Nachbarforum, der ja "echt fit" ist, so gemacht hat, wenn selbst die grundlegendsten Firewallregeln für den Anwendungsfall nicht da sind.

    Ich halte es auch für suboptimal, solche Dinge dann bilateral im Chat anzugehen. So bleibt anderen Interessierten der Lösungsweg verborgen. Jetzt bekommen wir vielleicht noch mit viel Glück eine (für diesen Fall) funktionierende Firewall Tabelle präsentiert, aber wie die entstanden ist und nach welchen Prinzipien man bei der Erstellung vorgeht, erfährt man nicht. Das eine fehlerhafte Firewall die Ursache war, war auch vorher schon mehr als offensichtlich, da ja schon grundlegendste Voraussetzungen falsch eingeschätzt wurden (siehe drop Policy).

    Übringens: Wenn man die Standard-Regeln der Firewall bei IPV6 nicht ändert, ist das Netzwerk offen.

    Falsch. Default policy ist "drop".

    https://help.ui.com/hc/en-us/a…duction-to-Firewall-Rules


    Zitat
    WAN v6 Local Applies to IPv6 traffic that is destined for the UDM/USG itself on the WAN network (default drop).<br><br>
    Zitat
    WAN v6 In Applies to IPv6 traffic that enters the WAN (ingress), destined for other networks (default drop).


    ab Punkt 3.7


    Firewall-Regeln ensprechend angepasst.

    Gerade der Bereich "Firewall" ist sehr stiefmütterlich beschrieben, und gerade darauf kommt es ja an. Außerdem lässt er Interpretationsspielraum, vor allem für die zweite Regel. Lange Rede, kurzer Sinn: Nach der Anleitung ist die Wahrscheinlichkeit hoch, dass ihr die Firewall falsch konfiguriert habt.


    Also: Was genau habt ihr da getan? Welche Geräte und welche Dienste wolltet ihr erreichen, und wie habt ihr diese Geräte vorbereitet?


    z. B. Werksreset

    Das kann ja nicht alles gewesen sein. Welche Ansätze habt ihr denn sonst noch verfolgt?



    Daher unsere Vermutung, dass es am Netzt liegen könnte.

    Das halte ich für recht unwahrscheinlich, da ihr bei der Fritzbox die WAN Adresse pingen könnt. Zumindest das müsste auf der UDM auch gehen. Da du in deinen bisherigen Beiträgen sehr viel Halbwissen und noch mehr falsche Annahmen präsentiert hast, ist es wahrscheinlich, dass ihr die Geräte falsch konfiguriert habt.

    Das haben wir ja freigegeben gehabt, aber da ging gar nichts.

    Was habt ihr denn da gemacht?


    Der Kollege aus dem Nachbarforum kannte das Problem auch schon, nur leider funktionieren die ganzen Lösungsansätze nicht.

    Und wieder: Was genau habt ihr da gemacht? Wir können nicht hellsehen.


    FB so eingestellt, dass auch die UDMPro an Ihrem WAN-Port und die Geräte an der UDMPro IPV6-Adressen bekommen.

    Das heißt Prefix Delegeation, oder was?


    Wenn man jetzt mit traceroute6 die IPV6-Adresse des WAN-Port der UDMPro oder die IPV6-Adresse eines der Geräte an der UDMPro mit

    mit traceroute6 anspricht, ist am WAN-Port der FB nach Zeile 8 Schluss, so wie es sein soll.

    Naja, ob das so sein soll, darf bezweifelt werden. Aber gut, wenn man nichts weiter macht, dann ist das so.

    In der Firewall habe ich nichts weiter eingestellt. Müsste ich das denn

    Oh ja, und das war irgendwie komisch. Ist lange her. Es gab einen Unterschied zwischen "ICMPv6" und "IPv6-ICMP", kann ich mich erinnern. Und man muss sauber unterscheiden zwischen dem Traffic für die UDM und dem fürs Netzwerk ("local", "in"). Insgesamt war das schon tricky, wenn man die Geräte nicht kennt. Man sollte definitiv mehr als nur Routing-Grundlagenwissen haben, um sich mit den Geräten auseinanderzusetzen.


    aber warum kommt man dann an die anderen Geräte nicht ran?

    Man kommt erst mal nirgendwo dran, es sei denn, man erlaubt es explizit. Eingehender Traffic sowohl auf "local" als auch auf "in" wird verworfen. Also: Ja, du musst definitiv erst mal dafür sorgen, dass der Datenverkehr deine Endgeräte erreichen kann.

    Gibts man an einem IPV6-Gerät eines anderen Anschlusses den traceroute6-Befehl gefolgt von der IPV6-Adresse des WAN-Port ein,

    müsste in Zeile 8 dann Schluß sein.

    Das ist in meinem Fall aber nicht so. Hier kommen dann nur Sternchen und der Befehl läuft weiter.

    Offenbar blockt deine UDM ICMPv6 Nachrichten auf dem WAN Port, entweder ein- oder ausgehend (oder beides). Ich vermute das Problem also in der Firewallkonfiguration. Was hast du denn dort getan, um den Zugriff von außen zu mit ICMPv6 ermöglichen?


    Hast du es mal mit "echten" Diensten probiert?

    Brauche ich überhaupt die Umsetzung mit 2 G.hn Geräten, oder kann ich einfach das Signal am ONT abgreifen und über die Telefonleitung zur Fritzbox führen? Sofern im Netzwerkkabel zwischen ONT und Router nur 2 Leitungen benötigt werden, müsste das doch gehen.

    Zum einen brauchst du mindestens 4 Adern, und das sind dann auch nur 100 MBit/s. Und ob die erfolgreich durch ein Telefonkabel gehen, ist eher ein Glücksspiel. Heißt: Für die Weiterleitung eines Glasfaseranschlusses völlig ungeignet. Für die Frequenzbereiche von Ethernet sind gewisse Anforderungen ans Kabel nötig. Für mehr als 100 MBit/s sind es mindestens 8 Adern, und das mit angemessener Schirmung und Verdrillung: Mindestens CAT5e. Alles andere funktioniert nicht.


    - Praxiserfahrung bzgl. Bandbreite der devolo-Lösung?

    Über Telefonkabel liest man davon eher selten. Meistens versuchen es die Leute über Strombakel, was üblicherweise in einer Katastrophe mündet. Über ein Telefonkabel könnte es besser funktionieren.