@Bytegetter – guter Punkt.

Hatte gerade eben 2x das Szenario, dass Traceroute sich im ersten und letzten Hop seeeehr abgemüht hat (je 1x Timeout) – aber letztlich erfolgreich durchging. VPN ist hingegen gescheitert…Vermutlich aufgrund der Latenz. “Früher" ging – wenn es nicht ging – konsequent auch ein Trace Route nicht. 

Nach einer Minute ging (mit unveränderten IPs) VPN dann plötzlich doch noch.

Und hier auch nochmal:

Mache ich morgen gleich muss bald los arbeiten. Die Karte ist derzeit ein Raum weiter  seltsam ist das ich auch mit den "Internet apn auf der Karte in der range komme d.h keine interne IP vergeben wird 1x 2x ? " Sonst war es definitiv vor ca 1-3 Wochen anders. Da wurde mir noch interne ips zugeteilt egal ob ich nun apn Internet oder netpub.... Nehme beides kommt fast auf die identischen ips  8x

Das ist was mich derzeit stutzig macht? 

Kein vpn an und in ein anderen Gerät ist es genau so.

Eigendlich sollte der netpub... Ja nicht gehen auf der Karte den dort wurde ja keine öffentliche gebucht !? Oder gilt dieser für den gesamten Account wo die Verträge drauf sind

Seltsam das ganze.

Dazu muss ich sagen der Vertrag wurde hier auch geändert auf unlimited . (O2 Handy Karte) 

genau.

die handys haben beide internet APN IPs 2.x.x.x

und auch nach mehrmaligen rebooten von handys und fritz.box: die fritz.box mit der public IP SIM karte bekommt immer eine 89.204.131.x oder 89.204.147.x IP.

und die sind nie von den normalen o2 SIM karten zu erreichen.

also um das für die o2 Mitarbeiter klar zu machen:

für mich funktioniert das immer noch nicht (und zwar gar nicht)

Ich habe hier in drei Versuchen aktuell nur IPs aus dem 89.204.147.x Block bekommen.

In keinem Fall war eine Verbindung von o2 Handy auf o2 Homespot möglich.

Von DTAG Anschluss auf o2 Homespot funktionierte jedes Mal.

Von Server im Rechenzentrum funktionierte die Verbindung zum o2 Homespot jedes Mal.

Ich würde gerne ausführlicher testen, wenn ich allerdings noch einmal den Stream töte schlafe ich heute Nacht in der Badewanne oder im Treppenhaus... , da geht die Frau wohl vor ;)

@ausdemdorf

ist dein Setup gerade

„internet“ —> „netpublic“ oder

„netpublic“ —> „netpublic“?

Sag deiner Frau, es sei für ihre Sicherheit :o)

mein Setup:

Mobile mit o2 Sim, APN internet

versucht auf

Homespottarif (in Huawei), APN netpublic

zu verbinden.

Was sich vor ca zwei Tagen zum Guten gewendet hat:

Das Routing auf live.twitch.tv.

Ich wurde bis dato immer von hier (Nähe Dortmund) nach Frankfurt, nach München an den BECIX in Berlin geroutet, wobei der DECIX etwas näher gelegen wäre.

Jetzt gehts von hier direkt an den DECIX, was sowohl Jitter als auch teils arge Ruckler auf 1080P absolut negiert hat.

Also sind die Kollegen aktuell wirklich dabei die Routen der Pakete zu kontrollieren , die letzten drei Wochen lief es nämlich gar gruselig mit der anderen Route.

So, habe noch ein paar Mal getestet. War schon voller Zuversicht und dann kam wieder eine IP mit der es nicht ging... 

89.204.131.252 - > 89.204.147.213 geht
89.204.147.81 - > 89.204.147.213 geht
89.204.147.9 - > 89.204.147.213 geht
89.204.131.51 - > 89.204.147.183 geht
89.204.131.51-> 89.204.131.67 GEHT NICHT

@KrawallOPA: Ging beim letzten „geht nicht“ sowohl Trace Route als auch VPN nicht – oder ging TR und nur VPN nicht? 
 

Zwischenstand: Dann haben sind wir aktuell drei User, bei denen 2.x.x.x & 46.204.x.xaNAT-Gateway] zu „89.204.x.x („internet“ —> „netpublic“) noch nicht geht.

Bei zwei Usern funktioniert zum jetzigen Zeitpunkt zumindest 89.204.x.x & 46.204.x.xmöffentl.] zu 89.204.x.x („netpublic“ —> „netpublic“) etwas umfangreicher als zuvor.

Testen wir mal alle (morgen) weiter...

Das kann auch an noch laufenden Sessions auf dem Utran liegen. Nach einer Trennung _kann_ das wieder anders aussehen.

Netzwerkgeräte merken sich den Trafficflow (Socket zu Socket), so dass hier ggf. auch noch eine gewisse Verzögerung bis zur Besserung ergibt.

