Raar fenomeen closed ports of toch niet

[on4bam]

Hi,

Ik ben zopas terug van vakantie en had mijn medion netbook bij voor contact met de buitenwereld/thuisfront en lokaal opzoekwerk. De verbindingen waren zowel LAN als wireless en werkten naar behoren (meestal upoad van +3Mbit )

Op onze laatste locatie kon ik perfect het net op maar IMAP via SSL werkte niet. Dan maar de encryptie afgezet en dat werkte wel. Encrypted nntp verkeer werkte ook niet unencrypted wel.
Het probleem begon met het verzenden van mail. SMTP met encryptie werkte niet maar ook zonder ging het niet. Een telnet sessie op poort 25 gaf een 220 welcome en daar hield het mee op. Met het tooltje Look@LAN zag ik dat poort 25 open stond en toch kreeg ik de SMTP verbinding niet in orde. Tracert gaf de hele route met waarden van 200-500ms
De mailserver is van mijn eigen domein, gehost in Atlanta.

Een man aan de receptie van het hotel (ex sysadmin) wist te zeggen dat hij hetzelfde had gehoor van een hotelgast die een mailserver in Indonesie niet kon contacteren maar was zich niet bewust van andere probs.

Ik heb mijn plan getrokken en mijn gmail (web) gebruikt voor outgoing mail maar vraag mij wel af wat er kan misgelopen zijn. Iemand een idee?

[ubremoved_539]

Een telnet sessie op poort 25 gaf een 220 welcome en daar hield het mee op.

Da's wel bizar want op dat moment ben je door alle stappen van het protocol door.

Enige verklaring is een transparante proxy die extra filtering doet... maar dan had men evenzeer poort 25 gewoon kunnen sluiten.

[on4bam]

Een telnet sessie op poort 25 gaf een 220 welcome en daar hield het mee op.

Da's wel bizar want op dat moment ben je door alle stappen van het protocol door.

Enige verklaring is een transparante proxy die extra filtering doet... maar dan had men evenzeer poort 25 gewoon kunnen sluiten.

Dat is er net zo vreemd aan. Ter info, mijn zoon zijn Ipod Touch kon ook geen mail versturen (gmail) wel ontvangen. Hij heeft in de hele stad nu en dan geprobeerd om via open netwerken zijn mail weg te krijgen en dat ging ook niet. Als die allemaal bij dezelfde ISP zaten is dat logisch natuurlijk.

BTW, de stad waar het niet werkte was Osaka, alle andere steden en gehuchten no prob

[Genghis]

