T-Mobile Unlimited geen verbinding naar t-mobile thuis.

@Solusjen-Laurens Niet dat het iets oplost, maar doe maar eens een traceroute vanaf je T-Mobile Thuis LAN naar een willekeurige grote internetsite. Als je 10.x.x.x adressen ziet tussen je router WAN IP adres en die internetsite, dan vindt op die link ongewone routing plaats, eigenlijk NAT, strict genomen.

tmoesel schreef:

@Solusjen-Laurens Niet dat het iets oplost, maar doe maar eens een traceroute vanaf je T-Mobile Thuis LAN naar een willekeurige grote internetsite. Als je 10.x.x.x adressen ziet tussen je router WAN IP adres en die internetsite, dan vindt op die link ongewone routing plaats, eigenlijk NAT, strict genomen.

Dat klopt niet helemaal.

T-Mobile maakt namelijk ook gebruik van 10.x.x.x adressen voor de routering binnen hun eigen netwerk, en daar is zeker geen sprake van NAT.

jeffrey@latitude:~$ traceroute www.t-mobile.nl
traceroute to www.t-mobile.nl (80.79.204.11), 30 hops max, 60 byte packets
1 * * *
2 1-83-143-37.ftth.glasoperator.nl (37.143.83.1) 8.791 ms 9.044 ms 9.676 ms
3 10.10.10.57 (10.10.10.57) 9.587 ms 9.591 ms 10.478 ms
4 * * *
5 80.79.204.11 (80.79.204.11) 10.665 ms 11.453 ms 11.681 ms

En zoals @Solusjen-Laurens al aangaf, werkt het wel als hij zijn server probeert te bereiken vanaf een ander netwerk dan het T-Mobile 4G netwerk. Van ongunstige routing aan zijn kant van de link is dus geen sprake.

Jeffrey87 schreef:

tmoesel schreef:

@Solusjen-Laurens Niet dat het iets oplost, maar doe maar eens een traceroute vanaf je T-Mobile Thuis LAN naar een willekeurige grote internetsite. Als je 10.x.x.x adressen ziet tussen je router WAN IP adres en die internetsite, dan vindt op die link ongewone routing plaats, eigenlijk NAT, strict genomen.

Dat klopt niet helemaal.

T-Mobile maakt namelijk ook gebruik van 10.x.x.x adressen voor de routering binnen hun eigen netwerk, en daar is zeker geen sprake van NAT.

Dat is maar wat je als NAT beschouwt. In een thuisrouter wordt een overgang tussen een publiek en privaat netwerk NAT genoemd.
In b.v. jouw traceroute is ook een overgang tussen een privaat en publiek netwerk te zien. Met 10.10.10.57 gedefinieerd als privaat en 80.79.204.11 (en ook 37.143.83.1) als publiek. Dat noem ik ongunstige routing, puur vanwege het gebruik van private adressen buiten en thuisLAN van een klant.

Als je de route anderom beschouwt, dus van 'internet' naar je thuis router, kom je vanaf internet/publiek netwerk in privaat netwerk (10.10.10.57) dan weer een publiek IP adres (37.143.83.1) en vervolgens weer privaat adres (192.168.1.1).

jeffrey@latitude:~$ traceroute www.t-mobile.nl
traceroute to www.t-mobile.nl (80.79.204.11), 30 hops max, 60 byte packets
1 * * *
2 1-83-143-37.ftth.glasoperator.nl (37.143.83.1) 8.791 ms 9.044 ms 9.676 ms
3 10.10.10.57 (10.10.10.57) 9.587 ms 9.591 ms 10.478 ms
4 * * *
5 80.79.204.11 (80.79.204.11) 10.665 ms 11.453 ms 11.681 ms

En zoals @Solusjen-Laurens al aangaf, werkt het wel als hij zijn server probeert te bereiken vanaf een ander netwerk dan het T-Mobile 4G netwerk. Van ongunstige routing aan zijn kant van de link is dus geen sprake.

Als nu de 4G link ook dergelijke routing vertoont (b.v. APN internet wordt gebruikt), weet ik niet hoe de route loopt van 4G device naar thuisLAN. Blijft het binnen dit 10.x.x.x? En is dat de reden dat het spaak loopt?
Of gaan beide links via het 'internet', dus treden buiten het interne TMO netwerk en is dat juist de reden dat het spaak loopt?

tmoesel schreef:

Dat is maar wat je als NAT beschouwt. In een thuisrouter wordt een overgang tussen een publiek en privaat netwerk NAT genoemd.
In b.v. jouw traceroute is ook een overgang tussen een privaat en publiek netwerk te zien. Met 10.10.10.57 gedefinieerd als privaat en 80.79.204.11 (en ook 37.143.83.1) als publiek. Dat noem ik ongunstige routing, puur vanwege het gebruik van private adressen buiten en thuisLAN van een klant.

Dit is een transparante firewall routering, en wordt door veel enterprise-level networking devices aangeboden om niet onnodig veel public IP space te gebruiken voor interne network hops.

Bij deze techniek is er geen sprake van port forwarding of whatsoever, maar wordt alles gewoon 1 op 1 doorgezet.

