Unifi UDM pro mit GPON Modul

Vielen Dank nochmal für die Antwort!

Zitat von frank_m

Es soll keine überzogene Kritik sein, aber es fällt mal wieder auf, dass sich Leute semiprofessionelles Equipment kaufen, die nicht mal Grundlagenwissen über Netzwerk-Konfiguration und Diagnose haben.

Völlig legitim, ich weiß wirklich nicht wo ich anfangen soll, aber darum frage ich ja und bin um jeden Tipp in die richtige Richtung froh, man wächst doch mit seinen Aufgaben

Ich hatte ja schon von der UDM versucht einen Ping zum Gateway zu machen und nachdem das nicht geklappt hat, bin ich nicht auf die Idee gekommen noch ein traceroute zu probieren.

Ich kann ja mal hier einfügen was ich gerade noch alles versucht habe:

(Die Outputs sind innerhalb der Spoiler)

(Ich habe nach dem Factory Reset nichts geändert an der UDM, also die Regeln sollten alle Standard sein)

Die letzte Nachricht wurde zu lang, ich habe noch probiert:

Ich habe während dem tcpdump auch mal das Glasfaser Kabel abgesteckt, dann haben die Anfragen abgebrochen. Als ich es wieder eingesteckt habe, kamen wieder fast nur ARP Requests, aber bei weitem nicht mehr so viele wie oben, sondern nur noch alle paar Sekunden.

Kann jemand irgendwas hieraus schließen? Oder hat noch irgend einen Tipp für mich was ich noch versuchen könnte?

Vielen Dank nochmal!

Die ARP Requests sind ein gutes Zeichen, denn das sind ankommende Pakete. Dein Interface funktioniert augenscheinlich korrekt. Jedenfalls kommen Pakete aus dem Internet an. Du versuchst nur nicht, welche zu senden.

Du hast vergessen, die Routen zu zeigen. Arbeite besser mit ip anstatt mit den alten ifconfig Tools. Ich vermute ein größeres Problem bei den Routen.

Das !H in der Ausgabe des traceroute deutet schon ein wenig auf eine unstimmige Konfiguration von Routen hin. Es bedeutet "destination host unreachable".

Wie von frank_m angeregt, zeige doch bitte die Ausgabe von

ip route

Ich habe folgende Ausgabe bekommen:

46.128.193.0/24 dev eth9 proto kernel scope link src 46.128.193.220
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1

Das ist in der Tat komisch, dass es keinen default gibt, oder?

Ich habe folgendes probiert:

ip route add default via 46.128.193.1

default via 46.128.193.1 dev eth9
46.128.193.0/24 dev eth9 proto kernel scope link src 46.128.193.220
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1

Aber ich bekomme nach wie vor das selbe Ergebnis:

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 46 byte packets
 1  46.128.193.220 (46.128.193.220)  852.953 ms !H  3084.074 ms !H  3067.904 ms !H

Und wenn ich während des traceroute den tcpdump --interface=eth9 weiter laufen lasse, schlägt dort auch außer den ARP-Requests nach wie vor nichts auf.

Ich habe auch noch versucht ip route replace default via 46.128.193.220, das macht vermutlich keinen Sinn, hat auch genauso wenig funktioniert...

Wenn ich den tcpdump beende, dann steht da:

115 packets captured
8766 packets received by filter
8620 packets dropped by kernel

Habt ihr eine Idee warum da so viele packets dropped by kernel sind?

Edit: Folgendes ist Quatsch:

Ich habe auch noch folgendes probiert:

tcpdump -ni lo tcp -c 20 --interface=eth9

und:

tcpdump -ni lo udp -c 20 --interface=eth9

Aber mein traceroute taucht auch hier nicht auf!

Vielen Dank nochmal für eure Hilfe!

Du filterst den tcpdump nur auf Protokollnummer 17/UDP! Traceroute, ping etc. arbeiten per Default mit ICMP (Protokollnummer 1)! Also: tcpdump -ni lo icmp -c 20 --interface=eth9

Und warum du das loopback Interface hinzuziehst, wird auch nicht klar. Warum machst du das?

Ist das Gateway denn richtig? Um das herauszufinden, musst du die DHCP Antwort vom Provider auswerten, das geht u. a. auch mit tcpdump. Natürlich musst du in der Lage sein, den zu sniffen, d. h.: UDM rebooten ohne Glasfaserverbindung, sicherstellen, dass es keine IPs auf eth9 gibt, tcpdump starten und dann das Kabel anstöpseln. tcpdump könntest du mit -vv starten, um mehr zu sehen. Oder noch besser: schreibe mit -w dump.pcap die Paketaufzeichnung weg und schaue es dir später mit Wireshark am PC an.

