Manuelle Portfreigabe seit 1.03.2016

[Schokobiene]

Hallo.
Ich bin 2 Jahre Kunde bei Telecolumbus. Bin eingestiegen mit Internet 60 und dem Standardkasten von Telecolumbus + Dlink Router DIR-600. Seit dem 1.3. ist ja nun das Internet 120 der niedrigst Mögliche Tarif hier und wurde auch Umgestellt. Nun zum Problem, die Portfreigabe Funktioniert über Nacht nun nicht mehr... bekomme keinen Port mehr frei seit der Umstellung. Vorher 2 Jahre keine Probleme damit. Teste es wie schon immer nebenher mit PFPortChecker usw. aber nix.

Was mir aufgefallen ist an der 1. Rechnung, sie haben nun das Sicherheitspaket ohne Nachfrage Rotzfrech mitgebucht. Kann es daran liegen ?

[knusper-muesli]

Hi,

https://www.telecolumbus.de/sicherheitspaket/

Das Sicherheitspaket können Sie in Kombination mit unseren Internet-Produkten nutzen. Auf Wunsch erhalten Sie es sogar die ersten 3 Monate gratis zum Testen⁶. Danach kostet der optimale Schutz nur 4,99 € im Monat.

Einfach rechtzeitig kündigen, das war es dann.

Grüße

[berndione]

Schaue mal welche WAN IP Adresse du von TC bekommen hast. Sollte diese mit 100 (100.x.x.x) beginnen setzt TC jetzt CGN bei dir ein. Setzt du DDNS ein ? Das funktioniert bei CGN nicht mehr ohne weiteres. Deine Portweiterleitungen fuktionieren prinzipiell noch, nur ist der Router von außen nicht mehr erreichbar.
Die gute Nachricht ist dass es Lösungen für dieses Problem gibt. Lies dir mal folgenden Threat durch:

Time Capsule Apple und Telecolumbus Anschluss

[Mase]

habe das selbe Problem, mehrfach schon im Februar gehabt, nun geht GARNIX mehr .
WAN-IP is 100.xxx.xxx.xxx ... , das soll echt nen schlechter scherz von denen sein? Mir ist es doch wohl selbst ueberlassen welche Ports ich öffne , und welche nicht? (im prinzip offen, jedoch nicht von außen erreichbar -> heißt fuer mich , geschlossen, da es keinen effekt hat)

Lösung dazu?
Weil sowas ist fuer mich ein eingeschraenkter Internetanschluss , ohne moegliche Portöffnungen.
-> Kündigungsgrund

[berndione]

Für eine Kündigung wird diese Einschränkung wohl nicht reichen. Ausnahmsweise ist TC hier einmal unschuldig. Der IPv4 Adressraum ist halt ausgeschöpft. Deshalb muss TC eine IPv4 Adresse für mehrere Nutzer verwenden.
Aber es gibt Lösungen. Ich habe es mit dem DDNS Anbieter NOIP.COM gelöst. Bei mir läuft ein Raspberry PI, der ein mal pro Minute NOIP kontaktiert. NOIP ermittelt aus der Anfrage meine aktuelle WAN IP. Diese wird dann mit einer Adresse wie zB: "meinName.ddns.net" verknüpft. Über diese Adresse kann ich mein HomeLAN erreichen und alle Portweiterleitungen funktionieren wieder. Es soll auch Router geben, die dies können.
Oder du stellst komplett auf IPv6 um.

[Kabelglotzer]

Deine Lösung ist für technisch versierte Personen geeignet, aber nicht für Normal-Nutzer-Kunde bei TC

[berndione]

Nun wir haben ja hier die PI Lösung schon einmal mit jemanden realisiert der auch kein Netzwerkprofi war. Hat zwar etwas gedauert aber letztlich hat es funktioniert.

[Kabelglotzer]

Ist aber keine Lösung. Man kann die IPv4 Knappheit nicht dem Kunden aufbürden. Der Kunde muss sich doch nicht um den Empfang seiner Daten bemühen, wenn er einen Vertrag hat. Und man kann doch von einen IN-Anschluss verlangen, Stecker rein und los mit Zocken, Spielen, E-Mails u.u.u. Dazu muss ich doch keine Hilfsmittel verwenden.

[berndione]

Prinzipiell hast du ja recht. Aber das ist ja kein Problem das nur TC hat. Was sollen die Provider machen wenn es keine Adressen mehr gibt. Und IPv6 ist ja auch möglich und die Zukunft.
Ich glaube für 99% ist CGN auch kein Problem. Denen reicht es wenn das Aufrufen von Webseiten funktioniert. Selbst wenn man Heimautomatisierung betreiben will ist CGN kein Problem. Professionelle Lösungen sind Server basiert und benötigen keine Portweiterleitungen.
Wenn Schokobiene Portweiterleitungen einrichten kann dürfte auch die PI Lösung kein Problem sein.
Notfalls helfen wir halt ein wenig.

