connection impossible serveur mail en ssl chez un client voo

[jfsenechal]

Bonjour

Je rencontre un soucis chez mon patron à son domicile client chez voo
il ne sait pas consulter ses mails professionnels via un client tel que thunderbird

la connexion se fait en imap ssl port 993

Ca fonctionne partout dans le monde, sauf chez lui

Alors évidemment les tests de base ont été fait, essais avec d'autres ordis, d'autre client mail, d'autres comptes sur ce même serveur etc...

D'après mes analyses il semble que se soit au niveau du cryptage que ça pose soucis
Le client contact bien le serveur mail, mais il semble qu'au retour il y a un soucis

Voici quelques infos, client voo chez qui tout fonctionne et chez la personne pour qui ça pose soucis

Un tracert



Un ssldump depuis le serveur mail



Wireshark chez le client ok


Wireshark chez le client ko


Wireshark en detail


LA capture complete wireshark

http://afmlibre.be/voo/cap2.pcapng

Quelqu'un sait il m'aider ?

Merci

[NuxPowa]

Le problème est-il chez le client voo ou sur le serveur mail qui apparemment est sous belgacom?
Quel genre de serveur mail?. Sous Sendmail? Autre?

Edit: le lien si dessus n'est que du "crypté", rien de visible.

Edit2: 194.78.31.178 = gw3.marche.be.

Je relirai l'ensemble plus tard, mais il me semble que le problème ne vienne pas du client, mais bien du serveur de marche.