Wie dem auch sei, die UDM sollte selber in der Lage sein, nach einer DHCP Antwort seitens des Providers die Routen und DNS-Server selbständig einzurichten. Da musst du dir also noch mal die Anleitung hernehmen und die Internetkonfiguration glattziehen. Da stimmt noch was Größeres nicht.

Zitat von frank_m

Und warum du das loopback Interface hinzuziehst, wird auch nicht klar. Warum machst du das?

Sorry, das ist Quatsch, das war copy paste bei dem Versuch eine Lösung für die dropped packets zu finden 🙈

Ich habe ein DHCP Reply nach dem Neustart der UDM gecaptured:

IP (tos 0xc0, ttl 30, id 14564, offset 0, flags [none], proto UDP (17), length 406)
    46.128.193.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 378, xid 0x1326f357, Flags [none] (0x0000)
      Your-IP 46.128.193.220
      Gateway-IP 46.128.193.1
      Client-Ethernet-Address d0:21:f9:79:24:a6
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: ACK
        Server-ID Option 54, length 4: 172.28.216.14
        Lease-Time Option 51, length 4: 6948
        Subnet-Mask Option 1, length 4: 255.255.255.0
        Default-Gateway Option 3, length 4: 46.128.193.1
        Domain-Name-Server Option 6, length 8: 195.234.128.139,217.68.162.53
        RN Option 58, length 4: 3348
        RB Option 59, length 4: 6048
        Hostname Option 12, length 12: "D021F97924A6"
        Vendor-Option Option 43, length 72: 1.70.104.116.116.112.115.58.47.47.112.114.111.118.97.99.115.46.109.105.112.45.112.108.97.116.102.111.114.109.46.110.101.116.58.55.53.52.55.47.108.105.118.101.47.67.80.69.77.97.110.97.103.101.114.47.67.80.69.115.47.103.101.110.101.114.105.99.84.82.54.57

Könnt ihr damit was anfangen?

Nochmals danke!

Das sieht sehr gut aus. IP, Gateway und DNS Server sind da. Das Gateway liegt auch im lokalen Subnetz, also alles gut.

Jetzt musst du die UDM nur noch davon überzeugen, die Informationen aus der DHCP Antwort auch ins System zu übernehmen, Sprich: Adresse, Subnetzmaske, Gateway und DNS Server setzen. Dabei die Lease Time nicht aus den Augen verlieren, um rechtzeitig eine Verlängerung zu beantragen.

Hmm, Addresse und Subnetzmaske sind ja schon übernommen, oder:

Zitat von demolitionfabi

ifconfig eth9

inet addr:46.128.193.220 Bcast:0.0.0.0 Mask:255.255.255.0

inet6 addr: fe80::d221:f9ff:fe79:24a6/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:268698 errors:0 dropped:0 overruns:0 frame:0

TX packets:3321 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:10000

RX bytes:11296771 (10.7 MiB) TX bytes:245140 (239.3 KiB)

Alles anzeigen

Und das Gateway habe ich ja auch schon versucht nochmal manuell zu setzen:

Zitat von demolitionfabi

Ich habe folgende Ausgabe bekommen:

Code: ip route

46.128.193.0/24 dev eth9 proto kernel scope link src 46.128.193.220
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1

Das ist in der Tat komisch, dass es keinen default gibt, oder?

Ich habe folgendes probiert:

ip route add default via 46.128.193.1

Na und mein traceroute -i eth9 8.8.8.8 sollte ja auch ohne DNS funktionieren...

Also ich habe leider keine Idee, was ich noch versuchen könnte

Was sagt mir denn diese Vendor-Option Option 43? Die brauche ich nicht für irgendwas?

Danke nochmal!

Zitat von demolitionfabi

Na und mein traceroute -i eth9 8.8.8.8 sollte ja auch ohne DNS funktionieren...

Versuche es mal ohne das -i eth9. Hast du mit tcpdump untersucht, welche Absender-Adresse der traceroute bzw. der ping nimmt? Gibt es entsprechende Firewall Regeln, die den Traffic erlauben und NAT für die privaten Adressen machen?

Ich habe es auch schon ganz ohne -i eth9 und auch schon mal mit -s 46.128.193.220 probiert, aber das Problem ist ja, dass meine pings und traceroutes im tcpdump gar nicht erscheinen!

