IMAP Portforward ( FritzBox ) zur DiskStation - Time Out?

[theunexpecteds]

Habe die Mailstation installiert. Da funktioniert auch alles soweit.
Auch den SMTP Port per Portforward freizugeben hat funktioniert, E-Mail flattern im Postfach ein.

Nur mit einem E-Mail Client per IMAP darauf zugreifen geht nicht.

Weder Port 143 nocht mit SSL 993 ermöglichen es.

Wenn man von außen prüft, die Ports sind offen und erreichbar.
Aber allein wenn man versucht per Telnet auf diese Ports über die Internet IP zuzugreifen, ist ende im Gelände. ( im LAN geht das)

Wer stellt sich hier also zu blöde an, die FritzBox, die DS oder Ich?

 

[theunexpecteds]

AhhhhHaaaaa!
Also wenn man sich nicht im lokalen LAN befindet, wo auch die DS durch Portforwards durch die FritzBox erreichbar ist, funktioniert die Geschichte.

Ist natürlich beschmiert, dann müsste man jedesmal im E-Mail Client alles umstellen.
Eine Lösung hätte schon etwas....

 

[thedude]

Das ist ein typisches Problem von vielen soho routern. Zugriffe über nat/pat "von innen" auf die "aussen" adresse funktionieren nicht. Da kannst du nicht viel machen ausser auf einen anderen Router umsteigen, der das unterstützt. (Ich kenne ad hoc keinen.)

gruss
dude

 

[theunexpecteds]

Komisch ist nur, das HTTP Portforwarding funktioniert. (zur DiskStation, aber auch zu anderen Rechnern im Netzwerk)

Da stellt sich mir die Frage, wieso es bei einem Protokoll geht und beim anderen nicht.
Wie gesagt, beim Imap Port funktioniert nichtmal telnet, bei HTTP funktioniert sogar das Protokoll.

 

[jahlives]

Komisch ist nur, das HTTP Portforwarding funktioniert. (zur DiskStation, aber auch zu anderen Rechnern im Netzwerk)

Da stellt sich mir die Frage, wieso es bei einem Protokoll geht und beim anderen nicht.
Wie gesagt, beim Imap Port funktioniert nichtmal telnet, bei HTTP funktioniert sogar das Protokoll.

Woher weisst du, dass das http Forwarding wirklich gegriffen hat? tracert gemacht?
Ich vermute dein Client hatte den Hostnamen mit der LAN IP noch im DNS Cache und hat damit direkt zur DS verbunden, ohne Umweg via externe Schnittstelle des Routers.
Leere mal den DNS Cache des Clients und versuche es nochmals via http. Bin fast 100% sicher, dass es dann nicht mehr klappen wird

 

[theunexpecteds]

ähm, momente, wie soll denn der DNS da ne rolle spielen.

Lokal im Netzwerk ist die DS unter http://diskstation erreichbar.

Im WAN per http://meine.dyndns.org (bzw. die aktuelle IP )

Befinde ich mich nicht im LAN der DS, funktioniert per meine.dyndns.org alles, http, Imap usw.
Befinde ich mich im LAN und versuche es per meine.dyndns.org, geht nur noch http, nicht mehr IMAP...?!

 

[jahlives]

ähm, momente, wie soll denn der DNS da ne rolle spielen.

Lokal im Netzwerk ist die DS unter http://diskstation erreichbar.

Im WAN per http://meine.dyndns.org (bzw. die aktuelle IP )

Befinde ich mich nicht im LAN der DS, funktioniert per meine.dyndns.org alles, http, Imap usw.
Befinde ich mich im LAN und versuche es per meine.dyndns.org, geht nur noch http, nicht mehr IMAP...?!

Weil dein Client im LAN eventuell bereit weiss, dass meine.dyndns.org eigentlich der Client 192.168.X.X ist und damit den Request gar nicht Richtung Internet schickt. Drum der Tipp mal den DNS Cache zu löschen und dann nochmals zu gucken, ob es immer noch geht. Alternativ kannst du mal auf deinem Client einen nslookup nach meine.dyndns.org machen. Ich wette ein Bier, dass dabei eine lokale LAN IP Adresse bei rauskommt.
Ich hätte auf jeden Fall keine andere Erklärung parat warum http funzen sollte und andere Protokolle ned. Weil entweder kann es der Router oder er kann es nicht. Das sollte keinesfalls vom verwendeten Protokoll abhängig sein

 

[theunexpecteds]

Frage: Portforwarding bei NAT/IP maskerading

meine.dyndns.org ist ja eine öffentliche IP

durch NAT müsste die private IP auch bei Portforwarding ja nicht bekannt sein

wie bzw. warum sollte der client dann ermitteln das die IP im lokalen Netz ist?

Ich bin leider unterwegs und greife nur von extern auf die DS zu, was ja auch wunderbar funktioniert.

Greetz

 

[jahlives]

Jeder Client hat einen DNS Cache. Dort speichert er die bereits aufgelösten IP Adressen zu den Hostnamen für eine bestimmte Zeit, damit er nicht jedesmal den DNS Server abfragen muss. Meine Vermutung war jetzt, dass der Browser zu deinem dyndns Namen die interne LAN IP gespeichert hatte und darum der Zugriff via http klappen konnte. Darum hätte mich das Resultat eines nslookups nach deinem dyndns Namens wundergenommen.
Allerdings sollten dann eigentlich alle Protokolle davon betroffen sein d.h. dann müsste es auch mit IMAP klappen. Vielleicht findest du beim Routerhersteller eine Info warum es nur mit http klappen will. Eventuell machen die bei http Verbindungen etwas anders als beim Rest der Protokolle.
Probiers mal mit folgendem Test:
Leg dir eine index.php in /volume1/web an mit folgendem Inhalt

echo $_SERVER['REMOTE_ADDRESS'];

und ruf die Seite aus dem LAN via dyndns Namen auf. Wenn du dann eine lokale IP angezeigt bekommst, wüssten wir dass der Request nicht nach aussen ging, also mit der internen IP beantwortet wurde.

Gruss

Tobi

p.s. könnte auch sein dass es REMOTE_ADDR heissen muss