Unitymedia Technicolor TC4400 Docsis 3.1 Modem Info Thread

[tq1199]

Ich habe nun kein Defaultgateway mehr eingetragen, komme dennoch auf das Modem.

OK, danke für den Test. D. h. die Datenpakete werden gezielt an die IP-Adresse 192.168.100.1 gesendet und müssen nicht auf dem Weg zum default gateway (CMTS?), "rausgefischt" werden.

EDIT:

Ich denke, das "Rausfischen" wäre ja schon eine Art von "man-in-the-middle" (MITM), wenn das Modem die Datenpakete die für einen Weg via default gateway (CMTS?) vorgesehen sind abfängt und dann auch noch in der Lage ist, eine gültige/akzeptierte Antwort zu generieren, so dass das absendende System, diese Antwort auch akzeptiert, die nicht via default gateway (CMTS?) zurück kommt ..., oder?

 

[rv112]

Davon ist wohl auszugehen. Evtl. liegt es an meinen Outbound NAT Regeln.

 

[tq1199]

Davon ist wohl auszugehen. Evtl. liegt es an meinen Outbound NAT Regeln.

M. E. nicht, denn deine "Outbound NAT Regeln" sind doch source-NAT-Regeln (masquerading), damit die Antwort weiß aus welchem Subnetz die Anfrage gekommen ist bzw. diese dann dort hin geleitet wird. D. h., die Regeln haben m. E. etwas mit dem Rückweg zu tun, aber nicht mit dem Hinweg.

 

[rv112]

Ja, das sollte so sein. Aber vielleicht bekomme ich deshalb Antwort und andere nicht?

 

[tq1199]

Aber vielleicht bekomme ich deshalb Antwort und andere nicht?

Ja, ... wäre möglich bzw. denkbar. Dann sollen die Anderen für ihren Test, auch ein System verwenden bei dem sie source-NAT konfigurieren können.

 