Woran könnte das denn liegen?

Also hier sollte es ja unabhängig von einem eingestellten NAT funktionieren, oder:

Zitat von demolitionfabi

traceroute -s 46.128.193.220 8.8.8.8

traceroute to 8.8.8.8 (8.8.8.8) from 46.128.193.220, 30 hops max, 46 byte packets

1 46.128.193.220 (46.128.193.220) 3071.339 ms !H 3071.421 ms !H 3075.477 ms !H

Firewall Regeln habe ich keine eingestellt, ich habe die UDM wie gesagt auf Werkseinstellungen zurückgesetzt und gehe davon aus, dass die Standardeinstellungen passen sollten, oder?

Ich hatte sie auch schon mal gepostet, kann man damit was anfangen?

Zitat von demolitionfabi

iptables -L

Chain INPUT (policy ACCEPT)

target prot opt source destination

UBIOS_INPUT_JUMP all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)

target prot opt source destination

UBIOS_FORWARD_JUMP all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

UBIOS_OUTPUT_JUMP all -- anywhere anywhere

Chain UBIOS_FORWARD_IN_USER (1 references)

target prot opt source destination

UBIOS_WAN_IN_USER all -- anywhere anywhere /* 00000001095216663481 */

UBIOS_WAN_IN_USER all -- anywhere anywhere /* 00000001095216663482 */

UBIOS_LAN_IN_USER all -- anywhere anywhere /* 00000001095216663483 */

Chain UBIOS_FORWARD_JUMP (1 references)

target prot opt source destination

UBIOS_FORWARD_USER_HOOK all -- anywhere anywhere

Chain UBIOS_FORWARD_OUT_USER (1 references)

target prot opt source destination

UBIOS_WAN_OUT_USER all -- anywhere anywhere /* 00000001095216663481 */

UBIOS_WAN_OUT_USER all -- anywhere anywhere /* 00000001095216663482 */

UBIOS_LAN_OUT_USER all -- anywhere anywhere /* 00000001095216663483 */

Chain UBIOS_FORWARD_USER_HOOK (1 references)

target prot opt source destination

UBIOS_FORWARD_IN_USER all -- anywhere anywhere /* 00000001095216663481 */

UBIOS_FORWARD_OUT_USER all -- anywhere anywhere /* 00000001095216663482 */

Chain UBIOS_INPUT_JUMP (1 references)

target prot opt source destination

UBIOS_INPUT_USER_HOOK all -- anywhere anywhere

Chain UBIOS_INPUT_USER_HOOK (1 references)

target prot opt source destination

UBIOS_WAN_LOCAL_USER all -- anywhere anywhere /* 00000001095216663481 */

UBIOS_WAN_LOCAL_USER all -- anywhere anywhere /* 00000001095216663482 */

UBIOS_LAN_LOCAL_USER all -- anywhere anywhere /* 00000001095216663483 */

Chain UBIOS_IN_GEOIP (0 references)

target prot opt source destination

Chain UBIOS_LAN_IN_USER (1 references)

target prot opt source destination

RETURN all -- 192.168.1.0/24 anywhere /* 00000001095216666481 */

RETURN all -- anywhere anywhere /* 00000001097364144127 */

Chain UBIOS_LAN_LOCAL_USER (1 references)

target prot opt source destination

RETURN all -- anywhere anywhere /* 00000001097364144127 */

Chain UBIOS_LAN_OUT_USER (1 references)

target prot opt source destination

RETURN all -- anywhere 192.168.1.0/24 /* 00000001095216666481 */

RETURN all -- anywhere anywhere /* 00000001097364144127 */

Chain UBIOS_OUTPUT_JUMP (1 references)

target prot opt source destination

Chain UBIOS_OUTPUT_USER_HOOK (0 references)

target prot opt source destination

Chain UBIOS_OUT_GEOIP (0 references)

target prot opt source destination

Chain UBIOS_WAN_IN_USER (2 references)

target prot opt source destination

RETURN all -- anywhere anywhere ctstate RELATED,ESTABLISHED /* 00000001095216663481 */

DROP all -- anywhere anywhere ctstate INVALID /* 00000001095216663482 */

DROP all -- anywhere anywhere /* 00000001097364144127 */

Chain UBIOS_WAN_LOCAL_USER (2 references)

target prot opt source destination

RETURN all -- anywhere anywhere ctstate RELATED,ESTABLISHED /* 00000001095216663481 */