[Mase]

ich muss mich meinen vorredner anschließen, das die keine IPV4 adressen bereitgestellt bekommen, ist nicht mein Bier, ich möchte meinen Anschluss im vollem Umfang nutzen.

Ich habe (da ich mir das schon denken konnte....) parallel noch meinen 16/1mbit tarif bei der Telekom laufen. da hab ich auch meine eigene adresse und kann alle Ports Forwarden .

Ich bin technisch versiert, Rasp. Pi ist mir durchaus ein begriff, jedoch sehe ich absolut nicht ein, mir zusaetzliche technik zuzulegen um meinen Internet-anschluss so nutzen zu koennen, wie ich das gerne haette.

Also telecolumbus hat sich erst mit der Wlanbox , dann nach 4 monaten mit ueberbuchung (sind NEU in Merseburg 06217 seit Agust 2015), und nun mit dem Port Forwarding ins Knie geschossen, also langsam ist das Fass voll.
Langsam stelle ich die kompetenz dieser Firma ernsthaft infrage.

[fqges3clld6z]

Carrier-grade NAT (CGN) ist nicht gleich CGN - da es verschiedene Typen von NAT gibt. Telecolumbus setzt einen sehr unüblichen Typ ein, 1:1-NAT - was bedeutet, dass eine externe Adresse auf genau eine interne Adresse übersetzt wird.

Als Folge dessen spinnt zwar die eine oder andere Software (bspw. DDNS), da sie die echte IP-Adresse, unter der man erreichbar ist, selber nicht sieht (nur die interne), aber generell ist das mit wenig Einschränkungen verbunden. Portfreigaben sind kein Problem, da jeder Port der externen Adresse genau so an die interne weitergeleitet wird - es ist ja ein 1:1-NAT.

Zu Hause (der Router) und auch einige andere Kabel-Anbieter setzen einen anderen NAT-Typ ein (asymmetrisches NAT), der als großer Unterschied eine externe auf viele interne Adressen übersetzt (1:many NAT). Daher sind dort manuelle Portfreigaben nötig (wie im Router). Da die Kabelbetreiber aber (im Gegensatz zum Router) kein Web-Interface für Portfreigaben haben, ist es praktisch so, dass man keine einrichten kann.

Folgerung:
Bislang setzt Telecolumbus 1:1-NAT ein, womit der OP zurecht kommt (DDNS hin oder her) - sollte dies nicht mehr funktionieren, könnte eine Umstellung auf 1:many-NAT die Ursache sein. Ich bin noch im alten Tarif und habe weiterhin 1:1-NAT - evtl. können Nutzer mit den neuen Tarifen das testen.

[berndione]

Genau, das Problem ist nicht die Portweiterleitung sondern das Nichtfunktionieren von DynDNS. Eine Portweiterleitung macht in der Regel aber nur Sinn wenn die Public IP bekannt und erreichbar ist.

@Mase
Der Themenersteller hat sicher kein Interesse an einer Diskussion wie gut oder schlecht TC ist. Hier geht es darum Lösungen vorzustellen die die Einschränkungen durch CGN aufheben. Wenn du daran kein Interesse hast ist das völlig in Ordnung. Aber dem Einen oder Anderen hilft es vielleicht. Und das ist ja schließlich auch der Sinn des Forums.
Du bist ja nach eigener Aussage vertraut mit Netzwerktechnologie. Dann nutze doch IPv6. TC stellt ja einen vollwertigen IPv6 Zugang mit DualStack zur Verfügung. (Um Fragen vorzubeugen: Das Präfixproblem ist mir bekannt ). Diese Lösung kommt ohne zusätzliche Hardware aus.

[fqges3clld6z]

Genau, das Problem ist nicht die Portweiterleitung sondern das Nichtfunktionieren von DynDNS. Eine Portweiterleitung macht in der Regel aber nur Sinn wenn die Public IP bekannt und erreichbar ist.

Wenn ich den OP richtig verstanden habe ist eben DDNS nicht das Problem (da die Konfiguration vor der Umstellung scheinbar funktionierte) - sondern eben die Portweiterleitungen (die nicht mehr funktionieren).

[berndione]

Wenn er seine Public IP kennt und über diese IP auf seinen Router zugreift, warum sollten dann die Portweiterleitungen nicht funktionieren ?

[fqges3clld6z]

Wenn er seine Public IP kennt und über diese IP auf seinen Router zugreift, warum sollten dann die Portweiterleitungen nicht funktionieren ?

So wie ich den OP verstehe kann er eben nicht "auf seinen Router zugreifen".

[berndione]

