T-Mobile blokkeert toegang tot kleinschalige servers

[jubeth]

Paar weken geleden (20 maart 2017) merkte mijn vriendin op dat ze met haar iPhone (via T-Mobile) plotseling niet meer bij haar mail kon, haar mail op mijn (zelf beheerde) server. Ik natuurlijk kijken wat de fout-melding op haar iPhone precies was. Kon geen contact maken met mail.x, veel meer zegt zo'n iphone niet.
Omdat ik zelf niets had veranderd aan mail.x, en er zelfs geen auto-updates hadden plaatsgevonden op die dag, ben ik de zaak wat dieper gaan onderzoeken, vooral omdat de storing aanhield, dagen later nog steeds. Meteen viel op dat ze wèl mijn mail-server kon bereiken als ze die iphone naar thuis-WiFi omschakelde. Toen ook getest op eigen mobiel, blijkt goed te gaan via KPN/Hi mobiel, via vodafone mobiel, en geen van de mail-users had mij problemen gemeld over toegang tot mijn mail-server (en er zitten een paar hele strenge IT-ers tussen die users).

Hoewel die mail-server zo ongeveer de meest veilige en goed geconfigureerde debian-bak is die er bestaat (ik doe al privé-mail sinds 2000 met dezelfde domeinnaam), ben ik beslist niet iemand die meteen de schuld bij een ander zal zoeken, zeker niet waar het om mail-servers gaat, dus ik ben eerst maar eens gaan uitsluiten of het aan mijn kant lag;

Eens checken wat er te zien was aan de kant van mijn mail-server als haar iPhone het probeerde via tmobile. Opvallend is dat er niet eens pogingen tot communicatie vanuit het T-Mobile netwerk te zien zijn op deze mail-server. Eerste waar ik toen aan dacht was firewalling op mijn server, maar ook dat bleek niet het geval. No matches found for 84.241.192.* in iptables. Beetje gaan greppen in logs op 84.241.192 en de laatste hit inderdaad op 20 maart:

/var/log/dovecot.log:2017-03-20 13:37:02 imap-login: Info: Login: user=<sanne>, method=PLAIN, rip=84.241.192.100, lip=91.228.53.46, mpid=15512, TLS, session=<VgjIyChLfwBU8cBk>

Daarna niets meer.

Via wat omwegen toegang kunnen krijgen met haar t-mobile SIM om eens te kijken wat er precies gebeurt met het verkeer naar mijn server. Met wat tcpdump commands kwam ik erachter dat T-Mobile de toegang tot diverse IP-ranges (en servers die wat minder groot of bekend zijn) verstoort door spoofed RST TCP packets toe te voegen aan het (TLS) verkeer. Ze komen er botweg gewoon niet doorheen bij t-mobile!

T-Mobile reageert ofwel niet, ofwel met standaard replies, en weigert mij natuurlijk in contact te brengen met een techneut of NOC, laat staan met iemand die wat meer invloed heeft bij T-Mobile.

[ Voor 8% gewijzigd door jubeth op 25-03-2019 11:22 ]

[dicksterk]

*knip*. Hier is het forum niet voor bedoeld.

[ Voor 83% gewijzigd door rens-br op 13-04-2017 12:31 ]

[GrooV]

Rare conclusies die je trekt, ik heb meerdere prive servers die ik gewoon kan benaderen via T-Mobile.

Ik zie dat je mailserver in Duitsland staat, misschien hebben ze de range geblokkeerd omdat er veel "verkeerd" verkeer naar toe gaat.

Verder zou ik gewoon normaal contact opnemen met T-Mobile, hun NOC is echt niet onbereikbaar (heb er zelf meerdere keren contact mee gehad).

edit:
Ik zie dat je gebruik maakt van een goedkope VPS provider, heb je daar het probleem al gezocht?

[ Voor 12% gewijzigd door GrooV op 13-04-2017 12:39 ]

[Pilovali]

Op het forum zijn ook al een handjevol klachten dat mensen niet op sommige websites kunnen komen. Volgens de hoge heren heeft het te maken met DNSSEC.

[GrooV]

Inderdaad, een DNS probleem https://forum.t-mobile.nl...baar-via-4g-thuis-277843/

Je IP is ook gewoon benaderbaar maar met HTTPS gaat het mis

[jubeth]

