Speedport: Automatische Konfiguration und DNS-Bug

Die Umstellung auf VDSL (50 Mbit/s Downstream, 10 Upstream, genau das, was der Admin braucht) lief, wie erwartet, nicht reibungslos. Als ich das »Entertain-Paket« bestellte, hatte ich darauf hingewiesen, dass wir zwar einen T-Online-Account haben, aber die Zugangsdaten seit dem Umzug verschollen sind, was uns bisher nicht gestört hat, weil wir T-Online z.Zt. nicht nutzen (der kostete nur ein paar Euro im Monat und wir behielten ihn für Notfälle, weil man wohl schneller neue Daten für einen bestehenden Account bekommt als einen ganz neuen Account). Das sei gar kein Problem, meinte die nette Dame, die den Auftrag entgegennahm, ich brauche keine Zugangsdaten, der neue Router konfiguriere sich nämlich automatisch. Ich bekundete mein Erstaunen. Ja, meinte sie, weil VDSL nur mit T-Online funktioniere, werde der Anschluss vorkonfiguriert und der Router übernehme die Einstellungen sobald er angeschlossen sei, das könne aber bis zu vierzig Minuten dauern. Das ist ja mal schlau, dachte ich bei mir, reinstöpseln und es tut einfach, so sparen die sicher jede Menge Kundensupport.

Na, wenigstens erwies sich ein Teil der Aussage als korrekt — meine freenet-Zugangsdaten funktionierten nach der Umstellung tatsächlich nicht mehr… T-Online ohne Daten aber auch nicht. Ich weiß nicht genau, was der Router da »automatisch konfiguriert«, aber die Zugangsdaten sind es nicht. Die (kostenpflichtige!) T-Com-DSL-Hotline half weiter: »Ihre Kollegin meinte, der Router konfiguriert sich automatisch, da tut sich aber nichts und das Webinterface verlangt von mir eine Anschlusskennung, eine Mitbenutzernummer und sowas.« — »Natürlich, wir müssen doch wissen, wer Sie sind!« — »Bei meinem Telefon wissen Sie das doch auch, ohne dass ich mich vorher anmelden muss.« — »Das ist ja was ganz anderes, das hat damit nichts zu tun.« — »Und was genau konfiguriert der Router dann automatisch?« — Er faselte was von »technischen Einstellungen«, empörte sich nochmal darüber, dass jemand glauben könne, man könnte einfach so Internet haben, ohne vorher mehrere zwölfstellige Zahlen einzutippen, und forderte mich schließlich auf, mir von der (kostenpflichtigen) T-Com-Entertain-Hotline neue Zugangsdaten zuschicken zu lassen. Das haben wir dann getan. Wir verbrachten an dem Tag insgesamt über eine halbe Stunde in kostenpflichtigen Warteschlangen und hielten zur Belohnung einige Tage später tatsächlich frische T-Online-Zugangsdaten in der Hand.

Erste Tests zeigten, dass wir Connectivity hatten, aber die Namensauflösung hing. Die Ursache war schnell gefunden:



Der primäre Nameserver, 194.97.173.124 (ffm4.cns.mcbone.net), wird von freenet betrieben und spricht nicht mit T-Online-Kunden, drum hing die Namensauflösung. Der sekundäre Nameserver, 217.237.148.70 (d-lb-a01.isp.t-ipnet.de) ist ein Nameserver der Telekom. Die spannende Frage: wie kommt der freenet-Nameserver in die T-Online-Konfiguration des T-Com-Routers?

Hab ich ihn vielleicht in einem Anfall geistiger Umnachtung selbst so eingestellt? Nein, die DNS-Server lassen sich in diesem Router-Modell nicht manuell konfigurieren.

Hat ihn der Router vielleicht irgendwie aus meinem Netz bezogen? Nein, mein DHCP-Server liefert als Nameserver-Adresse die IP meines lokalen Nameservers, den ich betreibe, damit ich in meinem Heimnetz auch dann (interne) Namen auflösen kann, wenn das Internet mal kaputt ist.

Hat der Router die IP bei meinem Versuch, eine Verbindung mit freenet herzustellen, aufgeschnappt? Nein, lt. Aussage meines Kollegen bei freenet, auf dessen Cisco ich aufschlagen sollte, wenn ich mich mit meinem freenet-Account anmelde, hat er von mir seit der Umstellung meines Teilnehmeranschlusses auf VDSL keine Verbindungen mehr gesehen, d.h. es gab keinen PPP-Handshake und somit auch keine Gelegenheit, dem Router einen falschen Nameserver unterzuschieben.

Hat der Router diesen Nameserver vielleicht »erschnüffelt«? Mein lokaler Nameserver benutzt genau diesen Nameserver als ersten Forwarder: jede Anfrage, die mein Nameserver nicht selbst beantworten kann, leitet er an 194.97.173.124 weiter. Der Router könnte festgestellt haben, dass ich versucht habe, DNS-Anfragen an diese IP zu schicken. Aber warum sollte jemand in einen Router eine Funktion einbauen, die sich Datenpakete anguckt, um einen verwendeten DNS-Server zu ermitteln, wenn der Router doch bei jedem PPPoE-Verbindungsaufbau — also, dank Zwangstrennung, einmal pro Tag — vom Provider ausdrücklich mitgeteilt bekommt, welche Nameserver er verwenden soll?

Zwangstrennungen hat der Router inzwischen schon einige hinter sich, der freenet-Nameserver steht trotzdem weiter in der Konfiguration. Das kann mir aber egal sein. Jetzt läuft mein gesamter Traffic halt über OpenVPN zum Provider meines Vertrauens — und T-Router, T-Com, T-Online und T-Stasi sehen von mir nur noch verschlüsselten Datenmüll.

Nachtrag, 1. Februar 2009: Ich hab den Router jetzt mal auf die Werkseinstellungen zurückgesetzt, jetzt passen die DNS-Server. Dabei ist mir aufgefallen, dass er tatsächlich irgendwas automatisch konfiguriert: vor der Eingabe der T-Online-Zugangsdaten hat er bereits eine IP-Adresse, ein Gateway und Nameserver, er stellt aber kein Internet zur Verfügung, weder einem angeschlossenen Rechner noch dem »T-Home Media Receiver«. Vielleicht wird das ja genutzt, wenn man ausschließlich VoIP-Telefonie (die Telekom nennt das wohl »DSL-Telefonie«) betreiben will.

Das Webinterface hat (zumindest mit Firefox, mit einem anderen Browser hab ich es nicht getestet) noch einige Macken, z.B. lassen sich gespeicherte Einstellungen nicht laden, weil das Eingabefeld für den Dateinamen nicht dargestellt wird (mit dem Firefox-WebDeveloper-Plugin kann man aber ein bisschen in der FORM rumfummeln, um es sichtbar zu machen). Dooferweise werden die Nameserver zusammen mit den anderen Settings gespeichert, so dass nach der Wiederherstellung der alten Einstellungen ein weiterer Werksreset fällig war, um den freenet-Nameserver wieder los zu werden.

Bevor ich das VPN eingerichtet hatte, ist mir übrigens aufgefallen, dass der Router offene NAT-Verbindungen überraschend schnell droppt, ständig starben mir SSH-Shells weg. Als Workaround kann man die SSH-Option TCPKeepAlive einschalten und das ServerAliveInterval auf 60 Sekunden setzen.