Wieso funktioniert die Portfreigabe beim Speedport 724V nicht?

Frank Zibull · ‎08.08.2013

Ich habe hier und in anderen Foren schon sehr viel zum Thema 723V gelesen und das es da schon zu den gleichen Problemen gekommen ist. Ich möchte dazu sagen, das ich IT Fachmann bin und durchaus weiß, was ich tue. Dennoch gebe ich zu, gerne dazu zu lernen, wenn es um Produkte der Telekom geht. Ich scheine da nicht der Einzige zu sein.

Die selben Probleme von 723V habe ich nun mit dem 724V. Ich habe ALLES probiert, komplett neu aufgesetzt, alle Einstellungen auf Werkseinstellungen belassen und nur die Portfreigabe eingeschaltet, Router danach neu gestartet. Die Verbindungen von einem völlig anderen Netzt von außen getestet usw. usw.

Der Speedport ist nicht dazu zu bewegen, den Port 8083 freizugeben. Auch Umleitungen von 80 auf 8083 oder Tips wie einen Bereich von 8080 auf 8089 freizugeben haben nicht geholfen.

Ich bin mit meinem Latein am Ende. Warum funktioniert das nicht? Es liegt auch definitiv am Router, da ich vorher eine FritzBox 7390 betrieben habe, mit der ALLES funktioniert hat.

Wer weiß Rat?

UlrichZ · ‎12.01.2017

@iFuB-Verlag: wenn das NAS den Port 9000 haben will,

musst Du eine Portweiterleitung auch auf Port 9000 machen. Deiun Beispiel sah anders aus.

In den Standardeinstellungen des Speedports steht für die Netzwerkgeräte im LAN der Adressbereich 192.168.2.2 bis 192.168.2.255 zur Verfügung. Der DHCP-Server des Speedport vergibt üblicherweise Adressen von 192.168.2.100 bis 192.168.2.199. D.H., wenn Du dem NAS eine feste IP vergibst, muss sie ausserhalb dieses DHCP-Bereiches aber innerhalb des Speedport-Adressbereiches liegen z. B. 192.168.2.50.

Gruß Ulrich

Lösung in ursprünglichem Beitrag anzeigen

kkr · ‎01.06.2016

Hallo zusammen.

Hatte das gleiche Problem mit einem SP W 724v TypB. Ich wollte von extern auf einen Panasonic-HDD-Recorder zugreifen um remote TV-Sendungen zu programmieren - wenn ich mal vergessen habe sie zuhause einzustellen.

Die Portfreigabe habe ich gemacht - vielmehr eine Potweiterleitung, da ich irgendwo gelesen hatte dass der SP zugang remote nicht sauber funktioniert wenn eingehender und ausgehnder Port gleich ist. Habe also bei eingehenden Port 48443 eingetragen (nur ein Beispiel), beim ausgehenden einfach eine Nummer hochgezählt auf 48444 - und mit meinem Recorder als Gerät verlinkt. (war auswählbar, da sich der Recorder schon im WLAN befand).

Die Smartphone Panasonic App für die Programmierung (Media Center) hat dann nach Installation und dem Registrieren des Rekorders in der App (dazu muss Smartphone und Recorder im gleichen LAN/WLAN sein) die Remotekonfiguration getestet - und ausgespuckt "Ihre Router-Einstellungen lassen einen Remote-Zugriff nicht zu".

War schon am verzweifeln, bis ich HIER im Thread gelesen habe, dass der SP einen Remote-Test nicht zulässt wenn man nicht wirklich von außerhalb testet. Da das Smartphone noch im WLAN verbunden war . . . konnte die App also gar nicht richtig testen.

Hab also mal trotz Fehlermeldung der App zuhause unterwegs auf der Straße mit 4G-Empfang die App angeschmissen . . . und was soll ich sagen: hat funktioniert!

Zur Ergänzug: Router neu starten hatte ich auch gemacht nach der Konfiguration der PortWEITERLEITUNGEN.

Einfacher wäre es natürlich gewesen mit UPnP - aber das geht ja nicht beim SP. Kann nicht sagen ob das jemanden hilft hier . . . aber ich wollte die Info nicht vorenthalten.