In meerdere netwerken die ik beheer (zakelijk) wordt deze methode ook toegepast.

Ik begrijp je onderbouwing, echter is een 10.0.0.0/8, 192.168.0.0/16 of 172.16.0.0/12 adres niet per definitie slecht.

Jeffrey87 schreef:

tmoesel schreef:

Dat is maar wat je als NAT beschouwt. In een thuisrouter wordt een overgang tussen een publiek en privaat netwerk NAT genoemd.
In b.v. jouw traceroute is ook een overgang tussen een privaat en publiek netwerk te zien. Met 10.10.10.57 gedefinieerd als privaat en 80.79.204.11 (en ook 37.143.83.1) als publiek. Dat noem ik ongunstige routing, puur vanwege het gebruik van private adressen buiten en thuisLAN van een klant.

Dit is een transparante firewall routering, en wordt door veel enterprise-level networking devices aangeboden om niet onnodig veel public IP space te gebruiken voor interne network hops.

Bij deze techniek is er geen sprake van port forwarding of whatsoever, maar wordt alles gewoon 1 op 1 doorgezet.

In meerdere netwerken die ik beheer (zakelijk) wordt deze methode ook toegepast.

Ik begrijp je onderbouwing, echter is een 10.0.0.0/8, 192.168.0.0/16 of 172.16.0.0/12 adres niet per definitie slecht.

De verzameling aan T-Mobile klanten is niet hetzelfde als b.v. 100.000 werknemers van een multinational met diverse sites wereldwijd. Daar werkt dat gebruik van 10.0.0.0/8 prima kan ik uit eigen ervaring zeggen. Een multinational heeft doorgaans een strict beleid m.b.t. bedrijfsinfo enz, dus is het daar helemaal geen probleem om private adressen te gebruiken omdat de omgeving dus al privaat is. Afhankelijk van soort bedrijf is goede peering met internet minder nodig of zelfs bewust totaal geblokkeerd. De verzameling aan T-Mobile klanten kan een enorme diversiteit aan software en hardware hebben
T-Mobile kiest of is gedwongen tot legacy schijnbaar. De andere gevallen op dit forum m.b.t. portforwarding hoeven niet alleen een portmapping probleem te zijn maar kunnen dus primair een adresmapping (ofwel NAT of routing) probleem zijn. 10.0.0.0/8 is simpelweg niet uniek, het vereist een extra administratie naast IANA en schijnbaar is die niet op orde of loopt het toch tegen onvoorziene beperkingen aan.

I.p.v. dit 'IPv4 spaarprogramma', zou men ook standaard DS-Lite kunnen gebruiken en voor klanten die het nodig hebben of willen, gewoon als extra gratis volledig DualStack aanzetten.

Hoi Jeffrey87,

Als ik handmatig de APN configureer naar smartsites.t-mobile dan werkt het inderdaad. Maar het verbaast me omdat ik overal bij kon het afgelopen jaar zonder problemen, en nu ik t-mobile thuis heb mijn settings op mijn mobiel moet aanpassen.

Maar het is gelukt, en daar ben ik al blij mee.

Bedankt voor het meedenken.

Met vriendelijke groet,
Lucien Bosman

Hoi @Solusjen-Laurens,

OnePlus geeft de verkeerde APN mee op hun toestellen.
De standaard 'juiste' APN voor T-Mobile is smartsites.t-mobile

Dit was een bevinding die ik ook heb op mijn eigen OnePlus 6T, en dit heb ik enige tijd terug ook zelf gemeld bij OnePlus.

De andere APN 'internet' is speciaal bedoeld voor onder andere 4G USB sticks en MiFi routers.

Waarom je met deze APN geen toegang kunt krijgen tot je server bij T-Mobile Thuis is voor mij een raadsel, aangezien de 2 netwerken (mobiel en vast) bij mijn weten gescheiden zijn.

Ik ben in ieder geval blij dat het nu voor jou werkt!

Groet,

Jeffrey

Solusjen-Laurens schreef:

Wie heeft er soortgelijke problemen, of wie kan mij helpen door te testen naar een ander t-mobile thuis netwerk. Heb jij poort 80 open staan laat even weten op welke hostnaam / ip adres je te benaderen bent. Ik heb al een ticket lopen bij t-mobile maar de oplossing is nog niet nabij.

Je zou onderstaande threads eens kunnen doorbladeren voor je aan het proberen slaat, alhoewel je nu wel weet wat de oplossing/workaround is.
Een transparante verbinding tussen 2 TMO clients die beide een publiek WAN IPv4 adres hebben, al dan niet gemapt achter een privaat 10.0.0.0/8, lijkt glad ijs. Verder lijkt de router van T-Mobile voor sommigen die servers draaien een block aan het been, omdat wat er aan functionaliteit in zit en actief is, ongedocumenteerd is.

https://community.t-mobile.nl/t-mobile-thuis-internet-492/blokkade-tussen-t-mobile-thuis-ip-adressen-307075
https://community.t-mobile.nl/t-mobile-thuis-internet-492/sinds-t-mobile-onderhoud-hyperback-up-naar-andere-t-mobile-klant-niet-meer-mogelijk-304951