Is toch niet zo raar, Belgacom en Telenet (en wss nog wat ISP's) doen hetzelfde.
Port 25 staat open, maar enkel naar HUN mailservers (je wordt dus omgeleid naar hun server, vaak zonder je het zelf merkt, kan je wel zien aan hostname via telnet bvb). Als je telnet kom je dus eigenlijk op hun server terecht ipv op de server
waar je naartoe wil. Als je u eigen mailserver draait, kunt ge dit makkelijk omzeilen door die te laten luisteren op bvb 2525.
Zo staat het bij mij ook geconfigureerd op mijn GSM bvb, dan maakt het niet uit op welke ISP ik verbonden ben, mails sturen lukt gewoon via eigen server.
Bijkomend voordeel: je omzeilt zo ook direct de meeluisterpraktijken van Stefaan De Clerck.

Waarom je inkomende IMAP SSL niet werkte, dat is dan weer een ander verhaal... Ook ni direct verklaring voor.

[on4bam]

Is toch niet zo raar, Belgacom en Telenet (en wss nog wat ISP's) doen hetzelfde.
Port 25 staat open, maar enkel naar HUN mailservers (je wordt dus omgeleid naar hun server, vaak zonder je het zelf merkt, kan je wel zien aan hostname via telnet bvb). Als je telnet kom je dus eigenlijk op hun server terecht ipv op de server
waar je naartoe wil.

Nee hoor, ik kreeg perfect antwoord van MIJN mailserver.

220-bullseye.d9hosting.com ESMTP Exim 4.68 #1 Sat, 15 Aug 2009 07:45:32 -0500
220-We do not authorize the use of this system to transport unsolicited,
220 and/or bulk e-mail.

Dit is exact wat ik enkele dagen terug ook kreeg, dus geen lokale ISP.

[splinterbyte]

Op welke provider zat je dan? Hostname/IP gechecked ?

[on4bam]

Op welke provider zat je dan? Hostname/IP gechecked ?

Ik had mijn tracert niet gesaved maar via de stats van mijn site toch dit gevonden:
122x221x140x91.ap122.ftth.ucom.ne.jp als origin vanwaar ik connecteerde.

[splinterbyte]

Japan dus.

Mischien heeft het te maken met de vele hops/slechte peering/routering.

Ik tel er toch 23 en dan gaat het onbekend verder:

Code: Selecteer alles

 1  10.0.0.1 (10.0.0.1)  31.141 ms  30.806 ms  30.425 ms
 2  * * *
 3  94.104.8.54 (94.104.8.54)  28.476 ms  32.005 ms  34.023 ms
 4  94.104.8.54 (94.104.8.54)  35.299 ms  37.768 ms  40.009 ms
 5  zvtm-s1-rou-1042.BE.eurorings.net (134.222.148.232)  41.964 ms  44.367 ms  55.726 ms
 6  nntr-s1-rou-1021.FR.eurorings.net (134.222.231.189)  56.963 ms  30.482 ms  32.562 ms
 7  nyk-s2-rou-1001.US.eurorings.net (134.222.226.165)  115.714 ms  104.971 ms  107.266 ms
 8  nyk-s1-rou-1001.US.eurorings.net (134.222.226.17)  152.634 ms  153.111 ms  153.614 ms
 9  nyk-s1-rou-1021.US.eurorings.net (134.222.231.238)  114.541 ms  115.077 ms  115.577 ms
10  ahbn-s1-rou-1041.US.eurorings.net (134.222.228.10)  123.167 ms  126.797 ms  128.528 ms
11  ahbn-s1-rou-1001.US.eurorings.net (134.222.226.53)  129.008 ms  130.983 ms  133.694 ms
12  dcp-brdr-03.inet.qwest.net (63.146.27.149)  135.362 ms  137.789 ms  140.425 ms
13  * * *
14  63.146.26.70 (63.146.26.70)  187.877 ms  182.527 ms  182.630 ms
15  lacbb001.kddnet.ad.jp (59.128.2.69)  183.469 ms lacbb002.kddnet.ad.jp (59.128.2.73)  174.927 ms lacbb001.kddnet.ad.jp (59.128.2.69)  184.966 ms
16  otejbb203.kddnet.ad.jp (203.181.100.81)  287.199 ms otejbb204.kddnet.ad.jp (203.181.100.105)  289.233 ms  290.413 ms
17  cm-ote232.kddnet.ad.jp (118.155.197.141)  288.188 ms  285.645 ms cm-ote232.kddnet.ad.jp (118.155.197.13)  324.568 ms
18  203.181.98.14 (203.181.98.14)  286.604 ms  288.467 ms  296.642 ms
19  usen-61x122x114x81.gate01.com (61.122.114.81)  289.894 ms  492.991 ms  493.450 ms
20  61.122.118.178 (61.122.118.178)  301.987 ms 61.122.127.18 (61.122.127.18)  310.373 ms  305.201 ms
21  221x112x15x34.ap221.ftth.ucom.ne.jp (221.112.15.34)  302.130 ms  309.733 ms  285.579 ms
22  221x112x15x186.ap221.ftth.ucom.ne.jp (221.112.15.186)  293.389 ms  293.432 ms  288.519 ms
23  221x112x4x230.ap221.ftth.ucom.ne.jp (221.112.4.230)  294.864 ms  289.023 ms  285.851 ms
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Ik heb ook soms voor dat alsje bij een bepaalde ISP surft, je naar sommige servers kunt connecten, maar na aan tijdje (of meteen al) een timeout krijgt of disconnect(connection interrupted).

[ubremoved_539]

Ik tel er toch 23 en dan gaat het onbekend verder:

De 24e is normaal de bestemming... het is gewoon omdat het een dynamic IP-adres is dat nu niet in gebruik is dat je geen reply krijgt. Op zich mag die 24 hops geen enkel probleem vormen, en het feit dat de SMTP server een antwoord geeft geeft duidelijk aan dat er geen probleem is bij het maken van de connectie en zelfs de initiele data uitwisseling.

[on4bam]

Ik tel er toch 23 en dan gaat het onbekend verder:

De 24e is normaal de bestemming... het is gewoon omdat het een dynamic IP-adres is dat nu niet in gebruik is dat je geen reply krijgt. Op zich mag die 24 hops geen enkel probleem vormen, en het feit dat de SMTP server een antwoord geeft geeft duidelijk aan dat er geen probleem is bij het maken van de connectie en zelfs de initiele data uitwisseling.

Ik denk dat het een fixed IP betreft (of zou toch moeten). Het betreft een hotel met een redelijk aantal kamers en een goede connectie (meer dan 3.5 Mbit up). Daarvan verwacht je geen dynIP.

Settings aan mijn kant zijn uit te sluiten omdat hetzelfde resultaat bekomen werd met een netbook, IPod Touch en laptop terwijl alles vanuit de andere hotels en vanop hotspots vlekkeloos werkte. Enkel in Osaka stelde dit probleem zich, ook op de "open netwerken" die we geprobeerd hebben tijdens onze tochten door de stad.

Welke "deftige" ISP zet de SSL poorten van IMAP en POP3 nu dicht en zet de non-encrypted open... strange...

[ubremoved_539]

Ik denk dat het een fixed IP betreft (of zou toch moeten). Het betreft een hotel met een redelijk aantal kamers en een goede connectie (meer dan 3.5 Mbit up). Daarvan verwacht je geen dynIP.

Zou best kunnen... aan de naam te zien is het Fiber-to-the-home (FTTH) trouwens... nu wat ik maar bedoelde is dat je de *** krijgt omdat het adres in kwestie geen ICMP echo replies doet, en dus niet reageerd op een ping/tracert. Het lijkt mij inderdaad nog altijd een raar probleem... eigenlijk had je met een sniffer moeten zijn wat er exact gebeurde, en zelfs dan is het soms nog moeilijk.

[Sub Zero]

Ik kan eigenlijk bijna niks anders bedenken dan dat er een application layer gateway tussen stond die deep packet inspection deed en ergens tijdens de SMTP nest de sessie dropte. Connectiegewijs is alles dik in orde als je de welcome message van de mailserver al ziet.