Lösung in ursprünglichem Beitrag anzeigen

infernomaster · ‎23.04.2015

Hallo, wie oft schauen die Mitarbeiter der Telekom denn überhaupt hier rein? Das Thema schien mir eigentlich ja sehr aktiv gewesen zu sein, deswegen hatte ich hier meinen Beitrag erstellt. Das Problem stört mich doch sehr.

Johannes S. · ‎23.04.2015

Hallo infernomaster,

sorry, wenn ich offen schreibe, dass ich Ihre Beobachtung zum Zusammenspiel zwischen Teamspeakserver und Speedport W 724V Typ A so nicht nachvollziehen kann. Vor einiger Zeit habe ich das getestet und da gab es keine Probleme. Bei mir sah es so aus:

infernomaster schrieb:

Ich habe alles probiert, Eingabe 8888 - 8888 8888-8888 ; 8888 - nix 8888 - nix
Oder Umleitung 8888 - 8888 8887 - 8887 ; 8888 - nix 8887 - nix
Nichts davon wird übernommen, immer "gefiltert" beim Scan.

Wollten Sie den TCP- oder UDP-Port freigeben? Der Heise Portscan testet meines Wissens keine UDP-Ports.

@infernomaster schrieb:

Ich bin auch bereit einem Bearbeiter per Privatnachricht oder Email meine Dyn Adresse zu geben um selber nachzugucken...

Also wenn das keine Vorlage ist. Senden Sie mir dazu bitte Ihre Kundendaten über unser Kontaktformular. Es wäre super, wenn Sie vorab noch einmal die von oben genannte Einstellungen testen.

Viele Grüße
Johannes S.

infernomaster · ‎23.04.2015

Bei mir sieht es nicht anders aus.

Ich habe auch mal 2 Screenshots gemacht.

Das der Heise check kein UDP testen kann ist mir sehr wohl bewusst, eigentlich brauche ich auch nur den UDP Port.

Aber auch der TCP Port sollte ja zumindest mit "geschlossen" antworten und ich sollte eine eingehende Verbindung beobachten können, selbst wenn diese abgewiesen werden würde. Es kommt aber definitiv nichts an. Außerdem hab ich nichts an der Konfiguration verändert, mit dem alten Router klappte es ja.

Das Kontaktformular fülle ich dann jetzt aus.

Edit: Ist gesendet.

infernomaster · ‎23.04.2015

Ein Wunder ist geschehen, nach dem ungefähr tausendsten UDP scan ist mal was angekommen, aber verändert habe ich an der Router Konfiguration seit Tagen nichts mehr. Sehr merkwürdig.

War ja auch klar, gerade wenn man den Support kontaktiert hat.

Verstehen muss ich es trotzdem nicht warum auf einmal doch was ankommt und es vorher tagelang nicht geht.

Nur leider ist gerade kein Bekannter zum Live Test online.

Richtig weiß ich es also erst wenn ich einen freundlichen Mitmenschen zum testen auftreiben konnte.

Werde dann nochmal Rückmeldung geben.

infernomaster · ‎23.04.2015

Nachtrag: Habe einen Tester gefunden, es geht.
Bin mal gespannt wie lang es hält

Evtl. melde ich mich dann wieder, Kontakt ist also nicht mehr nötig.

Johannes S. · ‎24.04.2015

Hallo infernomaster,

@infernomaster schrieb:
Ein Wunder ist geschehen...

"Wunder gibt es immer wieder
heute oder morgen
können sie geschehn."

Ich bin zwar kein großer Fan von Katja Ebstein, aber freuen wir uns doch einfach über das Ergebnis.

Gerade UDP-Tests sind echt tricky, weil der Portscanner da keinen Verbindungsaufbau wie bei TCP simulieren kann. Deshalb habe ich mir bei UDP-Scans eine gute Portion Misstrauen angewöhnt.

@infernomaster schrieb:

Aber auch der TCP Port sollte ja zumindest mit "geschlossen" antworten und ich sollte eine eingehende Verbindung beobachten können, selbst wenn diese abgewiesen werden würde.