*knip*. Houden we het wel een beetje vriendelijk?
1) Het gaat hier niet om een "goedkope VPS provider", de mensen die de zaak daar hosten zijn zelf actief in de open source en linux dev wereld, en als ergens schone IP/24 zitten, dan zijn het die van Janssen/Hoffrath bij first-root. Ik heb er *nog nooit* RBL- of andere problemen mee ondervonden.

2) Met TLS/SSL is er niets mis op genoemd IPv4 adres, en al zeker niet op de door deze server gebruikte domeinnamen.

3) DNSSEC ? Jullie bedoelen die security by obscurity middels een zwakke implementatie van 1990s crypto https://news.ycombinator.com/item?id=7116638 ? En wat de hell heeft DNSSEC met het bereikbaar stellen (en vooral het onbereikbaar *maken*) van hele IP-blocks te maken?

4) Deze mail-server voldoet aan *alle* RFC's die er maar voor te bedenken zijn. DNS loopt via CloudFlare, is niets mis mee. DKIM daar is perfect, IPv6 is in orde, zelfs rDNS is perfect. Er is nog nooit spam vandaan verzonden, laat staan dat er een 'veiligheidsrisico' zou bestaan.

5) Die 'hoge heren' weten schijnbaar niet wat ze doen, als hun DNSSEC implementatie plotseling voor drommen T-mobile klanten de toegang tot hele IP-blocks onmogelijk maakt. Feit dat T-mobile refereert naar deze reacties als "de oplossing van het probleem" is te triest voor woorden.

Dit blijft gewoon een geniepige vorm van anti netneutraliteit.
Zag dat ze eerder ook al mot hadden op dit gebied; https://www.bof.nl/2016/1...in-tegen-netneutraliteit/ Waar rook is is vuur, T-Mobile. Ik blijf staan bij mijn advies: Als je een keuze hebt, ga niet voor T-Mobile.

[ Voor 4% gewijzigd door rens-br op 14-04-2017 15:29 ]

[roeleboel]

jubeth schreef op vrijdag 14 april 2017 @ 11:34:
*knip*


1) Het gaat hier niet om een "goedkope VPS provider", de mensen die de zaak daar hosten zijn zelf actief in de open source en linux dev wereld, en als ergens schone IP/24 zitten, dan zijn het die van Janssen/Hoffrath bij first-root. Ik heb er *nog nooit* RBL-problemen mee ondervonden.

First-root geeft een vps vanaf 3.99€ per maand, wat noem jij dan wel 'een goedkope vps provider'?

[ Voor 5% gewijzigd door rens-br op 15-04-2017 14:50 ]

[jubeth]

*knip*. Op de man. want het is wat mij betreft ondenkbaar dat een internet connectivity provider *voor mij* zou mogen bepalen welke IP-blocks ik wel of niet kan of mag bereiken. Dat jullie hier al niet eens van staan te kijken is het werkelijke probleem:
Jullie willen schijnbaar dat jullie ISP jullie handjes voor je vasthoudt en niet alleen deep packet inspection voor jullie doet, maar ook voor jullie besluit welke sites je wel of niet kunt bereiken. Dit zijn gewoon Chinese praktijken, kwam toevallig ook een mede-slachtoffer tegen; https://www.grepular.com/...Great_Firewall_of_TMobile CENSUUR heet dat;
De geldige argumenten voor het blokkeren van toegang voor tmobile klandizie missen volkomen. Laat staan dat er 1 t-mobile klant ooit over ondervraagd zal zijn. Ik weet er inmiddels al 4 die hier flink van balen, waaronder mijn vriendin (die hoogstwaarschijnlijk haar contract bij Tmobile niet zal verlengen).

Nog afgezien van de prijsvoering die first-root *nu* hanteert; ik heb daar een RAID 10 SSD machine met een uptime waar men in NL nog wat van kan leren. En waarom gaat het ineens over 1 kleine provider die ik toevallig als voorbeeld noem? Het probleem ligt niet bij kleine providers. Ik heb voldoende eigen servers in nederlandse datacenters staan, ook die ondervinden dit probleem voor T-mobile klanten.

[ Voor 3% gewijzigd door rens-br op 14-04-2017 15:37 ]

[rens-br]

Modbreak:

Goed. Ik heb een aantal reacties aangepast en verwijderd.

Het op de man spelen en ranten is niet toegestaan op Tweakers en laat dat dan ook achterwege.