@ThomasA_FFM Traceroute habe ich nie probiert, nur VPN.

Gerade noch mal probiert. IP @Home ist geblieben, nur neue IP auf dem Handy.... Funzt 

Vielleicht hat @Bytegetter recht... 

89.204.147.29-> 89.204.131.67 geht

also bei mir nach einem Tag und mehrmaligem rebooten von Handys und Fritz.box:

ich kann immer noch nicht von o2 Handys mit normaler IP (2.x.x.x.) auf den server mit public IP zugreifen (89.204.x.x)

Also tracer von 02 Karte zur o2 Host . Gehen alle Hops verloren (Verbindung ist da Google tracen funkt.)

KD sind 6-7 Hops endet auf meiner öffentlichen o2 host IP. 

Online tracer enden ebenfalls auf meiner öffentlichen o2 Host IP

Von der Arbeitsstätte (wlan  nicht bekannter Anbieter funktioniert es auch)

Die KD Leitung ist im selben Ort jedoch nicht im selben Haushalt.

Bin nachher noch im anderen Ort und teste es dort auch nochmal.

Das verhalten einiger Switche ist halt manchmal etwas seltsam.

BTW: Die Portierungsnasen aus Hamburg haben es geschafft meinem Mitarbeiter zu antworten und nach nur drei Anläufen den PDA zwischen uns und TF zum laufen zu bringen. Immerhin. Im Juli hatten wir damit angefangen.

Hi zusammen. 

Puuh, da qualmt mir der Kopf beim lesen :-) 

Wenn ich ehrlich bin konnte ich jetzt kein wirklich Muster erkennen, wann es geht und wann nicht, oder übersehe ich da was (bis auf die Geschichte mit dem IP Ranges) ?  

VG Matze 

Ich sehe bei meinen Versuchen ein Muster! 

Wie man sieht funktioniert es nicht, wenn der 3. IP Block bei Beiden **. ***.131. **! 

89.204.131.252 - > 89.204.147.213 geht
89.204.147.81 - > 89.204.147.213 geht
89.204.147.9 - > 89.204.147.213 geht
89.204.131.51 - > 89.204.147.183 geht
89.204.131.51-> 89.204.131.67 GEHT NICHT
89.204.147.29-> 89.204.131.67 geht
89.204.131.154->89.204.131.67 GEHT NICHT

aber schon mal gut das es dort bei eure ranges etwas funzt bzw “ort-Stadt”  den arbeitet erstmal daran.

hier geht nichts alle Traces die ich versuche laufen zu lassen sind sotort “timeout” zumindest von der o2 karte auf o2 host da spielt auch keine rollte ob ich das ganze 10min laufen lasse.  (das ganze habe ich nun mit unterschiedlichen ips durch) hier “unten” scheint der wurm tiefer zu stecken   (aber auch 40km weiter weg andere mast sieht es so aus.)

Von kd Anschluss sind in 7-18 hops da und kaum Verzögerungen. 

also von einer normalen o2 IP (2.x.x.x) komme ich nie auf meinen LTE server mit public IP.

Und ich habe bisher hier niemand gesehen, der sagte, dass das wieder funktionieren würde

Ich teste aktuell vom Büro aus und konnte direkt verbinden, allerdings hat der Router aktuell auch den unproblematischen 46.x Block bekommen, mein Mobile mit APN internet ebenfalls…

Für weitere Tests kann ich leider den Router nicht ohne Absprache von hier aus neu starten, nicht das ich noch einen auf den Deckel bekomme ;)

Screenshot Traceroute Router zu Mobile:

Screenshot Traceroute Mobile zu Router:

Das war dann ein Gutfall. Die nächsten Stunden/Tage komme ich hoffentlich zu weiteren Schlechtfällen.

Mobiltelefon: 89.204.153.99

Homespot: 89.204.147.226

Keine Verbindung möglich, Traceroutes rennen sich von Handy zu Homespot tot, dort taucht nichtmals ein Hop auf.

Homespot zu Handy bricht mittendrin ab (wie erwartet, das Mobile benutzt ja auch keine öffentliche IP):

traceroute 89.204.153.99
traceroute to 89.204.153.99 (89.204.153.99), 30 hops max, 38 byte packets
 1  192.168.8.1 (192.168.8.1)  1.536 ms  0.533 ms  0.894 ms
 2  *  *  *
 3  10.96.85.154 (10.96.85.154)  32.518 ms  31.826 ms  38.944 ms
 4  82.113.103.70 (82.113.103.70)  39.940 ms  22.860 ms  26.895 ms
 5  IARFRA1-Gi0-2-199.net.de.o2.com (82.113.103.34)  37.972 ms  46.867 ms  34.926 ms
 6  ae6-510.20.xmws.99.fra.de.net.telefonica.de (62.53.2.54)  36.995 ms  46.807 ms  45.018 ms
 7  ae0-0.0002.inrx.01.dus.de.net.telefonica.de (62.53.18.123)  49.946 ms  40.831 ms  ae10-0.0002.inrx.01.dus.de.net.telefonica.de (62.53.26.166)  57.978 ms
 8  62.52.18.102 (62.52.18.102)  33.842 ms  39.823 ms  36.951 ms
 9  *  *  *