Ja, sehe ich aus so bei TCP; bei UDP kommt meist so ein "closed/filtered", also "weiß ich auch nicht so genau".

Wie auch immer, der Teamspeak läuft und das zählt!

Viele Grüße

Johannes S.

s.brucherseifer · ‎24.04.2015

Ist da vielleicht ein Muster? Ich hatte auch nichts an der Konfiguration geändert, aber einen Tag später funktionierte es plötzlich, vorher nicht. Und ich habe dazu nicht nur einen Portscan gemacht, sondern auch über Mobilfunk versucht auf den Test-Server zuzugreifen. Ein Router-Neustart nach dem ersten Fehlschlag brachte keine Besserung...

Johannes S. · ‎24.04.2015

Hallo s.brucherseifer,

ein Muster? Ich kann mir keines vorstellen. Ihre Einstellungen zur Portfreigabe greifen im Speedport - wie andere Einstellungen auch - sofort und unmittelbar. Eine irgendwie geartete "Karenzzeit" von einem Tag schließe ich definitiv aus. Den Routerneustart hatten Sie durchgeführt. Er ist schnell gemacht und schadet eigentlich nie. In ganz "hartnäckigen" Fällen kann ein Werksreset des Routers Abhilfe schaffen. Unter Umständen spielt auch die persönliche Firewall auf dem Rechner eine Rolle, die sich durch Updates verändern kann.

Ich gebe zu: viele "Wenn und Aber". Sicher ist erst einmal Ihr positives Ergebnis. Und das sieht sehr gut aus.

Viele Grüße
Johannes S.

bafe · ‎25.04.2015

ssh zB geht, aber bei http (zB 88 auf 80) bekomme ich immer einen Timeoutfehler.

Wüsste nicht, was ich beim Pi noch gesondert konfigurieren muss.

Insti · ‎26.04.2015

Hi, im Heimnetz funktioniert die Webpage aus dem RPi http://rasperrypi ?

Läuft da sicher ein Webserver auf dem Raspberry?

Empfehle dir auf den RPI ein openvpn Server einzurichten und nur einen udp Port am Speedport an den RPI weiterzuleiten, damit hast du Zugang zu deinem kompletten Netzwerk mit nur einem udp Port.

Kannst nach meiner Anleitung für den Pogo gehen, die ich im DEB geschrieben habe : http://www.digital-eliteboard.com/297362-openvpn-server-auf-pogoplug.html#post2079851

LG

bafe · ‎29.04.2015

Natürlich läuft der Server.

Und VPN ist keine Alternative, da ich einfach von extern auf den Server zugreifen möchte (Kamerüberwachung).

Insti · ‎30.04.2015

Einfacher und Sicherer als über openVPN gibt es meiner Ansicht nach nicht.

Da ssh Port22 funktioniert, wäre es auch möglich über einen ssh Tunnel das WebInterface vom PI zu erreichen, aber das ist etwas komplizierter als über VPN.

Um es ganz einfach zu haben, muss man sich einen anderen Router kaufen der dann "einfach" den TCP Port ungesichert zum Pi öffnet, da ja der 724 das anscheinend nicht kann.

LG Insti

Johannes S. · ‎04.05.2015

Hallo bafi,

ihr letztes Posting klang nicht besonders hoffnungsvoll: Ich befürchte deshalb, Sie kommen weiterhin nicht auf den Webserver.

Um eine Ursache im Speedport auszuschließen, lassen Sie uns bitte noch einmal Schritt für Schritt vorgehen:

Setzen Sie zunächst den Speedport auf die Werkseinstellungen zurück. Dazu benötigen Sie Ihre gültigen Zugangsdaten.

Richten Sie im Speedport die Portweiterleitung für TCP-Port 80 auf Port 80 des Rasberrys ein.

Machen Sie dann einen Online-Portscan, zum Beispiel diesen.

Berichten Sie uns bitte hier vom Ergebnis und ergänzen Sie auch den Typ des Speedports (beispielsweise so Speeport W 724V Typ A, B oder C).