DROP all -- anywhere anywhere ctstate INVALID /* 00000001095216663482 */

DROP all -- anywhere anywhere /* 00000001097364144127 */

Chain UBIOS_WAN_OUT_USER (2 references)

target prot opt source destination

RETURN all -- anywhere anywhere /* 00000001097364144127 */

(Ich habe nach dem Factory Reset nichts geändert an der UDM, also die Regeln sollten alle Standard sein)

Alles anzeigen

Ich habe auch mal versucht, die UDM bei meinem Eltern über den RJ45 WAN Port an einen Port der Fritz Box zu hängen, dann funktioniert alles einwandfrei (NAT etc.)...

Zitat von demolitionfabi

das Problem ist ja, dass meine pings und traceroutes im tcpdump gar nicht erscheinen!

Woran könnte das denn liegen?

Zum Beispiel an der Firewall. Die Pakete werden nicht zum externen Interface durchgelassen, z.B., weil die Absenderadresse nicht passt, oder weil die Firewall es nicht zulässt. Du kannst auch mal mit "tcpdump -i any" schauen, ob die Pakete auf einem anderen Interface auftauchen. Auch das kann ein Hinweis auf fehlerhaftes Routing sein.

Zitat von demolitionfabi

Firewall Regeln habe ich keine eingestellt, ich habe die UDM wie gesagt auf Werkseinstellungen zurückgesetzt und gehe davon aus, dass die Standardeinstellungen passen sollten, oder?

Oh nein, davon gehe ich nicht aus. Das passt ja schon bei Heimroutern nicht, viel weniger bei professionellen Geräten. Du wirst präzise einstellen müssen, was auf deinen Interfaces erlaubt ist und welcher Traffic rein und rauskommt. Im Speziellen die NAT Regeln musst du selber setzen. In deine Ausgabe sieht man, dass für die Output Chain einfach gar nichts vorhanden ist, und für WAN sind sowohl eingehend als auch ausgehend nur DROP Regeln zu sehen.

Zitat von demolitionfabi

Ich hatte sie auch schon mal gepostet, kann man damit was anfangen?

Das sind aber auch nur die aus der "filter" Table. Die aus den anderen Tables, z.B. nat oder mangle, fehlen.

Zitat von demolitionfabi

Was sagt mir denn diese Vendor-Option Option 43? Die brauche ich nicht für irgendwas?

Die DHCP Option 43 wird üblicherweise für die Fernkonfiguration verwendet. Beispielsweise wird darüber die URL des Auto Configuration Server (ACS) übermittelt um via tr069 das Endgerät zu konfigurieren. Es sind jedoch noch andere Szenarien möglich.

Vendor-specific option (Option 43)

Wenn ich es richtig interpretiere, dann ist das bei diesem Eintrag ebenfalls so. Die ASCII-Zeichen sind in deiner Ausgabe dezimal kodiert: 104.116.116.112.115 entspricht https

HubeBube Alles klar, verstehe, vielen Dank, das ist dann aber sicher nichts was ich brauche, damit mein Ping oder traceroute funktioniert...

Zitat von frank_m

In deine Ausgabe sieht man, dass für die Output Chain einfach gar nichts vorhanden ist, und für WAN sind sowohl eingehend als auch ausgehend nur DROP Regeln zu sehen.

Für die Output Chain steht aber die Policy auf ACCEPT, das heißt doch wenn sonst keine Regel vorhanden ist, dann sollte doch alles akzeptiert werden, oder?

Und für WAN steht ja die Policy auch auf ACCEPT und die DROP Regeln sagen

• für IN: RETURN (also accept) falls ctstate RELATED,ESTABLISHED und nur ansonsten DROP
• für OUT: RETURN all (also alles akzeptieren)

Also für mich klingt das plausibel (falls ich es richtig verstanden und zusammengefasst habe), aber ich kenne mich damit auch wirklich nicht besonders gut aus...

Und mangle und nat sollten doch meines Erachtens auch keine Pakete wegfiltern... oder?

Mit "tcpdump -i any" schließe ich ja auch das Interface mit ein mit dem ich meinen PC verbunden habe und es zeigt so unendlich viel Traffic an, dass ich überhaupts nichts mehr finde...

Ich befürchte, dass ich einsehen sollte, dass mein Wissen nicht ausreicht und ich mir einen ONT von meinem ISP setzen lasse

(wobei es am Ende ja das gleiche ist, nur dass ich an dem RJ45 Port über DHCP meine Daten vom ONT bekomme, statt an dem SFP+ Port direkt über die Glasfaser)