@jubeth Iedereen probeert je hier alleen maar te helpen, vervolgens met modder gaan gooien helpt echt niet. Vervolgens ranten tegenover de provider maakt je case ook niet bepaald duidelijk[

Het topic gaat nu in ieder geval weer open, mocht het weer uit de hand lopen komt er weer een slotje op

[ Voor 89% gewijzigd door rens-br op 14-04-2017 15:40 ]

[jubeth]

Ik dank The Force dat ik zelf een KPN abonnement heb. Daar zou zo'n krankzinnig besluit echt nooit langs de mensen in het NOC komen.

[theblindman]

@jubeth Hoe valt dit probleem te reproduceren?

[Question Mark]

jubeth schreef op woensdag 12 april 2017 @ 11:45:
Met wat tcpdump commands kwam ik erachter dat T-Mobile de toegang tot diverse IP-ranges (en servers die wat minder groot of bekend zijn) verstoort door spoofed RST TCP packets toe te voegen aan het (TLS) verkeer.

Hoe kom je tot de conclusie dat het spoofed RST packets zijn? Da's namelijk wel een aardig dappere uitspraak...

[alex3305]

Pilovali schreef op donderdag 13 april 2017 @ 13:38:
Op het forum zijn ook al een handjevol klachten dat mensen niet op sommige websites kunnen komen. Volgens de hoge heren heeft het te maken met DNSSEC.

GrooV schreef op donderdag 13 april 2017 @ 13:48:
Inderdaad, een DNS probleem https://forum.t-mobile.nl...baar-via-4g-thuis-277843/

Je IP is ook gewoon benaderbaar maar met HTTPS gaat het mis

Ook hier kan ik bevestigen dat het om DNSSEC gaat. Een tijdje terug eenzelfde soort vaag probleem meegemaakt. Op mijn .io domein was mijn server niet te bereiken, maar met mijn .nl domein ging het prima.

Uiteindelijk bleek dat Google DNS het .io domein blokkeerde wanneer er een HTTPS verbinding op zit zonder DNSSEC. Lijkt mij überhaupt een hele goede maatregel, maar erg lastig te debuggen. Mocht je zelf weinig kennis van DNSSEC hebben dan zou je eventueel met CloudFlare DNSSEC kunnen instellen op je records.

[Pilovali]

Probeer eens je telefoon op 3G-only te zetten, sommige klanten op het T-Mobile forum zeggen dat het dan werkt. Vind ik wel apart.

[TereZz]

Dit lijkt me een kort-geding wel waard.
Als je niet oppast worden deze praktijken normaal voor providers.
Het is volgens mij begonnen met poort 25 die geblokkeerd werd, om spam tegen te gaan. Is dit de lijn?

[jant]

jubeth schreef op vrijdag 14 april 2017 @ 15:45:
Ik dank The Force dat ik zelf een KPN abonnement heb. Daar zou zo'n krankzinnig besluit echt nooit langs de mensen in het NOC komen.

KPN NOC gaat niet over dergelijke beslissingen. Maar goed om constructief te zijn. Geef eens antwoord op (eerder gestelde) vragen.

1) Hoe reproduceer je dit probleem?
2) Hoe kwam je tot de conclusie van (TLS) spoofed packets?
2) Definieer 'diverse ip-ranges'.
3) Definieer 'minder bekende servers'.

Je doet nogal heldere uitspraken over de betreffende provider op basis van 1 niet functionerend email account. Dat is een tikkeltje summier.

[ Voor 13% gewijzigd door jant op 15-04-2017 02:52 ]

[jubeth]

https://forum.t-mobile.nl...3/index2.html#post1378569

[jubeth]

Question Mark schreef op vrijdag 14 april 2017 @ 20:21:
[...]
Hoe kom je tot de conclusie dat het spoofed RST packets zijn? Da's namelijk wel een aardig dappere uitspraak...

Gekeken wat er gebeurde. Let op de foute TTL (boven 150..). Overigens is dat 'effect' nu verdwenen, dus ze zijn er wel degelijk aan bezig (geweest), sinds mijn eerste bericht hier.