Ob der Speedport die Ursache ist? Ich denke, wir werden es gemeinsam herausfinden.

Viele Grüße
Johannes S.

gartenmeister · ‎12.05.2015

Das ist aber sicherlich für viele User eine große Einschränkung.

Ich habe in meinem Netzwerk zu Hause einen Rechner, auf dem ein Mailserver läuft. Damit ich die E-Mails mit dem Smartphone und iPad auch von draußen abholen kann, ist dort als POP und SMTP meine <ich>.no-ip.com-Verbindung eingetragen.

Bei dem alten Router (Speedport W722V) konnte ich die E-Mails zu Hause über WLAN trotzdem abholen - das schont die Datenflat, die auf den Smartphone nicht so groß ist.

Jetzt kann ich die E-Mails nicht über das WLAN abholen, nur über das Datenpaket - es sei denn, ich tausche dann ständig die POP- und SMTP-Einstellungen zwischen <ich>.no-ip.com und den lokalen Einstellungen zu Hause.

Ich verstehe nicht ganz, wo da der Vorteil einer solchen Einschränkung liegen soll.

Stanislaw

Matthias Bo. · ‎21.05.2015

Hallo gartenmeister,

willkommen in der Telekom hilft Community!

Ich verstehe nicht ganz, wo da der Vorteil einer solchen Einschränkung liegen soll.

Ich denke, hier wird der Schutzgedanke, für das heimische (Kunden-) Netzwerk, der Vater des Gedankens gewesen sein.

Ich kann gut verstehen, dass die feste Verdrahtung, b.z.w. die fehlende Entscheidungsmöglichkeit, in dieser Sache, nicht gewünscht ist. Wir haben schon oft versucht hier Änderungen zu erreichen.

Ich kann gerne noch einen Versuch starten.

Nutzen Sie einen IP-Anschluss?

Hier findet keine regelmäßige Zwangstrennug mehr statt und Sie könnten direkt mit Ihrer IP arbeiten.

Gruß

Matthias Bo.

gartenmeister · ‎21.05.2015

Ich denke, hier wird der Schutzgedanke, für das heimische (Kunden-) Netzwerk, der Vater des Gedankens gewesen sein.

Aber hier werde ich doch vor mir selbst geschützt, denn gesperrt ist nicht die Möglichkeit, von draußen hineinzukommen (Portfreigabe funktioniert), sondern die Möglichkeit, aus dem eigenen Netzwerk raus- und wieder hineinzukommen.

Da liegt die Vermutung nahe, dass die Programmierer den User für so dumm halten, dass man ihn vor ihm selbst schützen muss. Das ist kein gutes Zeugnis für Programmierer (man soll anderen nicht den eigenen IQ imputieren).

Ich würde es also begrüßen, wenn diese Sperre künftig (evtl. durch Firmwareupdate) entfallen könnte.

Ja, ich habe einen IP-Anschluss (seit voriger Woche, daher auch der Umstieg von W722V, wo es funktioniert hat, auf W724V).

Aber was bringt mir dann die Angabe der IP?

Habe es gerade versucht, funktioniert aber nicht.

Wenn ich als Posteingangsserver anstelle von "gartenmeister.no-ip.com" z.B. "217.84.100.100" (in Wirklichkeit meine richtige IP) eingebe, erhalte ich die Fehlermeldung, dass der Server nicht erreichbar ist.

Danke für die erneute Aufnahme des Themas.

gartenmeister

Insti · ‎22.05.2015

@gartenmeister schrieb:

Jetzt kann ich die E-Mails nicht über das WLAN abholen, nur über das Datenpaket - es sei denn, ich tausche dann ständig die POP- und SMTP-Einstellungen zwischen <ich>.no-ip.com und den lokalen Einstellungen zu Hause.

Ich verstehe nicht ganz, wo da der Vorteil einer solchen Einschränkung liegen soll.

Stanislaw
Hi Gartenmeister, das ganze Dilemma schimpft sich NAT-Loopback.

Eine Lösung wäre das einrichten eines zweiten Konto als Email Client mit dem hostname des Mail Servers statt der ip oder dyndns.

LG Insti