Edit3: il se peut aussi que le problème se passe sous Thunderbird (ce m'est déjà arrivé auparavant).
Un peu de lecture

Ainsi que ici

Ce qui m'intrigue, c'est le rst ack.

RST is sent by the side doing the active close because it is the side which sends the last ACK. So if it receives FIN from the side doing the passive close in a wrong state, it sends a RST packet which indicates other side that an error has occured.

Autre question: les ports sont-ils en 443 ou 993?

Suggestion également: sous linux, il y a également ssldump

[jfsenechal]

Bonjour

Merci pour l'intervention, mais je pense que vous n'avez pas bien lu mon message
J'ai mis un ssldump
On a testé avec de multiples pc qui fonctionnent partout sauf sur cette ligne

Merci quand même

[tandem11c]

Avez-vous fait un test des ports sur la ligne VOO ?

[NuxPowa]

Avez-vous fait un test des ports sur la ligne VOO ?

+1

Surtout s'il s'agit d'un abo particulier avec modem/routeur NetGear. Le routeur intégré en lui-même est mal conçu.
Rien de tel que de mettre le modem en bridge avec un routeur valable derrière.

[jfsenechal]

Via un telnet ?

[jfsenechal]

Autre info, tester sur autre client de thunder
et par exemple, test via iphone mis sur le wifi ca va pas
et iphone mis sur le 3g la ça passe...

donc c'est clairement un soucis sur la ligne, mais aller faire comprendre ça à voo...

[NuxPowa]

Le test des ports? graphicalement, un très bon site (je parle point de vue fiabilité) est grc rubrique "Shields Up"

[NuxPowa]

Autre info, tester sur autre client de thunder
et par exemple, test via iphone mis sur le wifi ca va pas
et iphone mis sur le 3g la ça passe...

donc c'est clairement un soucis sur la ligne, mais aller faire comprendre ça à voo...

Petit détail: chez "voo", ce qui peut arriver, c'est le CGN (Carrier Grade NAT) également.

Première chose à voir: l'ip WAN du client "voo".
Dans le cas d'un abo particulier, direction telephone chez voo et demander de ne pas avoir de CGN (Si si, il leur suffit de leur demander)!

Edit: donc d'une pierre deux coups: chez grc: test des ports ouverts/cachés/fermé" ainsi que l'affichage de l'ip WAN

[jfsenechal]

oui j'ai déjà entendu parler de cgn

dans ma capture du ssldump on voit l'ip du client posant soucis (à droite)
et à gauche l'ip fonctionnant (chez moi)

on sait dire si c'est du cgn ?

[NuxPowa]

Je crains avoir "loupé un épisode" là.
Chez vous, l'ip/domaine est mail.marche.be (194.78.31.178) et chez le client: host-85-201-106-132.dynamic.voo.be, juste?

Si c'est bien ça, son ip externe n'est pas en CGN, le CGN étant en ip de classe A ou classe C (Carrier Grade NAT est en fait un double NAT, que les FAI mettent car manque d'IPv4 actuellement).
Maintenant, comme c'est indiqué, le client a un abo particulier (dynamic), donc il est surement derrière un routeur.
Deux possibilités: soit son routeur, soit le routeur du NetGear (CG3100 ou 3700).
Car le NetGear est à la fois (par default) modem/routeur. Et le routeur est merdique (excusez moi du terme) et ferme par défault pas mal de ports entrants.
Rien de tel que de mettre le NetGear en bridge et d'installer un vrai routeur derrière.

Maintenant, si je me suis trompé, rien de tel que de faire un ptit GRC chez le client pour voir les ports ouverts ainsi que son ip WAN.

[NuxPowa]

Edit: (je suis lent, pour ceux qui ne le savent pas)...
"jf": lorsque je vois lors de votre premier post (tout au dessus), dans les tracert, je vois: 192.168.0.1 (la classe C du pc j'imagine).
Ensuite, en deuxième position: le 10.206.224.1 : qu'est-ce? C'est du private network (classe A)
Ensuite je vois : 78.129.127 - Belgium - Brutele SC (Autrement dit: le "voo")....

La question principale étant: le 10.206.224.1 est de? Un routeur? Autre?

Je me répète (comme un vieux schnok): c'est du classe A! Si cette ip ne vient de chez un routeur, il vient de chez "voo"!
Donc: pour faire court: celà vient du CGN

La seule solution étant: téléphoner chez "voo", prendre un thermo de café, deux dafalgans pour demander aux transferts de la dizaine de types différents au tel que vous ne voulez pas du CGN mais une ip publique (si si, ça ce fait).

[jfsenechal]

J'ai fait une comparaison avec mon voo qui fonctionne bien avec marche.be, à ce moment là mon ip était en 109.88... (voir ssldump)
et le voo chez qui ça ne va pas, qui lui était en 85-201-106-132...

avec le tracert chez moi, en effet à la deuxième ligne on voit un 10.206...
et chez le client en panne, on ne voit des étoiles

Voo doit me retel, je leur parlerai du cgn

j'ai pas accès pour le moment à la machine client on verra pour le grc

merci

[NuxPowa]

85.201.106.132 est une ip publique du Range de chez Brutele, donc ce n'est pas un problème de CGN.
Pour l'anecdote, "voo", "brutele" etc font partie de Tecteo en fait, tout simplement.

[roylion15]

@JF et Nuxpowa
Effectivement c'est tout à fait normal depuis le réseau local d'avoir une adresse en 10.x en seconde ligne du traceroute après celle du routeur voo ou perso .... j'ai aussi cette ligne à chaque fois que je fais le traceroute sous Windows par exemple et sur n'importe quel site ....

exemple de traceroute mais ici depuis mon routeur asus, l'adresse en 10.x apparaît directement en première position alors ...

Code : Tout sélectionner

traceroute to 194.78.31.178 (194.78.31.178), 30 hops max, 38 byte packets
 1  10.xx.xxx.1 (10.xx.xxx.1)  6.975 ms  11.072 ms  7.952 ms
 2  78.129.127.117 (78.129.127.117)  8.311 ms  9.553 ms  10.034 ms
 3  212.68.211.25 (212.68.211.25)  12.349 ms  9.904 ms  9.111 ms
 4  skynet.bnix.net (194.53.172.63)  12.686 ms  13.695 ms  9.575 ms
 5  ae-27-1000.iprstr1.isp.belgacom.be (91.183.246.91)  9.384 ms  9.024 ms  10.016 ms
 6  85.246-183-91.adsl-static.isp.belgacom.be (91.183.246.85)  10.786 ms  9.449 ms  11.200 ms
 etc ...


[jfsenechal]

Ok roylion

mais est-ce normal d'avoir "délais de la demande dépassé" pour le client posant problème ??

[NuxPowa]

Bien sur que non.
Mais sans regarder au dBmV du modem, au routeur utilisé ec, c'est quelque peu compliqué de vous répondre.
Brièvement: De combien sont les dBmV?
Quel modem? Est-ce uniquement modem (donc en bridge) ou modem/routeur? Il y a t'il un autre routeur derrière/proxy autre derrière?
Si celà se trouve, il y a encore un pare feu derrière...
Autant de questions sans réponses qui ne peuvent vous faire avancer, jf

J'ai eu la blague une fois chez un client dont leur connexion "voo" n'avancait pas du tout. Le modem "Bridgé", et supprimer les 36 pare feu derrière fut la solution.

Ne fut ce que: un GRC et p-ê un "speedtest" avancerait déjà votre problème

Voici ce que donne traceroute ici:

traceroute mail.marche.be
traceroute to mail.marche.be (194.78.31.178), 30 hops max, 60 byte packets
1 copyleftgnu (192.168.0.254) 0.362 ms 0.342 ms 0.355 ms
2 * * *
3 78.129.127.241 (78.129.127.241) 9.563 ms 9.561 ms 9.541 ms
4 212.68.211.50 (212.68.211.50) 10.165 ms 10.147 ms 10.097 ms
5 212.68.211.54 (212.68.211.54) 11.695 ms 11.987 ms 11.972 ms
6 212.68.211.185 (212.68.211.185) 13.520 ms 12.335 ms 12.706 ms
7 skynet.bnix.net (194.53.172.63) 12.788 ms 13.876 ms 14.985 ms
8 ae-27-1000.iprstr1.isp.belgacom.be (91.183.246.91) 39.562 ms 38.989 ms 38.984 ms
9 * * *
10 * dialup30.brussel.belbone.be (195.13.4.30) 14.346 ms 14.325 ms
11 dialup4.brussel.belbone.be (195.13.4.4) 13.925 ms 13.791 ms 11.996 ms
12 62.48-181-213.adsl-fix.isp.belgacom.be (213.181.48.62) 14.841 ms 11.715 ms 11.675 ms

traceroute gw3.marche.be
traceroute to gw3.marche.be (194.78.31.178), 30 hops max, 60 byte packets
1 copyleftgnu (192.168.0.254) 0.288 ms 0.269 ms 0.291 ms
2 * * *
3 78.129.127.241 (78.129.127.241) 8.689 ms 8.679 ms 8.659 ms
4 212.68.211.50 (212.68.211.50) 9.177 ms 9.156 ms 9.113 ms
5 212.68.211.54 (212.68.211.54) 10.613 ms 10.604 ms 10.572 ms
6 212.68.211.185 (212.68.211.185) 12.584 ms 11.492 ms 11.614 ms
7 skynet.bnix.net (194.53.172.63) 12.433 ms 12.089 ms 12.317 ms
8 ae-27-1000.iprstr1.isp.belgacom.be (91.183.246.91) 12.454 ms 11.963 ms 12.270 ms
9 * * *
10 dialup30.brussel.belbone.be (195.13.4.30) 14.333 ms 12.684 ms 13.054 ms
11 dialup4.brussel.belbone.be (195.13.4.4) 12.919 ms 15.457 ms 12.493 ms
12 62.48-181-213.adsl-fix.isp.belgacom.be (213.181.48.62) 12.266 ms 12.195 ms 12.692 ms

traceroute 194.78.31.178
traceroute to 194.78.31.178 (194.78.31.178), 30 hops max, 60 byte packets
1 copyleftgnu (192.168.0.254) 0.342 ms 0.355 ms 0.400 ms
2 * * *
3 78.129.127.241 (78.129.127.241) 10.768 ms 10.737 ms 10.751 ms
4 212.68.211.50 (212.68.211.50) 11.303 ms 11.301 ms 11.294 ms
5 212.68.211.54 (212.68.211.54) 12.895 ms 12.928 ms 12.883 ms
6 212.68.211.185 (212.68.211.185) 17.225 ms 15.713 ms 15.682 ms
7 skynet.bnix.net (194.53.172.63) 13.936 ms 11.773 ms 13.537 ms
8 ae-27-1000.iprstr1.isp.belgacom.be (91.183.246.91) 12.432 ms 12.460 ms 12.101 ms
9 85.246-183-91.adsl-static.isp.belgacom.be (91.183.246.85) 14.943 ms 14.063 ms 14.026 ms
10 * * *
11 dialup4.brussel.belbone.be (195.13.4.4) 14.237 ms 14.851 ms 12.247 ms
12 62.48-181-213.adsl-fix.isp.belgacom.be (213.181.48.62) 12.250 ms 12.090 ms 16.355 ms
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

[roylion15]

Hello,
Je vais répondre que non également et bien qu'effectivement on pourrait soupçonner une mauvaise configuration chez le client, le souci pour moi se trouverait au niveau de l'infrastructure de voo et pas forcément chez le client; En tout cas quelque part plus en amont que la partie modem du client ou à moins que le modem ne soit carrément défectueux et il ne communique pas correctement avec le CMTS quelque chose de ce genre.
Aussi oui, comme le dit Nuxpowa,il faut voir la qualité de la ligne et s'il n'y a pas des problèmes à ce niveau là car aucune info n'est postée par JF sur cette partie là, très importante pour la liaison du client au cmts, ni sur le type de modem(routeur) qui foire.

edit : @Nuxpowa , je vois que toi aussi tu as des *** en seconde ligne, c'est pas fort normal non plus ou bien c'est lié à une config de serveur voo qui n'aime pas trop les tracerts...