# tcpdump -nvvvi eth3 'src host 91.228.53.46 and tcp[13] & 4 != 0'
tcpdump: listening on eth3, link-type EN10MB (Ethernet), capture size 262144 bytes
20:51:27.496058 IP (tos 0x0, ttl  45, id 12122, offset 0, flags [DF], proto: TCP (6), length: 40) 91.228.53.46.57208 > 84.241.192.189.http: R, cksum 0xa111 (correct), 315395613:315395613(0) ack 1281815693 win 4355
20:51:27.498496 IP (tos 0x0, ttl  46, id 12400, offset 0, flags [DF], proto: TCP (6), length: 40) 91.228.53.46.57208 > 84.241.192.189.http: R, cksum 0xa114 (correct), 0:0(0) ack 1 win 4352
20:51:27.498505 IP (tos 0x0, ttl  48, id 11778, offset 0, flags [DF], proto: TCP (6), length: 40) 91.228.53.46.57208 > 84.241.192.189.http: R, cksum 0xa084 (correct), 142:142(0) ack 1 win 4354
20:51:27.811792 IP (tos 0x0, ttl  48, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 91.228.53.46.57208 > 84.241.192.189.http: R, cksum 0xf318 (correct), 315395613:315395613(0) win 0
20:51:28.025505 IP (tos 0x0, ttl 154, id 8442, offset 0, flags [DF], proto: TCP (6), length: 40) 91.228.53.46.57217 > 84.241.192.189.http: R, cksum 0xe799 (correct), 315842116:315842116(0) ack 1698940036 win 4464
20:51:28.027111 IP (tos 0x0, ttl 155, id 8479, offset 0, flags [DF], proto: TCP (6), length: 40) 91.228.53.46.57217 > 84.241.192.189.http: R, cksum 0xe79c (correct), 0:0(0) ack 1 win 4461
20:51:28.027259 IP (tos 0x0, ttl 157, id 11607, offset 0, flags [DF], proto: TCP (6), length: 40) 91.228.53.46.57217 > 84.241.192.189.http: R, cksum 0xe70c (correct), 142:142(0) ack 1 win 4463
20:51:28.333804 IP (tos 0x0, ttl 196, id 10446, offset 0, flags [DF], proto: TCP (6), length: 40) 91.228.53.46.57220 > 84.241.192.189.http: R, cksum 0x9694 (correct), 315390708:315390708(0) ack 2786441185 win 4506
20:51:28.336437 IP (tos 0x0, ttl 197, id 8341, offset 0, flags [DF], proto: TCP (6), length: 40) 91.228.53.46.57220 > 84.241.192.189.http: R, cksum 0x9697 (correct), 0:0(0) ack 1 win 4503
20:51:28.337711 IP (tos 0x0, ttl  48, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 91.228.53.46.57217 > 84.241.192.189.http: R, cksum 0x22e2 (correct), 315842116:315842116(0) win 0
20:51:28.636092 IP (tos 0x0, ttl 48, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 91.228.53.46.57220 > 84.241.192.189.http: R, cksum 0x0636 (correct), 315390708:315390708(0) win 0

[ Voor 4% gewijzigd door jubeth op 18-04-2017 01:23 ]

[Question Mark]

jubeth schreef op maandag 17 april 2017 @ 01:45:
[...]

Gekeken wat er gebeurde.

Intressante dump, thx.

[jubeth]

Nog even ter completie;

Deze draad begon wat verkeerd, waarvoor excuses. Hetgeen ik schreef klopte allemaal wel, maar ik was die dagen echt veel te moe om me voldoende te beheersen. Mede aangezwengeld door de onwelwillendheid van hulpeloze tmobile helpdeskers en twitter-care die eraan vooraf ging. Vaak vergeet ik dat het helemaal niet gewoon is om goed thuis te zijn in de besproken materie, en kan ik onbegrip bij de veroorzakende partij niet goed verdragen, dus het is er wat onprofessioneel uitgekomen, en in verkeerde toon gesteld. Ik was vooral bang dat het voorgoed zo zou blijven, en dat ik voortaan moest dealen met geklaag hierover van diverse users (familie, kennissen, vrienden en vriendin) van mijn privé hosting services.
Gelukkig was daar ineens FooLsKi to the rescue, die wat invloed kon uitoefenen bij het reilen en zeilen binnen T-mobile, en is dit probleem vanmiddag de wereld uit geholpen. Het was allemaal geen opzet, niet de bedoeling. Las dat zelfs solcon.nl bij de onbereikbare adressen zat.
Denk wel dat iemand bij tmobile zichzelf een flinke facepalm heeft verkocht vanmiddag.