Uwe-Josef-Schiffer · ‎24.07.2015

Portweiterleitung beim Speedport W724V Typ A funktioniert nicht.

Ich möchte Überwachungscameras ins System einbinden. Innerhalb meines eigenen Netzwerks funktioniert alles einwandfrei nur wenn ich vom externen Netzwerk zugreifen will funktiniert gar nichts. Portweiterleitung eingerichtet ( 7777 -7777-7777-7777 kamera1 und 7778-7778-7778-7778 kamera2

jedoch beim Portscan bekomme ich imm er nur Port geschlossen egal was ich auch versuche.

In diversen Foren schon nach Lösung gesucht leider ohne ergebniss ich bitte um schnelle Hilfe

Bitte um konkrete Hilfe da doch schon ausreichend Diskutiert und von Telekom Mitarbeitern schon selbst getestet worden ist. dann darf man doch auch um eine korrekte Lösung bitten

s.brucherseifer · ‎24.07.2015

Wenn die Ports tatsächlich als geschlossen angezeigt werden, heißt das eigentlich, dass sie offen sind. Ansonsten würdest du nämlich die Meldung geöffnet/unbekannt kriegen. Bei mir war erst letzteres der Fall, bis irgendwann die Freischaltung geklappt hat, danach wurde der Port als geschlossen angezeigt und wenn ich auf diesem Port einen Server habe laufen lassen, dann wurden die Verbindungen hier auch angenommen und der Port war dann gänzlich geöffnet.

Vorsicht bei Portscannern für UDP: hier muss der Server, der auf dem port lauscht auch tatsächlich einen UDP-Socket verwenden. Ein HTTP-Server wird hier nicht funktionieren, weil das Protokoll TCP ist.

Warum Portweiterleitungen nicht immer unmittelbar zu funktionieren scheinen ist mir ein Rätsel. Neustart allein hatte nichts genutzt, einen Tag später ging es dann wie von Zauberhand.

Ich würde folgendes tun: Weiterleitung noch mal raushauen, neuste Firmware einspielen, Gerät NACH ABGESCHLOSSENEM Reboot vom Strom nehmen für 10 Minuten, wieder dran, mindestens 5 Minuten warten bis Internet und WLAN wieder funktionieren und dann die Weiterleitung wieder einrichten. Wenn möglich port-Freigabe erstmal testen um ein anderweitiges Problem wie PC-Firewall etc. ausschließen zu können. Wenn alles fehlschlägt, via Webinterface Router nochmal neustarten und über Nacht warten, ob es an morgen danach funktioniert.

Das ist zwar hauptsächlich Aberglaube , aber wenns hilft...

Johannes S. · ‎24.07.2015

Hallo Uwe-Josef-Schiffer,

herzlich willkommen in der Telekom hilft Community.

s.brucherseifer hat Ihnen eben schon super Hinweise gegeben, die noch um zwei Tipps ergänzen möchte.

1. Nach dem Screenshot sehen die Portfreigaben im Speedport sehr gut aus. Ich habe keinen Grund daran zu zweifeln, dass sie aktiv sind und die Firewall im Speedport die Anfragen auf diesen Ports durchleitet. Testen können Sie dieses beim Speedport nur von außerhalb Ihres Heimnetzwerkes. Eine einfache Methode ist ein Online-Portscanner und damit sind wir bei meinem zweiten Tipp 2.

2. Der Portstatus von TCP-Ports lässt sich mit Online-Portscanner relativ gut ermitteln. Bei UDP-Ports wirds leider kompliziert. s.brucherseifer hat schon darauf hingewiesen. Manche Online-Scanner machen das gar nicht erst, weil die Ergebnisse zu unsicher sind. Deshalb testen Sie bitte Ihre TCP-Ports hier und posten uns Ihr Ergebnis. Ich bin zuversichtlich, dass wir dann einen Hebel finden werden.

Viele Grüße

Johannes S.

s.brucherseifer · ‎27.01.2016

Nochmal als Hinweis: Portfreigaben scheinen manchmal nicht zu funktionieren, in Wahrheit ist es aber so:

über die lokale Netzwerkadresse ist der Dienst hinter dem freigegebenen Port nicht zu erreichen
über die externe IP (wenn ich mich richtig entsinne) auch nicht
von einem anderen Internetanschluss aus (z.B. Mobilfunknetz, aber eben nicht das heimische WLAN) klappt es aber

Warum das so ist, bleibt mir ein Rätsel. Die Erreichbarkeit sollte nicht davon abhängen, ob man sich im gleichen oder einem anderen Netzwerk befindet. Irgendwas ist das faul mit dem Routing oder der Firewall.

kkr · ‎01.06.2016

Hallo zusammen.

Hatte das gleiche Problem mit einem SP W 724v TypB. Ich wollte von extern auf einen Panasonic-HDD-Recorder zugreifen um remote TV-Sendungen zu programmieren - wenn ich mal vergessen habe sie zuhause einzustellen.

Die Portfreigabe habe ich gemacht - vielmehr eine Potweiterleitung, da ich irgendwo gelesen hatte dass der SP zugang remote nicht sauber funktioniert wenn eingehender und ausgehnder Port gleich ist. Habe also bei eingehenden Port 48443 eingetragen (nur ein Beispiel), beim ausgehenden einfach eine Nummer hochgezählt auf 48444 - und mit meinem Recorder als Gerät verlinkt. (war auswählbar, da sich der Recorder schon im WLAN befand).

Die Smartphone Panasonic App für die Programmierung (Media Center) hat dann nach Installation und dem Registrieren des Rekorders in der App (dazu muss Smartphone und Recorder im gleichen LAN/WLAN sein) die Remotekonfiguration getestet - und ausgespuckt "Ihre Router-Einstellungen lassen einen Remote-Zugriff nicht zu".

War schon am verzweifeln, bis ich HIER im Thread gelesen habe, dass der SP einen Remote-Test nicht zulässt wenn man nicht wirklich von außerhalb testet. Da das Smartphone noch im WLAN verbunden war . . . konnte die App also gar nicht richtig testen.

Hab also mal trotz Fehlermeldung der App zuhause unterwegs auf der Straße mit 4G-Empfang die App angeschmissen . . . und was soll ich sagen: hat funktioniert!

Zur Ergänzug: Router neu starten hatte ich auch gemacht nach der Konfiguration der PortWEITERLEITUNGEN.

Einfacher wäre es natürlich gewesen mit UPnP - aber das geht ja nicht beim SP. Kann nicht sagen ob das jemanden hilft hier . . . aber ich wollte die Info nicht vorenthalten.

idzan · ‎26.08.2016

Für alle die Probleme haben mit der Portweiterleitung.

Ich hab mir das ganze auch mal angeschaut, VPN Server hinter SP 724v Typ c eingerichtet Port 1723 weitergeleitet auf VPN Server und bei canyouseeme.org Port 1723 getestet. Wie alle anderen gepostet haben war der Port nicht erreichbar.

Ich hab beim VPN Server eine fest IP4 eingetragen gehabt, wenn man diese aber auf DHCP umstellt und die Portweiterleitung neu einrichtet, dann Funktioniert der Port. Demnach sieht dies so aus, dass der SP keine Ports weiterleitet wo der Server im internenen Netzwerk eine Feste IP eingetragen hat.

s.brucherseifer · ‎26.08.2016

Interessant... Aber irgendwie witzlos, dass es nicht mit festen IPs geht.

Ich frage mich, wie man das andere Anwendungen übertragen kann. Mein Rechner bezieht seine IP über DHCP und eine Server-Anwendung kann ich statt an die feste Netzwerk-IP an 0.0.0.0 binden (alle Interfaces). Aber dann funktioniert die Portfreigabe trotzdem nur extern, aber nicht im lokalen Netzwerk.

Marita1953 · ‎06.12.2016

Hallo.

Habe alles gelesen.

Habe alles probiert.

Ich würde auch gern einen neuen Router ausprobieren. Bitte um umtausch, habe den w724 Typ B seit 2 Monaten.

Wieso funktioniert die Portfreigabe beim Speedport 724V nicht?

Social Media