Port Forwarding/WAG120N/Telekom

[epek]

Hallo!

Ich verwende zur Fernwartung bei typischen Privatnutzern, die halt nicht so EDV-fit sind und meine Hilfe gerne beanspruchen, normalerweise eine VNC-Verbindung, sei sie getunnelt (via ssh) oder ausnahmsweise per port forwarding.

Nun habe ich aber einen Teilnehmer, der einen Telekom Zugang (Aon Kombi) hat, bei dem Portforwarding schlicht nicht will:

Vorgeschichte:
TG585v6 (das mit antrazitfarbene mit den gelben Ports) mit einem WRT54GL (aktuellste originale Linksys-FW) mit Einzel-Port-Forwarding für 5900 stand dort. Es war schon der Wartungsport 8080/http(s) nicht erreichbar. (Fehler meinerseits ist freilich nicht ausgeschlossen, auch, wenn ich glaube, dass ich mein Werk an sich verstehe.)

Vor kurzem habe ich beide Geräte durch einen WAG120N ersetzt. Der Wartungsport funktioniert nun.
Was nach wie vor nicht geht, ist Portforwarding. Der Linksys-Support hat mir gegenüber einige Fehlfunktionen der Software bestätigt. So soll bei der aktuellen 1.00.12 Annex A angeblich das Web-Interface nur vollständig funktionieren, wenn die Sprache auf English eingestellt bleibt. Man riet zum Reflash, Default-Settings, Neuerstellen der Konfiguration.
Auch dies half jedoch nicht.

Seitens der Telekom wurden unterschiedliche Infos ausgegeben: Hotline: keine Ports werden gesperrt, Business-Hotline: bei Privatkunden wird Port 25 geblockt, Customer Service/Backoffice: Nur Port 25 würde gesperrt; zwei Tage später vom selben Mitarbeiter nach Rückfrage bei der Technik: für Port Forwarding ist ein Business-Zugang erforderlich...

Ich gehe davon aus, das die letzte Aussage der Telekom marketingtechnisch und nicht routertechnisch begründet ist und nehme weiters an, dass eingehende Ports generell offen sind, jedoch die 8-Stunden-Zwangstrennung weiter besteht. (DDNS ist freilich auf dem Router eingestellt und funktioniert). (Erreichbarkeit des Wartungsports auf unterschiedlichen Portnummern, je nach Konfiguration würde dieses Argument untermauern.)