Vielen Dank nochmal an alle für die Mühe und wenn noch jemand eine Idee hat bin ich natürlich auch dankbar.

Ich werde dann wenn der ONT installiert wurde auch mal versuchen, die Seriennummer des ONT in mein SFP Modul zu klonen und die MAC Adresse der UDM auf die des ONT zu stellen und dann nochmal versuchen, ob es nach wie vor das gleiche Problem gibt und hier berichten...

Zitat von demolitionfabi

Für die Output Chain steht aber die Policy auf ACCEPT, das heißt doch wenn sonst keine Regel vorhanden ist, dann sollte doch alles akzeptiert werden, oder?

Wenn klar ist, wie man da hinkommt, dann kann das sein.

Zitat von demolitionfabi

Und mangle und nat sollten doch meines Erachtens auch keine Pakete wegfiltern... oder?

Naja, wer weiß, was dan in den Pre- und Postrouting Regeln so angestellt wird? Auf jeden Fall müssen da die NAT Regeln fürs LAN rein. Bedenke; Für den Router sind die Forwarding Regeln wichtiger, als In- und Out Regeln. IP Forwarding an sich ist ja an?

Zitat von demolitionfabi

Mit "tcpdump -i any" schließe ich ja auch das Interface mit ein mit dem ich meinen PC verbunden habe und es zeigt so unendlich viel Traffic an, dass ich überhaupts nichts mehr finde...

Da musst du halt filtern. Entweder filterst du die Paketbomben raus (z.B. "not port 22" um SSH auszuschließen), oder du filterst präzise auf das, was du suchst (icmp oder udp oder was auch immer).

Zitat von demolitionfabi

(wobei es am Ende ja das gleiche ist, nur dass ich an dem RJ45 Port über DHCP meine Daten vom ONT bekomme, statt an dem SFP+ Port direkt über die Glasfaser)

Das weiß ich eben nicht, ob das für die UDM das gleiche ist. Das musst du selber herausfinden, ob sie den SFP Port wie jeden anderen WAN Port behandelt.

Ich habe mir jetzt einen ONT von meinem ISP setzen lassen und habe zum testen in den gleichen WAN SFP Port von meiner UDM ein RJ45-SFP Modul gesetetzt und dort den ONT angesteckt:

Es hat auf Anhieb alles problemslos funktinoiert.

Also an der Konfiguration der UDM kann es nicht liegen, dass es nicht funktioniert die Glasfaser direkt an die UDM zu stecken. 🤔

Zitat von demolitionfabi

Also an der Konfiguration der UDM kann es nicht liegen, dass es nicht funktioniert die Glasfaser direkt an die UDM zu stecken.

Woran soll es denn sonst liegen? Natürlich liegt es an der Konfiguration.

Aber du hast ja jetzt ideale Voraussetzungen, die eingestellten Regeln und Routen zwischen RJ45 und Glasfaser zu vergleichen. Stimmt da alles? Gibt es auffällig Unterschiede, z.B. bei den IP-Adressen? Was ist mit IPv6? Ansonsten die Fragen von oben: Stimmen alle Parameter und Zugangsdaten? VLAN Tag etc.?

Wie gesagt, die Konfiguration, Regeln und Routen sind völlig identisch: Ich habe das RJ45 Modul in den selben SFP Slot gesteckt, in dem vorher der Zyxel war, ohne irgendetwas an der Konfiguration zu verändern.

Die IP Adresse, die ich über den ONT an dem RJ45 Modul bekomme ist auch die gleiche, wie die die ich vorher mit dem Zyxel direkt über die Glasfaser Leitung bekommen habe...

Ich habe die WAN Konfiguration auf Auto gestellt, ich denke da ist IPv6 standardmäßig deaktiviert.

Wenn ich es manuell auf DHCPv6 stelle, müsste ich eine Prefix Delegation Size angeben.

Vlan Tag ist deaktiviert, wenn ich das aktiviere, dann bekomme ich wie gesagt ja nicht mal mehr eine IP Addresse vom DHCP...

Also ich habe wirklich keine Idee was ich noch prüfen könnte

Wenn es mit dem RJ45-SFP Modul hinter dem ONT funktioniert würde ich es dabei belassen.

Wenn Du mit dem RJ45 SFP Modul nochmals einen tcpdump durchführst (wie in #28), ist die Option 43 noch sichtbar und gibt es ggf. Unterschiede?