Beiträge von frank_m

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.

Zitat von lycra

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.

Zitat von alfalfa

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.

Zitat von HubeBube

Verbindungseinstellungen - VLAN-Einstellungen: VLAN für den Internetzugang verwenden: Haken setzen => VLAN-ID: 360 ; PBit: 0

Sollt der Modus "Kundeneigener Router" sein, dann ist die VLAN ID hier 362. Dafür braucht man keine dedizierte Telefonie VLAN ID mehr.

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

Zitat von Braeuni

Ü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/artic…-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).

Zitat von Braeuni

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?

Zitat von Braeuni

z. B. Werksreset

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

Zitat von Braeuni

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.

Zitat von Braeuni

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

Was habt ihr denn da gemacht?

Zitat von Braeuni

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.

Zitat von Braeuni

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?

Zitat von Braeuni

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.

Zitat von Braeuni

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.

Zitat von Braeuni

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.

Zitat von Braeuni

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?

Dafür wäre es interessant zu wissen, welcher Modus bei bugmast3r aktiv war. Er schreibt ja, dass er eine Sicherung eingespielt hat, mit der alles noch lief. Die Konfiguration der VLANs etc. hat sich also nicht geändert.

Zitat von James

Es müsste auch funktionieren wenn die FB nicht als Router verwendet wird

Ja, Problem ist dann aber: Wie finden die spanischen Netzwerk-Clients die Route ins VPN? Entweder muss in jedem Gerät eine entsprechende Route erzeugt werden, oder eine statische Route im vorgelagerten Router.

Zitat von det2fe

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.

Zitat von det2fe

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

Weil die Fritzbox dann eben nicht Router ist. Das wurde ja explizit gewünscht.

Haegar: Die Fritzbox arbeitet in dem Fall als Router. Deshalb ja die Doppel-NAT Konfiguration. Du hast dann zwei Router hintereinander. Das meinte ich mit Nachteil, und das meinte ich, wenn ich schrieb, dass man sehr genau wissen sollte, was man tut, wenn man sowas macht.

Zitat von Haegar

Es sollte doch auch möglich sein den gelieferten Router nur als Modem zu nutzen und eine 4040 oder 4060 als Router einzusetzen.

Ich weiß nicht, ob es möglich ist, diese Geräte quasi in einen transparenten Modus zu versetzen. Was aber natürlich immer möglich ist: Eine Fritzbox hinter den Movistar Router zu hängen, auch wenn der noch als Router arbeitet. Das hat natürlich Nachteile, weil man damit eine Doppel-NAT Konstellation baut. Aber wenn man unbedingt auf eine Fritzbox setzen will, wäre das ein Weg.

Zitat von matzek

Und kann der festellen von extern , daß dort eine andere Glasfaserbox

angeschlossen ist?

Ja, das kann er.

Was an der DG Anleitung interessant ist: Man klemmt die Box direkt nach einem Recovery oder Werksreset an die Glasfaserleitung. Dann bekommt sie eine IP Verbindung, über den sie aktiviert werden kann. Zu der Zeit hat man noch überhaupt keine Zugangsdaten, Seriennummern oder ONT Kennungen eingegeben. Die Box geht quasi ohne spezifische Daten online.

Ich frag mich, wie der Prozess dahinter aussieht. Ist die initiale Verbindung quasi eine Default Verbindung nur für die Aktivierung? Werden dabei dann die spezifischen GPON Zugangsdaten übermittelt, die für die spezifische Kundenverbindung benötigt werden?

Ich frage mich, wie du von der Beschreibung auf eine 5530 schließt. Das ist eine Spezifikation für ein SFP Modul, aber nicht für einen Router.

Damit hast du dann im Grunde genau die Infos, die du für die Anschaffung eines SFP Module benötigst. Beispiele für Medienkonverter und SFP Module finden sich schon einige im Forum, auch passend zu diesen Specs.

Drei Dinge wundern mich.

Warum funktioniert nur Version 7.26? Keine neuere? Und warum wird der Firefox Browser nicht unterstützt? Und woher kommt die symmetrische Verbindungsgeschwindigkeit mit 1 GBit/s?

Aber schön, dass die DG nun einen Prozess dafür hat, der offenbar sogar automatisiert abläuft, so dass kein Kontakt zum Kundenservice nötig ist.

Zitat von James

Selbst eine Sekunde wäre ja ein 1000er Ping

Es geht hier glaube ich nicht um Ping, sondern eher um eine Reaktionszeit auf Applikationsebene. Also z.B. Cst sagt was zu seinem Google Home, und der gönnt sich dann erst mal eine Gedenkpause, bevor er antwortet oder aktiv wird.