Nach einigen Stunden im "Labor" mit einem WRT54GL, den ich mit unterschiedlichen Firmwares gegen einen hausinternen pptpd habe authentizieren lassen und der einige Portscans auf sein "externes" Interface erdulden mußte, habe ich letztlich die Sourcen der WAG120N GPL-Firmware durchgeschaut und einige Besonderheiten entdeckt, die ich freilich an Linksys weitergegeben habe. (m.E. wurde das Webinterface eines anderen Modells nur notdürftig an dieses Modell angepasst, was aus Überbleibseln im Source gut ersichtlich ist. Weiters ist mir aufgefallen, dass die Firmware im Configfile Settings für das WLAN mit einem "USA" speichert, obwohl die Firmware in den Defaultsettings "EU" annimmt.
Werden diese Geräte eigentlich jemals von irgendwelchen unabhängigen Instituten getestet?

Man riet zu eingangs erwähntem Vorgehen und zur Nutzung von Port Range Forwarding anstelle des Single P.Fw..
Auch Tests mit ein/ausgeschalteter SPI-Firewall und der DMZ blieben erfolglos.

Zur Gegenprobe steht hinter dem WAG120N in einer Switch-to-Switch-Verbindung noch ein zweiter Router, der als AccessPoint arbeitet und ein Webinterface auf Port 80/HTTP laufen hat. Auch hierfür habe ich ein Forward, respektive auch die DMZ ausprobiert - negativ (pingen kann man ihn aber vom WAG120N).

Warum schreibe ich Euch diese Unmengen Text? - Nun, ich suche Antworten und glaube, dass sich hier ein paar Mitstreiter tummeln. Meine Fragen:

1. Kann jemand, der einen WAG120N mit der FW 1.00.12 Annex A besitzt und mit PPPoATM verbindet (auch andere Provider) meine Probleme mit dem Port Forwarding nachvollziehen? Der Linksys Support hatte den Fehler bei Nutzung von PPPoE (Callcenter ist freilich in .de) nicht. Im Sourcecode habe ich bisher keine Iptables-Aufrufe finden können. (Insbes. root.tar.gz - init und ppp-up/ppp-down).

2. Die einfachere Frage: hat jemand von Euch schon einmal Probleme mit VNC-Verbindungen im Telekom-Netz gehabt? Deep Packet Inspection/Firewalling wird doch hoffentlich kein seriöser Provider in .at, selbst bei Privatkunden vornehmen, oder?

3. Hat jemand noch andere Debugging-Ratschläge?
3.1 Wo würdet Ihr in der Firmware-Source zu suchen beginnen? Hat da irgendwer mit Linksysfirmware schon Erfahrungen gemacht? (ssh wäre auch ein Hit, aber ich will mangels JTAG-Kabel und wegen noch aufrechter Herstellergarantie da nicht herumpfuschen, sondern suche eine geteste "Debugging"-Firmware,

4. Empfindensfrage: Ist Remote-Support für Privatkunden (Senioren) wirklich sooo ein abwegiges Szenario, dass Unternehmen den Privatkunden zum Unternehmer machen wollen oder einfach nur Diskriminierung?

Ich danke für Eure Meinungen und Ratschläge!

[wicked_one]

*bla bla, viel übersprungen..*

benutz Teamviewer, und sorge dich nie wieder um irgendwelche Portforwardings....

[epek]

Danke für den Tip!
Teamviewer wurde mir schon von anderer Seite empfohlen, löst aber nicht alle Probleme. Weiters wirft es Lizenzfragen auf scheint nicht Open Source zu sein. Die Lizenzkosten müßten letzlich auf die Kunden übergewälzt werden und dafür ist es schlicht die falsche Zielgruppe. (Zumal es bei den Businessanschlüssen, ja von Haus aus schon kein Problem sein soll, weswegen dort die Lizenzkosten wegen des fehlenden Bedarf an der Software schon gar nicht anfallen würden).

Darüber hinaus kann ich mit Teamviewer bei ausgeschaltetem Client wohl nicht auf Geräte wie Printserver, Zweit-Access-Point etc. zugreifen. Dafür hätte ich gerne einen Direktzugriff, damit ich auch zu später/früher Stunde noch Wartungsarbeiten erledigen kann, wann es eben gerade nötig ist. (Wake on Lan - wäre auch so ein Thema...).

Ich bin mir sicher, dass es eine Vielzahl an Workarounds gibt, hätte aber ganz gerne auch die Ursache gefunden, um für spätere Anfragen gewappnet zu sein - darum auch das lange Posting zu Beginn.

Außerdem würde mich interessieren, ob andere Leute auch das von mir vermutete Problem mit der Routerfirmware bestätigen können. (Ich vermute, dass die Firewall im Falle von pppoa für ppp0 schlicht nicht initialisiert wird - weswegen die Standard-Policy: Drop greift. Das würde sich nämlich auch mit meinen Portscans in der Versuchsanordnung decken.) Diesfalls sollte man den Hersteller freundlich und nachdrücklich ersuchen, ein Update bereitszustellen bevor das Produkt in den Supportstatus End-of-Life übergeht. (Valet steht schon vor der Tür).
Was den GPL-Code der Firmware angeht, kann man sicher Nachbesserungen vornehmen - jedoch werde ich mich als Newbie ohne JTAG-Kabel und Doku sicher nicht (allein) in die Sache einlassen.

Wenn alle Stricke reissen, kann ich ja den WRT54GL mit Tomato wieder hinstellen - die Variante habe ich im "Labor" ja ausgiebig getestet. Da ich aber 50km weit fahren muss, habe ich lieber vor Fahrtantritt den Plan B schon im Kofferraum. Wenn ich die Gewissheit habe, dass es ao nicht funktionieren wird, erspare ich mir die Aktion und lege mich in die Sonne um die Bildschirmbräune abzulegen.

[_RoB_]

oder man instaliert logmein.com free - macht den pc wake on lan fähig und gibt port 9 frei - funktioniert bei meiner freundin bestens

[epek]

Hallo Rob!

Danke auch für diese Info! Ich sehe die gleichen Probleme wie beim obigen Produkt. Und mein primäres Problem ist nicht nur die Fernwartung des PCs selbst, sondern auch der anderen Geräte v.a. über Webinterface. Freilich geht das über den angeschlossenen PC, ist aber nicht optimal, da der Overhead bei der Bandbreite von max. 512k im Upload problematisch ist.

Wie Wake-On-Lan, das ja an sich in der Hardware implementiert ist, mit einer Software auf dem Client, den man erst aufwecken will funktionieren soll, ist mir noch nicht ganz klar.

Primär interessiert mich, ob jemand mein Problem mit den Forwards entsprechend meiner Angaben reproduzieren kann.
Falls ja, möchte ich dem Verursacher der Störung gerne zart auf die Zehen treten. Dazu brauche ich mehr Fakten.
Workarounds sind mir immer noch eingefallen - mich ärgert's nur, dass Produkte nicht das tun, was sie laut Hersteller tun sollen - und das ist mir gerade bei Routern und Homenetworking-produkten schon mehrmals passiert. Wenn's stimmt, wird ein RMA gemacht und fertig - oder ich schließe mich einer WRT-Entwicklergruppe an - je nachdem. Wenn keiner sonst das Gerät verwendet, ist die Motivation für letztere Option aber eher gegen 0 tendierend.

[jutta]

1. mit dem wag120n scheint es hier noch wenig erfahrungen zu geben. ich habe aussser diesem nur 1 thread gefunden viewtopic.php?f=59&t=49489

2. ausser port 25 wird bei privatproduktion nichts gesperrt, alle portforwardings sind moeglich. dass es mit einer statischen ip (business-produkt) einfacher geht, ist was anderes.

3. es gibt viele leute, die bei aon-anschluessen alle moeglichen arten von fernwartungen betreiben und dementsprechende ports geforwardet haben. das problem duerfte also entweder an deinem speziellen router oder an einem anwendungsfehler liegen.

schalten deine kunden nicht etwa aus stromspargruenden den router zeitweise aus?

was genau war dein problem beim speedtouch modem? die lassen sich doch nach strich und faden konfigurieren wie man sie braucht.

[epek]

Hallo Jutta!
ad 1: den Link kannte ich, er bezieht sich aber auf eher auf aonTV, denn auf die spezifischen Probleme.
ad 2: Das sehe ich ebenso. Mir ist immer noch schlicht unverständlich, wieso man beim gesprächsgegenständlichen Provider Fernwartung als "nicht endkundenspezifisch" betrachtet. Aber das ist ein anderes Thema, wo eher Meinungsbildung gefragt ist. -Ohne Meinungsbildung gäbe es heute noch keine unlimited oder fair-use-Zugänge.
ad 3: Die Anwendung wurde getestet, der Router laut Herstellerangaben konfiguriert. Ich bin mittlerweile auch recht sicher, dass das Problem an einer Firmware liegt und, dass bei ihrer Entwicklung ein Outsourcing des Qualitätsmanagements an den Endkunden stattgefunden hat. Das belegt der Source Code recht eindeutig. Warum aber das Portforwarding ausgerechnet im Modus pppoa[tm] versagt, wäre noch zu rekonstruieren. In dieser Hinsicht ist der Quellcode für mich schlicht nicht verständlich. Ich habe bisher keinerlei iptables-Aufrufe finden können und die Dokumentation fehlt anscheinend. Vielleicht sollte ich einmal die Leute bei OpenWRT bei der Suche um Hilfe bitten.
ad Stromsparen: Das war bisher kein Thema. In Anbetracht dessen, dass laut Auskunft des Anbieters die Skripts zur Anpassung der Bandbreite die Verfügbarkeit des Endgerätes periodisch abfragen und allenfalls einen Profilwechsel verursachen, halte ich das auch für keine gute Idee. Bitte um Information, falls sich daran etwas geändert haben sollte.
ad Speedtouch: Ich werde mich hüten, den bereitgestellten Modemrouter umzukonfigurieren, wenn es einen anderen Anschluss als den eigenen oder den eines nahen Verwandten betrifft. Das ist schlicht eine Frage der Haftung und der Wiederherstellung des vorigen Zustandes. Darüber hinaus hatte der alte Modemrouter kein WLAN. Wahrscheinlich gehe ich jetzt ohnedies auf die Kombination WRT54GL/Tomato + ST585v6 zurück. Dass der ST585v6 in Reserve liegt, für den Fall, dass andere Gerät den Geist aufgibt (Unwetter o.ä) erachte ich auch nicht gerade als Fehler. Darüber hinaus habe ich schon die Konfig des 585v7 (sic!) als zu zeitaufwändig in Erinnerung.

Danke für Deine Infos und Anregungen. Das mit dem Stromsparen ist schon einmal ein wichtiger Hinweis, aber wird nur mit Planung funktionieren. Zeitschaltuhren wären vielleicht eine Möglichkeit. Ich frage mich ja, warum es nicht schon längs Zeitschaltuhren-Funksteckdosenkombinationen gibt, bei denen ich wahlweise das Relais via Fernbedienung und/oder Zeitschaltung arbeiten kann - und eine Gembird-Schaltleiste mit Bluetooth würde die Anwender wohl überfordern.

[jutta]

@stromsparen: du hast mich missverstanden oder ich hab mich unklar ausgedrueckt. ich meinte bloss, dass manche leute ihre geraete genau dann ausgeschaltet haben, wenn jemand anderer sie fernwarten woll. die support-mitarbeiter_innen hier im forum koennen ein lied davon singen

im uebrigen laeuft das testscript nur in den ersten tagen bei einem neuen anschluss. danach hoechstens, wenn man bei der hotline anruft und darum bittet.

und zur konfiguraton des speedtouch: die sind dafuer gemacht, von endkunden konfiguriert zu werden. wenn du vorher ein backup der als funktionierend bekannten user.ini machst kann ueberhaupt nichts passieren. ich wuerde es zumindest versuchen, wenn es mit dem linksys nicht hinhaut.

> Mir ist immer noch schlicht unverständlich, wieso man beim gesprächsgegenständlichen Provider Fernwartung als "nicht endkundenspezifisch" betrachtet.

ganz einfach: wer anderer leute geraete fernwartet, sollte wissen was er dabei tut. daher ist es nicht aufgabe des supports, ihm das schritt fuer schritt zu erklaeren, schon gar nicht, wenn er ein geraet verwendet, das die support-mitarbeiter_innen noch nie gesehen haben.

wie gesagt: wenn es bei tausenden leuten funktioniert und bei dir nicht, gibt es 2 moeglichkeiten: entweder ist dein geraet schuld oder du machst etwas falsch. solange du uns nicht sagst, was du wie machst und was dabei genau nicht funktioniert, koennen wir dir bei der fehlersuche auch nicht helfen.

btw: bei vnc kommt es auch darauf an, dass client und server zusammen passen. da gibts ein paar kombinationen die gar nicht miteinander moegen. (gab es vor ein paar wochen einen thread dazu.)

[rwhome]

Mit dem Teamviewer gibt es keine Lizenzprobleme.
Im privaten Bereich ist er frei und für den Geschäftsbereich braucht man nur eine Lizenz kaufen und kann soviele Kunden fernwarten wie man will. Die Kunden müssen keine Lizenz kaufen.

Ich habe mich jahrelang mit VNC und Portforwardings herumgequält.
Es ist einfach leichter wenn man einen Collaboration Service benutzt und beiderseits nur ausgehende Verbindungen braucht.

Um Geräte ein oder auszuschalten verbinde ich mich meistens direkt mit dem Router des Kunden ( PPTP Tunnel o.ä.) und nutze zum Beispiel das iBoot von dataprobe.com

[epek]

Liebe Jutta:
Danke für die Antworten. Danke auch an rwhome.

ad Geräteabdrehen -> Erziehungsfrage in der Kunde - Technikerbeziehung.
ad testscript: Weiß das auch die Hotline? Die sind sich da selbst nicht so sicher. Ich habe mehr als einmal die Auskunft bekommen, dass das zu unspezifischen Zeiten laufen soll. Ich kann nicht beurteilen, ob die eine oder die andere Info richtig ist.
ad Speedtouch-Umkonfigurieren: Das ist letztlich eine Frage der Haftung im Schadensfall und außerdem eine Frage der Effizienz. Dass da auch was Schiefgehen kann, ist bei den Schmidts im Forum reichlich nachzulesen. (TG585v7 Firmware, Konfig, Paketflooding im TA-Netz).
ad Support: Der Support sollte mir ja nicht das spezifische Gerät supporten, sondern nur eine allgemeine Auskunft geben. Leider sind viele Hotlinemitarbeiter bei vielen Unternehmen dazu aber entweder nicht geschult, nicht dazu angewiesen oder haben mangelndes Abstraktionsvermögen. Die Antworten fallen dann demensprechend seltsam aus.
ad Falschmachen/Helfen: Die Firmware ist laut Linksys-Support partiell fehlerhaft - Single Port Forwarding geht schlicht nicht. Die prinzipielle Richtigkeit meiner Konfiguration hat der Linksys-Support bereits bestätigt, als er am Gerät eingeloggt war. In .de mit pppoe geht es in der Versuchsanordnung mit Port Range Forwarding, sofern das Interface nicht auf Deutsch umgestellt wird.
Wonach ich nun suche, sind Bestätigungen des Problems mit der Hardware, damit ich den Entwicklern der offiziellen Firmware und denen von OpenWRT o.ä. Bericht erstatten kann.
Was ich genau mache ist eine Standard-Konfig mit always-on pppoatm, dyndns und (zuerst) single port fw und dann port range fw. eintragen.
Die Ports sind am Gerät stets "closed", auch, wenn die Dienste am jeweils richtigen Client laufen. Firewallsettings wurden in allen Kombinationen durchgespielt und auch ein frisches Setup nach 30-sekunden-hw-reset brachte keine
Verbesserung. Lediglich der Remote-Port mit dem Webinterface "lebt" am externen Interface.

VNC ist dabei wirklich nur ein Randthema. Es geht auch und vor allem um Endgeräte mit Webinterface wie Zweit-AccessPoint und Druckserver, für die das Forwarding nicht geht und wo mir ein Teamviewer oder Sonstiges nur beschränkt hilfreich sein wird. (nämlich wenn der Client dahinter gerade eine Session hat...)

Ich suche jetzt ausnahmsweise nur noch nach Antworten auf das Hardwareproblem in der Konstellation pppoa/Port forwarding (Dienst egal).
Womit der Thread nach derzeitigem Stand der Dinge jetzt eigentlich nach "TECHNIK, NETZWERK & HARDWARE" verschoben gehört. (Bitte, Danke)


Ad Remote Desktop: Das war zwar Auslöser der Anfrage - danke für die vielen Tips und Erfahrungsberichte - interessiert mich aber im Moment wirklich nur beiläufig. Ich sehe keinen Grund, mein Konzept wegen eines einzelnen kaputten Routers zu ändern, würde mich aber freuen, wenn wir die Open Source Firmware des WAG120N zum Wohle der anderen Nutzer korrigieren können.


Wer immer mit einem WAG120N das Problem reproduzieren kann, ist herzlich willkommen mir eine Rückmeldung zu geben. Ich will wissen: single port fw.; port range fw.; Firmwareversion; Hardwareversion und Annex; TCP Service Port Number des geforwardeten Dienstes; Verbindungsart; Ergebnis des legitimen Portscans auf die geforwardeten Ports auf dem Gerät (closed, open, filtered).

[jutta]

kurze zwischenfrage: geht es um dieses geraet? http://geizhals.at/a475056.html - vom wag 120n gibt es ja mehrere modelle. vielleicht solltest du auch im geizhals forum und im wcm forum fragen.

//ps: nach dem modell googeln bringt eh die von dir gewuenschten beweise, dass andere das gleiche problem haben.
http://homecommunity.cisco.com/t5/Cable ... d-p/337744
das war jetzt nur der erste treffer, weiter hab ich nicht gesucht.

[epek]

Hallo!

Ja, die Forumsdiskussion kannte ich bereits (Cisco-Forum). Ich habe mittlerweile mit dem Cisco-Support telefoniert und habe dort eine teilweise Bestätigung erhalten. [Single Port Forward ist definitiv betroffen; weitere Fehler sind bei Verwendung des deutschsprachigen Interfaces reproduzierbar].

Ad mehrere Modelle: Das kann ich nicht nachvollziehen - es gibt ein Grundmodell, das in einer Version 1.0, die lediglich in zwei Versionen Annex A und B verfügbar ist. "Meiner" hat die ist 1.0 Annex A und der ist mit dem von Dir verlinkten Modell ident.

Die Lösungswege mit Reset und Neueinspielen der Firmware brachten jedoch nur teilweisen Erfolg.
Der GPL-Sourcecode zur Firmware ist mir aufgrund mangelnder Kommentare nicht verständlich.