[#DiRK]

Ich habe nun kein Defaultgateway mehr eingetragen, komme dennoch auf das Modem.

OK, danke für den Test. D. h. die Datenpakete werden gezielt an die IP-Adresse 192.168.100.1 gesendet und müssen nicht auf dem Weg zum default gateway (CMTS?), "rausgefischt" werden.

EDIT:

Ich denke, das "Rausfischen" wäre ja schon eine Art von "man-in-the-middle" (MITM), wenn das Modem die Datenpakete die für einen Weg via default gateway (CMTS?) vorgesehen sind abfängt und dann auch noch in der Lage ist, eine gültige/akzeptierte Antwort zu generieren, so dass das absendende System, diese Antwort auch akzeptiert, die nicht via default gateway (CMTS?) zurück kommt ..., oder?

Irritierend finde ich, dass in @rv112 Beitrag mit der Routing Tabelle

Routing tables

Internet:
Destination Gateway Flags Netif Expire
default 134.3.212.1 UGS re1
10.0.0.0/24 link#9 U re2.100
10.0.0.1 link#9 UHS lo0
127.0.0.1 link#4 UH lo0
134.3.212.0/22 link#2 U re1
134.xxx.xxx.xxx link#2 UHS lo0
192.168.1.0/24 link#3 U re2
192.168.1.1 link#3 UHS lo0
192.168.3.0/24 192.168.3.2 UGS ovpns1
192.168.3.1 link#10 UHS lo0
192.168.3.2 link#10 UH ovpns1

und dem anschließenden Weglassen der Default Route überhaupt ein Paket mit Zieladresse 192.168.100.0/24 das Interface re1 verlässt. Meines Wissens sollte er (da keine valide Route gefunden) direkt eine Fehlermeldung erhalten?!?!?!?!

 

[rv112]

Dachte ich mir auch, aber die pfSense konnte es pingen und die Clients auch.

 

[#DiRK]

Dachte ich mir auch, aber die pfSense konnte es pingen und die Clients auch.

Bei der pfSense hattest du, glaub ich, explizit das Interface (WAN = re1) ausgewählt und somit vermutlich das Routing umgangen. Das mag eine Erklärung sein, dass ein Paket über re1 mit Zieladresse 192.168.1.100 vom Modem "gefischt" / empfangen wird.

Bei den Clients jedoch geht das nicht. Hier müsste m.E. das Routing voll zuschlagen und da keine Route für 192.168.100.0/24 existiert (auch keine Default Route) das Paket verworfen werden. Hier hilft auch nicht das Source NATting, da das m.E. erst nach dem Routing statt findet.

 

[tq1199]

Bei den Clients jedoch geht das nicht. Hier müsste m.E. das Routing voll zuschlagen und da keine Route für 192.168.100.0/24 existiert (auch keine Default Route) das Paket verworfen werden.

Naja, bei seinen Clients wird er die pfsense als default route eingetragen haben, und die pfsense erledigt den "Rest", auch wenn sie als default gateway für die Clients, selber keine default route hat.

 

[rv112]

Richtig. Meine Clients kennen nur die pfSense als Gateway.

 

[#DiRK]

Bei den Clients jedoch geht das nicht. Hier müsste m.E. das Routing voll zuschlagen und da keine Route für 192.168.100.0/24 existiert (auch keine Default Route) das Paket verworfen werden.

Naja, bei seinen Clients wird er die pfsense als default route eingetragen haben, und die pfsense erledigt den "Rest", auch wenn sie als default gateway für die Clients, selber keine default route hat.

Was meinst du mit "den Rest"? Ganz im Gegensatz zu manchen Routern oder Frust-/Fritzboxen ist pfSense kein "Voodoo-Kästchen". Sie macht was ein anständiger Router machen soll:
- IP-Routing entsprechend der eigenen Routing Tabellen
- NATting
- etc

Wenn ein Verhalten nicht in das Schema passt, dann sollte man m.E. verstehen warum. Insbesondere wenn man (in diesem Thread) versucht das Verhalten vom TC4400 zu verstehen.

Warum ist das TC4400 auf Layer 3 unterwegs, wo es nichts zu suchen hat? Warum reagiert es auf IP 192.168.100.1? Vielleicht auch auf andere IPs (aus RFC1918 Subnetzen)? Vielleicht auch auf bestimmte Parametern (z.B. UDP, TCP oder bestimmte Ports) auf Layer 4 (siehe Problem von @Andreas1969)? Was ist mit anderen Non-IP Protokollen?

 

[tq1199]

Was meinst du mit "den Rest"?

Mit "Rest" meine ich das was man sieht, wenn man von einem Client an der pfsense ein traceroute auf die IP-Adresse 192.168.100.1 (Modem) macht.

Als einziger hop (im traceroute) zwischen dem Client und dem Modem (192.168.100.1) sieht man die IP-Adresse (192.168.1.1) der pfsense (... die aber dafür auch keine default route haben muss).

 

[#DiRK]

Was meinst du mit "den Rest"?

Mit "Rest" meine ich das was man sieht, wenn man von einem Client an der pfsense ein traceroute auf die IP-Adresse 192.168.100.1 (Modem) macht.

Als einziger hop (im traceroute) zwischen dem Client und dem Modem (192.168.100.1) sieht man die IP-Adresse (192.168.1.1) der pfsense (... die aber dafür auch keine default route haben muss).

Klar, vom Client siehst du als ersten Hop die pfSense, da sie ja beim Client als Default Gateway eingetragen ist. Aber erkläre mir bitte, wie dann die pfSense mit dem ankommenden Paket verfährt (Ziel IP = 192.168.100.1), wenn sie keine Route hat (weder 192.168.100.0/24 oder Default)? Woher weiß die pfSense auf welchem Interface sie das Paket weiter schicken soll? Könnte ja auch Loopback sein oder das VPN Interface?

Aber letztendlich hilft es nix die pfSense zu analysieren. Eigentlich geht es um das TC4400, welches uns interessiert.

 

[tq1199]

Aber erkläre mir bitte, wie dann die pfSense mit dem ankommenden Paket verfährt (Ziel IP = 192.168.100.1), wenn sie keine Route hat (weder 192.168.100.0/24 oder Default)? Woher weiß die pfSense auf welchem Interface sie das Paket weiter schicken soll? Könnte ja auch Loopback sein oder das VPN Interface?

Das kann ich dir nicht genau erklären. Wir haben hier in diesem Thread, nur gemeinsam getestet bzw. festgestellt, dass diese Art von Verbindung zwischen Modem und Gerät (hier pfsense) möglich ist. Andere Besitzer des TC4400 waren bzw. sind z. Zt. noch nicht bereit so einen Test durchzuführen.

Aber letztendlich hilft es nix die pfSense zu analysieren. Eigentlich geht es um das TC4400, welches uns interessiert.

Naja, wir analysieren die Verbindung bzw. das Verhalten der pfsense mit bzw. am TC4400. Z. B. ein Linux-PC direkt an dem TC4400, wird sich nicht anders verhalten.

 

[#DiRK]

Das kann ich dir nicht genau erklären. Wir haben hier in diesem Thread, nur gemeinsam getestet bzw. festgestellt, dass diese Art von Verbindung zwischen Modem und Gerät (hier pfsense) möglich ist. Andere Besitzer des TC4400 waren bzw. sind z. Zt. noch nicht bereit so einen Test durchzuführen.

Da stimme ich dir zu: wir werden das TC4400 nur kennen lernen, wenn wir entsprechende Tests durchführen.

Naja, wir analysieren die Verbindung bzw. das Verhalten der pfsense mit bzw. am TC4400. Z. B. ein Linux-PC direkt an dem TC4400, wird sich nicht anders verhalten.

Auch hier stimme ich dir zu. Es ist egal ob Linux Box oder BSD mit pfSense. Hauptsache es ist ein richtiges Betriebssystem (nicht Windows) mit entsprechenden Tools nicht nicht gerade eine Frust-/Fritzbox.

 

[rv112]

Ich warte im anderen Thread ja noch immer auf mein TC4400. Sobald ich da etwas ergatter, mach ich damit weiter, wenn auch erst mal unprovisioniert. Ich gehe davon aus, dass es daran liegt dass mir UM als Gateway deren CMTS (?) mitteilt. Demnach gehen auch die RFC1918 Adressen die die pfSense nicht kennt raus und werden dort verworfen. Das Modem scheint sich seine Adresse jedoch rauszufischen und zu beantworten. Das TC4400 dürfte sich da gleich verhalten, da wohl alle DOCSIS Modem über diese IP erreichbar sind.

 

[tq1199]

Ich gehe davon aus, dass es daran liegt dass mir UM als Gateway deren CMTS (?) mitteilt. Demnach gehen auch die RFC1918 Adressen die die pfSense nicht kennt raus und werden dort verworfen.

Für einen weiteren Test könntest Du auch das verhindern, in dem Du auf das Modem zugreifst während dieses _keine_ (Kabel-)Verbindung zum CMTS hat. Oder in dem Du im border device (bei dir die pfsense) den arp-cache-Eintrag für das CMTS löscht.

 

[rv112]

Das CMTS hab ich ja schon aus dem ARP Table gelöscht und kam dennoch auf das Modem. Einen Neustart des Modems inkl. Neustart der pfSense kann ich mal testen. Ohne Neustart der pfSense komme ich definitiv aufs Modem, auch wenn es noch nicht mal mit dem CMTS verbunden, geschweige denn provisioniert ist.

 

[tq1199]

... komme ich definitiv aufs Modem, auch wenn es noch nicht mal mit dem CMTS verbunden, ...

Genau mit dieser Konstellation sollte weiter getestet werden, warum das möglich ist?

 

[Andreas1969]

Wer sich auch an der Suche des Passworts für's Web IF des TC4400 beteiligen möchte, hier mal ein Link aus dem VF Forum. Ich hab mich da mal in einen Thread für das TC4400 eingeklinkt.
https://www.kdgforum.de/viewtopic.php?f=68&t=38748

 

[SpookyMulder]

Wer sich auch an der Suche des Passworts für's Web IF des TC4400 beteiligen möchte, hier mal ein Link aus dem VF Forum. Ich hab mich da mal in einen Thread für das TC4400 eingeklinkt.
https://www.kdgforum.de/viewtopic.php?f=68&t=38748

Ich behaupte mal gekapert, da im Ursprungsthread garnicht nach Passwörtern gefragt wurde.

 

[Andreas1969]

Ich behaupte mal gekapert, da im Ursprungsthread garnicht nach Passwörtern gefragt wurde.

Meinetwegen auch gekapert :zwinker:
Wenn es dafür der Sache dienlich ist.
Da profitieren ja nachher alle von, die ein solches Gerät betreiben (möchten) :super:

 

[Flole]

Ja mein Thread da drüben wurde gekapert, aber das macht nix denn jetzt bin ich ja hier und alles hat wieder seine Ordnung.

Hat schon irgendwer mal versucht mithilfe der von mir angegebenen SNMP Communities etwas zu erreichen? Wird aber wahrscheinlich auf das jeweilige Modem/den jeweiligen Kunden spezifisch sein. Also jeder kriegt zufällige Zugangsdaten aber daran sollte es ja eigentlich nicht scheitern die eben auszulesen und von hex zu ascii zu konvertieren.

 

[nts]

Hat schon irgendwer mal versucht mithilfe der von mir angegebenen SNMP Communities etwas zu erreichen? Wird aber wahrscheinlich auf das jeweilige Modem/den jeweiligen Kunden spezifisch sein.

Sieht so aus, ich hatte mit keiner davon Erfolg. Vielleicht wird aber auch noch zusätzlich nach der Provisionierung SNMP auf Nutzerseite deaktiviert. Davor funktioniert aber auf jeden Fall public: https://www.unitymediaforum.de/viewtopic.php?p=389279#p389279

 

[Flole]

Hat schon irgendwer mal versucht mithilfe der von mir angegebenen SNMP Communities etwas zu erreichen? Wird aber wahrscheinlich auf das jeweilige Modem/den jeweiligen Kunden spezifisch sein.

Sieht so aus, ich hatte mit keiner davon Erfolg. Vielleicht wird aber auch noch zusätzlich nach der Provisionierung SNMP auf Nutzerseite deaktiviert. Davor funktioniert aber auf jeden Fall public: https://www.unitymediaforum.de/viewtopic.php?p=389279#p389279

Das Modem sollte unmöglich unterscheiden können von wo nun die Anfrage kommt (welche Schnittstelle). Ich hab aber drüben im KDG Forum schonmal festgestellt, das Public auf einen IP adressbereich limitiert ist. Lediglich die Passwörter sind unlimitiert.