Wieso funktioniert die Portfreigabe beim Speedport 724V nicht?

[#1]

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?

[#2 · Accepted solution]

@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

[#3 · Accepted solution]

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.

[#4]

Das kann ja nicht die Lösung sein. Ich betreibe einen server der mit anderen server auf zb. 20800 kommuniziert. unter 20810 zb. gibt er sein lebenszeichen weiter und unter ip :28965 ist der server connectbar aus dem internet. wie soll ich denn beim forwoard einen andren port von ausen angeben wenn diese von der gegenstation gar nicht verwendet werden???!! zb 20800 ist standart, trage ich 20801 ein dann kommt von ausen ja die anderen stationen gar nicht rein, denn diese pingen auf 20800.. das kann nicht funktionieren.

[#5]

Hallo corsapower2,

leider hat Frank Zibull sich nicht wieder gemeldet, ich weiß also nicht, wie er den Knoten gelöst hat.
Führen Sie die Tests mit der aktuellen IP-Adresse des Routers oder mit einer DynDNS Adresse aus? Nutzen Sie dabei einen DSL Anschluss oder eine UMTS/LTE-Verbindung?
Stecken Sie doch bitte mal einen USB-Stick an den Router und konfigurieren Sie eine Freigabe, die auch über FTP über das Internet erreichbar ist. Dann versuchen Sie mal, diese von außen zu erreichen. Wenn dies dann geht, dann wissen wir, dass der Router selber erreichbar ist, dann sind die Weiterleitungen dran.

Gruß Stefan

[#6]

Hallo,

Verstehe das nicht wieso man sowas nicht aus dem eigenen Netzwerk Testen kann! Bei Der Fritzbox geht das alles wunderbar! Das die Telekom auch immer noch auf ihre Speedports schwören! Es gibt viel bessere Router die jeden von uns glücklich machen.
Man könnte ja wenigstens die Fritzbox mit ins Sortiment nehmen! Da sie so Robust sind wie kein anderes dsl Modem/Router!

[#7]

ich bin aufgrund eines HW-Defekts bei meiner Fritzbox 7390 auf den Speedport W724 (HW-Version C) reingefallen umgestiegen.

Die Portweiterleitung der W724 funktioniert bei mir auch nur beim Zugriff aus einem externen Netz, nicht aber beim Zugriff aus dem internen Netz.

Alle Einstellungen (dyndns, IP-Adressen, ...) und die Verkabelung wurden 1:1 von der Fritzbox übernommen. Bei der Fritzbox klappt alles reibungslos, bei der Speedport nur mit der o.g. Einschränkung.

[#8]

---

@henk_s schrieb:

...Die Portweiterleitung der W724 funktioniert bei mir auch nur beim Zugriff aus einem externen Netz, nicht aber beim Zugriff aus dem internen Netz.

... 

---

Das liegt daran, dass der Speedport kein NAT-Loopback unterstützt. Im internen Netzwerk solltest du auch die internen Adressen nutzen, muss doch nicht jede Anfrage einmal um die Welt und wieder zu dir zurück.

[#9]

---

@henk_s schrieb:

 auf den Speedport W724 (HW-Version C) reingefallen umgestiegen.

---

Nur mal als kleiner Hinweis für weitere Posts: ich nehme an, es handelt sich um den SP W 724V Typ A von Huawei (siehe rückseitiges Typschild).

Gruß Ulrich

[#10]

---

@UlrichZ schrieb:

ich nehme an, es handelt sich um den SP W 724V Typ A von Huawei

---

korrekt!

[#11]

---

@Pr. Habakuk Tibatong schrieb:

Das liegt daran, dass der Speedport kein NAT-Loopback unterstützt.

---

Danke für die Erklärung!

[#12]

Hallo blue7654,

ich schließe mich der Analyse von User Pr. Habakuk Tibatong an. Mein herzlicher Dank an den User. Der Speedport W 724V unterstützt aus Sicherheitsgründen kein NAT-Loopback (Hairpin NAT). Mit anderen Worten: Wenn Sie sich mit Ihrem mobilen Gerät in Ihrem Heimnetzwerk per WLAN mit dem Server verbinden möchten, auf dem der Dienst läuft, geht dies ausschließlich über die private IP-Adresse des Servers. Dies gilt jedenfalls, soweit Sie nicht noch weitere Methoden implementiert haben (z.B. Eintrag im Hostverzeichnis).

Außerhalb Ihres Heimnetzwerkes kann der Zugriff auf Ihren Dienst auch mit dem Hostname erfolgen, den Sie bei Ihrem DynDNS-Anbieter angemeldet haben.

Einige wenige Ports sind am Speedport für interne Zwecke reserviert. Ansonsten können Sie alle Ports an Ihrem Speedport weiterleiten.

Viele Grüße

Johannes

[#13]

Leider klappt es bei mir mit dem W 724V Typ C nicht. Port 80 funktionierte zwar nach einem Reboot, aber nur solange ich direkt mit dem Speedport-WLAN verbunden war. Ist der Rechner im WLAN meines Access Points (der per LAN-Kabel mit dem Speedport verbunden ist), klappt es nicht. Möglicherweise leitet das Speedport nur an Adressen im eigenen DHCP-Bereich (192.168.2.100+) weiter oder es geht grundsätzlich nicht wenn eine Zwischenstation dazwischen hängt.

Nachdem es bei Port 80 mit oben genannten Einschränkungen geklappt hat, probierte ich das gleiche mit Port 55660 - ohne jeden Erfolg. Daraus kann ich nur schließen, dass das Speedport offenbar zwischen verschiedenen Diensten oder Ports unterscheidet. Das scheint mir ziemlich willkürlich.

Darüber hinaus bin ich auf folgende Meldung im Systemlog gestoßen:

DoS (Denial of Service) Angriff SYN Flood wurde entdeckt. (FW101)

Zeitlich muss es der Portscan gewesen sein, oder mein manueller Zugriffsversuch auf Port 55660. Offenbar tritt dieses Problem, wie oben angedeutet, bei Port 80 scheinbar nicht auf. Gibt es denn Schokoladenports, die nicht für bestimmte Dienste reserviert sind und sich trotzdem öffnen lassen???

[#14]

Hallo s.brucherseifer,

willkommen in der Telekom hilft Community!

Auf Ihrem Acces-Point läuft ein zusätzlicher DHCP-Server? Ich denke Sie sollten den DHCP-Server deaktivieren und den Speedport als alleinigen DHCP-Server laufen lassen. Dann wird das Heimnetz wie geplant reagieren und funktionieren.

---

 Gibt es denn Schokoladenports, die nicht für bestimmte Dienste reserviert sind und sich trotzdem öffnen lassen???

---

Reservierte Ports sind:

TCP 5060 für SIP (VoIP)
TCP 7547 für EasySupport
UDP 67-68 für DHCP
UDP 5002-5082 für RTP für VoIP Gesprächsdaten

Reservierte Ports bei Nutzung/ Aktivierung von bestimmten Diensten:

TCP 20-21 nach Aktivierung des internen FTP Servers
TCP 515  nach Anschluß eines Druckers
UDP 137-138 reserviert nach Anschluss Drucker oder USB-Datenträger (NETbios) 
UDP 631 reserviert nach Anschluss Drucker oder USB-Datenträger (IPP Internet Printing Protokolll)  
UDP 1701 und 38946 nach Aktivierung von WLAN To Go

Es gibt allerdings noch einige andere Ports, die besser nicht genutzt werden sollten, da sie von anderen Diensten benutzt werden:

http://de.wikipedia.org/wiki/Liste_der_standardisierten_Ports

Gruß

Matthias

[#15]

Viele der genannten Probleme kann ich nicht nachvollziehen. Für eine Synology Diskstation richtete ich auf meinem W724V diverse Portweiterleitungen ein - und alle funktionieren!

Viele Grüße

Holger

[#16]

Hallo Matthias Bo.,

ich werde nochmal versuchen, den zusätzlichen DHCP-Server des APs zu deaktivieren. Beim letzten Versuch hatte das nicht geklappt (DHCP deaktiviert und WLAN-SSIDs geändert auf die des Speedports einschließlich der Verschlüsselung und des Keys, damit automatisch das jeweils besser empfangbare Gerät angefunkt wird). Anschließend konnte ich weder auf das Speedport noch auf den AP mehr zugreifen, egal neben welchem Gerät ich stand, und es gab auch keine Internetverbindung mehr. Ich musste dann den AP resetten.

Ich glaube ich hatte NAT im AP nicht deaktiviert und keine feste IP für die Kabelverbindung mit dem Speedport gesetzt - könnten das die Ursachen sein?

Übrigens funktioniert Dualband beim Speedport nicht wie gewünscht (2,4 und 5GHz mit einer SSID). Sobald ich mich einen Meter vom Speedport entferne, kommen von den 50Mbit/s nur noch 22MBit/s durch die Luft - ein Indiz dafür, dass die 2,4GHz-Frequenz genutzt wird, obwohl die 5GHz-Frequenz ebenso guten Empfang hat und deutlich höhere Datenraten erzielen würde. Wenn beide getrennte SSIDs haben funktioniert es unter Windows 8.1 hervorangend (das 5GHz-Band wird dann offenbar bevorzugt).

Die Ideallösung wäre beide 2,4GHz-Netze und beide 5GHz-Netze jeweils zu roamen und ein sich transparent verhaltender AP (funktionierende Portfreigabe miteingeschlossen).

Übrigens verwende ich nur Ports jenseits der 20 000 bzw. sogar 50 000, da dort fast keine Gefahr besteht, mit bekannten Diensten in Konflikt zu geraten.

[#17]

---

@s.brucherseifer schrieb:
ich werde nochmal versuchen, den zusätzlichen DHCP-Server des APs zu deaktivieren.

---

In einem Netzwerk darf nur ein DHCP-Server tätig sein - am besten der des Routers.

---

@s.brucherseifer schrieb:
und keine feste IP für die Kabelverbindung mit dem Speedport gesetzt - könnten das die Ursachen sein?

---

Wenn beim Router DHCP aktiv ist, brauchst Du dem AP keine feste IP zuordnen, die erhält er vom Router.

---

@s.brucherseifer schrieb:

Übrigens funktioniert Dualband beim Speedport nicht wie gewünscht (2,4 und 5GHz mit einer SSID). Sobald ich mich einen Meter vom Speedport entferne, kommen von den 50Mbit/s nur noch 22MBit/s durch die Luft - ein Indiz dafür, dass die 2,4GHz-Frequenz genutzt wird, obwohl die 5GHz-Frequenz ebenso guten Empfang hat und deutlich höhere Datenraten erzielen würde. Wenn beide getrennte SSIDs haben funktioniert es unter Windows 8.1 hervorangend (das 5GHz-Band wird dann offenbar bevorzugt).

---

Doch, Dualband funktioniert wie gewünscht mit gleicher ID. Nur musst Du Deinem Client sagen, mit welchem Frequenzband er sich bevorzugt verbinden soll. Wenn Du das nicht entsprechend konfigurierst, setzt der Client seinen Kopf durch und versucht in der Regel zunächst die Verbindung im 2,4 GHz-Band, die dann ja auch funktioniert - warum sollte er es dann noch im 5 GHz-Band versuchen? Der Router hat damit überhaupt nichts zu tun!

Übrigens läuft hier Dualband auch mit der gleichen SSID und auch der zusätzliche AP hat die gleiche SSID und WLAN-Key. Nur die Kanäle sind unterschiedlich festgelegt.

Gruß Ulrich

[#18]

Mit den zwei DHCP-Servern gab es ehrlich gesagt keine Probleme, beide haben unterschiedliche Bereiche zugeordnet. Der Nachteil der Konfiguration insgesamt war eher, dass das Speedport vom AP-WLAN aus nicht erreicht werden konnte.

Mit der statischen IP hast du recht, solange ein DHCP-Server vorhanden ist besteht kein Bedarf dafür. Zwischenzeitlich vergab allerdings auch das Speedport keine gültigen IP-Adressen, das Problem hat sich nach ein paar Minuten jedoch von selbst gelöst.

Ich wüsste nicht, dass man unter OS X oder Windows das Band auswählen kann. Dann ist es wohl ein schlechter Client-Algorithmus bei SSID-Roaming. Etwas ärgerlich ist die Voreinstellung des Speedports mit einer gemeinsamen SSID, wodurch ich schon dachte, dass nur die Hälfte der 50MBit/s ankämen, wenn doch beide großen Betriebssysteme nicht vernünftig mit Dualband umgehen können.

Zurück zur Portfreigabe:

Ich kann nun mit Sicherheit sagen, dass es nicht am zwischengeschalteten AP liegt. Wenn ich im Speedport-WLAN bin, einen Webserver auf Port 80 laufen habe und Port 80 im SP freigebe, sagt mir ein Portscanner unmittelbar, dass der Port offen ist. Deaktiviere ich den Port im SP, wird er sofort als geschlossen gemeldet. Wenn ich den Webserver nun auf z.B. Port 23456 starte und diesen Port freigebe, ist er dennoch geschlossen. Offenbar gibt es also Schokoladenports!

Hier der Videobeweis:

http://youtu.be/BXl6jEqrW2Q

Zum AP: ich habe NAT und DHCP ausgeschaltet und das LAN-Kabel vom WAN-Port auf einen LAN-Port umgesteckt, und anschließend kann ich mich mit dem AP-WLAN verbinden und erhalte Internet und Zugriff auf speedport.ip - allerdings kann ich dann nicht mehr auf den AP selbst zugreifen (das geht nur noch, wenn ich mir manuell eine IP im gleichen Subnetz 192.168.0.* zuordne, nur das dann weder Internet noch das Speedport verfügbar sind). Die LAN-IP des APs auf das Subnetz des WANs zu legen ist nicht erlaubt, daher bin ich ratlos, wie ich vom SP-Subnetz 192.168.2.* auf den AP zugreifen soll...

[#19]

---

s.brucherseifer schrieb:

Ich wüsste nicht, dass man unter OS X oder Windows das Band auswählen kann.

---

Unter Windows in den Treibereinstellungen der Client-Hardware:

Gruß Ulrich

[#20]

Hallo s.bruchenseifer,

ich fang mal mit der Schokolade an. Da mir die Grundlagen des von Ihnen verwendeten Online-Portscans nicht bekannt sind, bitte ich Sie schlicht und ergreifend, Ihren Test mit diesem Onlinescan zu wiederholen.

Ich habe dies eben getan und konnte dabei keine Schokoladenseiten feststellen. Wenn ich die TCP-Ports 80 und 23456 im Speedport freigebe, dann meldet der Portscan, dass beide Ports geschlossen sind. Da ich keinen Apache auf den Ports lauschen lasse, weist der Server den TCP-Verbindungsaufbau (Three-Way-Handshake) korrekt zurück. Die Ports als solche werden vom Speedport nicht geblockt.

Nehme ich dagegen die Portfreigaben im Speedport raus und wiederhole den Online-Portscan, dann meldet der Portscan die Ports 80 und 23456 als gefiltert. Mit anderen Worten die Client-Anfrage kommt beim Server gar nicht erst an - egal, ob der Dienst läuft oder nicht.

Bei dem von Ihnen verwendeten Portscan scheint mir keine Unterscheidung zwischen gefiltert ("closed") und geschlossen ("closed") stattzufinden. Der Port 23456 wird als geschlossen identifiziert. Dies könnte auch ein Hinweis sein, dass der Apache den Verbindungsaufbau zurückweist (vielleicht blockt noch eine Personal Firewall). Dann wäre der Speedport "Außen" vor.  Deshalb meine Bitte, dies mit dem oben genannten Portscanner noch einmal zu wiederholen. Bitte posten Sie auch die Firmware Ihres Speedport.

Zum Zugriff auf den WLAN-AP: Hierzu wird vermutlich die Namensauflösung des APs benötigt. Da der Speedport-DNS-Server den Hostname des APs nicht kennt, müssten sie nach meinem Verständnis für einen administrativen Zugriff als DNS-Server fallweise den DNS-Server des APs wieder im IP-Stack des zugreifenden Gerätes aktivieren.

Echt spannende Themen! Halten Sie uns bitte auf dem Laufenden.

Viele Grüße

Johannes S.

[#21]

@Ulrich: Danke, ich habe die Option Bevorzugtes Band  im Treiber entdeckt. Dort gibt es zwar nur die Wahl zwischen a oder b/g, aber ich vermute a steht für 5GHz.

Portz tausend, das ist ja der reinste Tatport!

Ich habe den Heise-Portscanner probiert und heute klappt alles so wie Sie es beschrieben haben - Port ist offen/gefiltert wenn keine Portfreigabe eingerichtet ist, geschlossen wenn kein Dienst auf diesem Port lauscht und offen wenn ein Programm auch tatsächlich antwortet.

Interessanterweise erscheint der Port 23456 heute auch bei meinem anderen Online-Portscanner als offen, obwohl sich das Test-Setup nicht geändert hat. In beiden Fällen war ich im 2,4GHz-Netz des Speedports, der Port war gleich und im SP freigegeben, die Windows-Firewall war vollständig deaktiviert und ein Webserver lauschte auf dem Port auf Anfragen. (Vielleicht ein Montags-Router?)

Einziger Unterschied: bevor ich das "echte" Programm auf dem Port startete hatte ich ein NodeJS-Skript laufen, welches einen UDP-Echo-Server an 0.0.0.0:23456 gebunden hat. Ein UDP-Portscanner meldete den Port als offen und ich konnte die Nachricht im NodeJS-Terminal sehen. Bin gespannt ob es in ein paar Tagen mit dem tatsächlichen Programm von Anfang an klappt. Soweit scheint es jedenfalls in Ordnung, selbst wenn ich im AP-WLAN hänge (AP verhält sich offenbar transparent, um nicht zu sagen unsichtbar - auf das Webinterface kann ich schließlich nicht zugreifen).

Ich bin mir nicht sicher, ob der AP irgendwelche DNS-Funktionen bietet. Falls ja könnte es dennoch sein, dass ich diese nicht nutzen kann, weil alle NAT-Features deaktiviert sind und somit die meisten Funktionen vom AP nicht mehr genutzt werden können. Ich werde das bei Gelegenheit prüfen. Allerdings frage ich mich, ob DNS hier überhaupt helfen würde - schließlich versuche ich über die IP-Adresse auf die Web-Oberfläche zu gelangen (192.168.0.1) und nicht über tplinklogin.net.

Meine Firmware-Version ist übrigens 09011602.00.015 (momentan die aktuellste).

[#22]

Hallo, ich habe vor ein paar Tagen meinen alten w700v Router ersetzen müssen und habe mir im Telekomshop den w724v Typ A gekauft.

Ich habe das gleiche Problem wie alle hier, die Portfreigabe funktioniert einfach nicht, weder als Weiterleitung, noch als Umleitung.

Ich betreibe den Router am normalen DSL anschluss (17.000 mbit) mit normalem t-net Anschluss (also weder IP, noch ISDN), keine Telefonie (ist ja auch gar nicht möglich, kein Anschluss für "normales" Amt mehr am Router vorhanden).

Jede Funktion funktioniert, die Verbindung ist stabil, die DynDNS Anmeldung klappt, nur die Portfreigabe gar nicht.

Ich brauche eine (eigentlich) simple Portweiterleitung von Port 8888 TCP  + UDP für meine lokalen Teamspeak 3 Server, auf meinen PC anschluss per Kabel.

Mit meinem alten w700v war das überhaupt kein Problem, hat Jahrelang funktioniert.

Das der Router kein Nat Loopback kann ist mir bereits bewusst, deswegen habe ich mit dem hier genannten Port Check bei Heise.de geprüft. Aber egal was ich mache, es kommt immer "gefiltert" heraus.

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.

Ich habe auch einen Bluray Spieler im WLAN, Weiterleitung auf diesen getestet, geht auch nicht.

(Das hab ich nur testweise getan, standardmäßig ist das WLAN bei mir ausgeschaltet.)

Ich hab sogar gedacht es liegt evtl. am Port, also mal die 21 aufgemacht. Ergebnis "gefiltert".

Danach habe ich wie hier beschrieben auch die FTP freigabe für einen USB Stick ausprobiert und diese funktioniert einwandfrei. Meldung vom Portcheck "offen" für die 21, also die zu erwartende Antwort. (Vorher habe ich die nicht funktionierende Port 21 Weiterleitung natürlich gelöscht.)

Die Router Firware ist Version: 05011603.00.002, automatisch installiert.

Ich bin auch bereit einem Bearbeiter per Privatnachricht oder Email meine Dyn Adresse zu geben um selber nachzugucken oder eine Sicherung meiner aktuellen Router Konfiguration zu senden (inkl. der nicht funktionierenden Freigaben.) Aber öffentlich posten möchte ich verständlicherweise natürlich keines von beiden hier.

Also was nun? Ich will wirklich dringend diese Funktion wieder haben.

[#23]

Gleiches Problem.

Port 80 soll auf Port 80 (Raspberry Pi) umgeleitet werden.

Keine Chance!

Neuste Firmware installiert, Router nach Änderung der Einstellungen neu gestartet - nix.

Kann doch nicht sein, dass dieser Router solch eine simple Funktion nicht umsetzen kann!

[#24]

Hi,

wie wurde getestet das der Port 80 geschlossen ist?

Das geht beim 724 nur über www.canyouseeme.org da NAT loopback nicht funktioniert.

[#25]

Mittels Handy (nicht im WLAN); sprich IP in Browser eingegeben, keine Verbindung.

Und ja, der http Server läuft.

Und ja, ich habe nicht die LAN IP genommen.

[#26]

Kannst du ein Firewall-Problem ausschließen? Ggf. die einmal vorübergehend komplett deaktivieren (Windows Firewall und evtl. Virenscanner).

[#27]

Wie ich schrieb, läuft der http Server auf einem Raspberry Pi.

[#28]

Hi,

probiere mal einen anderen Port auf den 80er des RPI weiterzuleiten. Bsp. 8080

TCP 8080-8080  auf 80-80 192.168.2.x

und dann nochmal über canyouseeme.org prüfen ob der 8080 offen ist.

LG Insti