Genau so habe ich es auch verstanden. Um von außen zugreifen zu können ist aber in der Regel DynDNS erforderlich. (Es sei denn dein Provider spendiert die eine statische public IP). Und DynDNS funktioniert wegen CGN nicht mehr. Das bedeutet das der Router eine falsche IP (Nämlich die IP nach CGN 100.xxx.xxx.xxx) an den DynDNS Dienst liefert. Unter dieser IP ist der Router natürlich nicht erreichbar.

[fqges3clld6z]

Genau so habe ich es auch verstanden. Um von außen zugreifen zu können ist aber in der Regel DynDNS erforderlich. (Es sei denn dein Provider spendiert die eine statische public IP). Und DynDNS funktioniert wegen CGN nicht mehr. Das bedeutet das der Router eine falsche IP (Nämlich die IP nach CGN 100.xxx.xxx.xxx) an den DynDNS Dienst liefert. Unter dieser IP ist der Router natürlich nicht erreichbar.

DynDNS funktioniert selbstverständlich weiterhin, nur nicht über die WAN-IP (was auch nicht immer die Standardkonfiguration ist).

Der OP hat spezifisch angemerkt, dass es seit dem 1.3. nicht mehr funktioniert - CGN läuft aber schon seit geraumer Zeit. Da Porttests aus dem internen Netz ohne NAT-Hairpin ohnehin nicht möglich sind hat er mit PFPortChecker einen externen Tester verwendet - der automatisch die externe IP erkennt (CGN hin oder her).

Zusammengefasst: DynDNS ist für einen externen Porttest NICHT nötig, da die zuständige Software automatisch mit der 'echten' WAN-IP arbeitet.

Schlußfolgerung: Entweder blockiert etwas die Portfreigaben (z.B. eine neue Router-Firmware, das Sicherheitspaket), oder Telecolumbus hat den CGN-Typ von 1:1-NAT bei den neuen Tarifen auf 1:many-NAT geändert.

[berndione]

Der TE hat nur geschrieben dass seine Portweiterleitungen nicht mehr funktionieren. Ob und wenn ja welchen Portscanner er verwendet hat geht aus seinem Statement nicht hervor. Die üblichen Anwendungen (Eigener Server, IPcam aus dem Internet erreichen, Ports für Spiele) brauchen die Kenntnis der public IP. Diese können die meisten der in der in Routern implementierten DynDNS Clients wegen CGN nicht mehr ermitteln. Es gibt auch Ausnahmen aber zB. die allseits beliebten Fritzboxen können es nicht.
Nur dies habe ich behauptet. Das es auch Software gibt die die public IP selbst ermitteln kann, habe ich nie bestritten. Natürlich sind auch andere Ursachen denkbar. Das müssten wir dann gemeinsam mit dem TE untersuchen.

[fqges3clld6z]

Teste es wie schon immer nebenher mit PFPortChecker usw. aber nix.

Das klärt das ob und welchen, denke ich.

[berndione]

Stimmt. Na ja, wenn man lesen kann hat man halt Vorteile .

[Schokobiene]

das blöde ist halt das es seit 2 jahren lief :p

hab nix an der hardware geändert, nix an den einstellungen garnix. ist halt dummerweise mit der umstellung reingekommen von TC aus.

[oschn]

Also, dieses Sicherheitspaket scheint nur eine Software (F-Secure) zu sein, die man manuell und lokal installieren muss. Daran dürfte es also nicht liegen.

Was zeigt PFPortChecker denn als externe IP an?
Kann es sein, dass die Box die letzten 2 Jahre im Bridge-Modus lief, nun durch die Umstellung wieder im Router-Modus?
Wurden auf der TC Box auch Portweiterleitungen erstellt oder nur auf dem D-Link?
Wurde DynDNS früher auf der TC-Box oder auf dem D-Link konfiguriert?

Ich sehe hier mehrere verschiedene Szenarien, die zutreffen könnten, warum es AUF EINMAL nicht mehr geht, die aber trotzdem noch eine Lösung zulassen. Sollte TC bei neuen Anschlüssen auf 1:many NAT umgestellt haben, dann geht leider so ohne weiteres nichts mehr (außer IPv6).

Meinte Theorie: Die letzten 2 Jahre lief der Vertrag nach alten Bedingungen und vielleicht gab es damals noch eine richtige Public IP, die auch direkt an der Kabelbox anlag. Wenn die Kabelbox dann noch im Bridge-Modus war, hat sie die öffentliche IP einfach an den DLink "weitergereicht". Damit konnte DynDNS und Portforwarding auf dem DLink eingerichtet werden und funktionierte auch. Nun mit der Umstellung wurde der Anschluss ins CGNAT aufgenommen, evtl. die Box von TC wieder von Bridge auf Router umgestellt. Dann die Sache mit PFPortChecker. Ich weiß nicht, wie der die externe IP ermittelt. Evtl. erkennt der auch nur die CGNAT-IP.
Evtl. trifft auch nur der Teil mit der Rückstellung des Modems von Bridge in Router. Naja, ich sehe da noch nichts als verloren.