10  *  *  *
11  *  *  *

und noch die nächsten 19 HOPS *  *  *

Die Route 89.204.153.x zu 89.204.147.x funktioniert für mich nicht.

Also zusammengefasst,

„internet“ —> „netpublic“ geht unverändert nicht (bei keinem, der hier getestet hat);

„netpublic“ —> „netpublic“ funktioniert hingegen.

Stimmt das so?

Kann ich so zustimmen zumindest bei den Internet apn auf netpublic.

 Das andere kann ich nicht testen.

im prinzip ja, das stimmt so.

ich würde aber auch sagen von interner IP auf public IP geht nicht.

wenn ich an meinem Handy den APN von internet auf netpublic stelle und neue zum mobilnetz connecte, ändert sich nichts. ich kann weiterhin im internet surfen, aber ich habe immer noch eine 2.x.x.x IP und ich kann im mer noch nicht auf die public IP 89.204.x.x zugreifen

und ob netpublic zu netpublic funktioniert ist eigentlich irrelevant. ich habe eine IP Kamera an meiner fritz.box und darauf sollen einige familienmitglieder zugreifen können (davon haben 4 leute o2 verträge). vor ich 200€ für public IPs bezahle, werde ich o2 verlassen und zu einem anderen anbieter gehen.

und um dem problem nachdruck zu verleihen habe ich mich das problem per email an impressum@cc.o2online.de kommuniziert.

Ah stimmt… 89.204.131.x zu 89.204.131.x funktioniert bei Dir nicht.

Bei mir zwar schon (bsp. 89.204.131.177 → 89.204.131.18 funktioniert), aber mit sehr hohen Verzögerungen im Tunnelaufbau.

———————————-

@o2_Kurt / @o2_Matze 

Kurz für euch zusammengefasst: 

„internet“ —> „netpublic“  also Verbindungen vom CG-NAT zu einer öffentlichen o2-IP gehen unverändert nicht (bei keinem, der hier getestet hat); Hier besteht noch Handlungsbedarf!

„netpublic“ —> „netpublic“ geht nun zwar in vielen Fällen – jedoch oft auch nicht:

Man scheint hier vermutlich zwar einige Routen aufgesetzt zu haben – aber womöglich nicht vollumfänglich alle relevanten „Kombinationen“.

Nach Beobachtungen von @KrawallOPA funktionieren Verbindungen von 89.204.131.x zu 89.204.131.x nicht. Bei mir hingegen schon (jedoch mit starken Verzögerungen beim Tunnelaufbau).

.Denkanstöße:

a) Werden/wurden die Routen zentral angepasst oder dezentral an mehreren Knoten? Wurde hier vielleicht für eine Region die Konfig. von x.131.x —> x.131.x (und evtl. auch anderen Kombinationen, die uns noch nicht untergekommen sind) vergessen?

b) Ist das Routing von x.131.x —> x.131.x eventuell zwar theoretisch okay, aber so quer durch Deutschland verschaltet, dass es zu hohen Verzögerungen/Latenzen kommt und daher bei @KrawallOPA praktisch kein Tunnel aufgebaut werden kann?]

Hier besteht also ebenfalls noch Nachbesserungsbedarf: Hat man wirklich für alle Public-IP-Kombinationen entsprechende Routen aufgesetzt oder wurden welche übersehen? Sind die Routen so, dass die Latenzen in einem vertretbaren Rahmen sind?

Randnotiz: Verbindungen von 89.204.147.x zu 89.204.131.x vice versa] scheinen hingegen nun stabil zu laufen.

Nachtrag:

Hab nochmal etwas intensiver mit Geräten rumgespielt und mehrmals neu einwählen lassen: 

Nun wie bei @KrawallOPA: 89.204.131.x zu 89.204.131.x  ist - komplett - tot. Heute morgen ging 

89.204.131.138 → 89.204.131.62 �Kein VPN, kein tracert]

89.204.131.138 → 89.204.131.149 �Kein VPN, kein tracert]

89.204.131.62 → 89.204.131.49 2Kein VPN, kein tracert]

Heute Vormittag ging 89.204.131.177 → 89.204.131.18 noch (wenn auch langsam).

@o2_Matze / @o2_Kurt Also wie schon obendrüber in der Zusammenfassung gesagt: Nachbesserungsbedarf bei den Routen. netpublic → netpublic funktioniert zwar jetzt in einigen Fällen, aber viel zu oft auch eben nicht. Danke für eure Nerven :)