Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Passerelle, routage, VPN, MTU

31 réponses
Avatar
cyberjujum
Bonjour à tous,

Pour les pros du réseau, une petite question qui me fait tourner en bourrique depuis un bon moment maintenant :

J'ai une passerelle sous Ubuntu server, qui en gros me sert à partager une connexion VPN. Cette passerelle profite de ma connexion perso pour se connecter à un VPN qui ne me donne accès qu'à certains serveurs et a des routes configurées pour dispatcher les paquets là où il faut (mon FAI pour le net "classique", le VPN pour les serveurs à accès restreint). Comme ça mes autres PC clients (PC de bureau, laptop...) ont une connexion prête à l'emploi en passant par cette passerelle.

Le hic, c'est que j'ai quelques soucis :
- Impossible d'envoyer de "gros" mails (long contenu ou pièce jointe), l'envoi se bloque en plein milieu
- Impossible d'afficher certaines pages (genre certaines pages de phpMyAdmin)
- Déconnexions fréquentes en SSH (je parcours un fichier et pouf, la connexion SSH se gèle)

Ce qui selon ce que j'ai pu voir sur le net s'apparente à un problème de MTU.

Ces problèmes apparaissent seulement avec les serveurs accessibles via le VPN (impossible d'envoyer un mail avec pièce jointe via un serveur SMTP accessible via ce VPN, alors qu'avec celui de mon FAI c'est nickel ; le seul phpMyAdmin qui foire est hébergé sur un serveur auquel j'accède via ce VPN, idem pour les décos SSH...).

Voici quelques infos :
--------------------
root@gateway:/usr/local/share/gateway2# ifconfig
eth0 Link encap:Ethernet HWaddr 00:22:15:d3:8e:28
inet addr:192.168.1.254 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::222:15ff:fed3:8e28/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4583 errors:0 dropped:0 overruns:0 frame:0
TX packets:3917 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1462854 (1.4 MB) TX bytes:1479658 (1.4 MB)
Interrupt:220 Base address:0xe000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:840 (840.0 B) TX bytes:840 (840.0 B)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.31.46.251 P-t-P:10.31.46.251 Mask:255.255.248.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1390 Metric:1
RX packets:924 errors:0 dropped:0 overruns:0 frame:0
TX packets:1164 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:719440 (719.4 KB) TX bytes:384407 (384.4 KB)
--------------------

Mon script iptables (j'ai ouvert autant que j'ai pu tellement je désespère :)) :
--------------------
echo 1 > /proc/sys/net/ipv4/ip_forward

# Réinitialisation
iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

# Idem, table NAT
iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
--------------------


J'ai remarqué le MTU 1390 sur l'interface tun0 (justement celle du VPN). J'ai essayé de passer le MTU de mes postes clients à 1390 voire moins, ça ne résoud pas le problème (peut être un peu de mieux, cad que je peux envoyer un long mail ou accéder à des pages qui ne voulaient pas se charger auparavant, mais je finis toujours par avoir des décos en SSH, les mails avec pièce jointe ne passent toujours pas, etc...).

Voyez-vous quelque chose qui cloche ?


Merci beaucoup ! :)

10 réponses

1 2 3 4
Avatar
Mateusz Viste
On Thursday 25 June 2009 00:27, cyberjujum wrote:
Le hic, c'est que j'ai quelques soucis :
- Impossible d'envoyer de "gros" mails (long contenu ou pièce jointe),
l'envoi se bloque en plein milieu
- Impossible d'afficher certaines pages (genre certaines pages de
phpMyAdmin) - Déconnexions fréquentes en SSH (je parcours un fichier et
pouf, la connexion SSH se gèle)

Ce qui selon ce que j'ai pu voir sur le net s'apparente à un problème de
MTU.



Bonjour,

La réencapsulation de données, propre au mécanisme VPN (que ce soit ESP,
GRE, ou autre), provoque une diminution de la MTU utile. Cela entraîne un
phénomène de fragmentation, voir de drop de paquet (si le bit DF desdits
paquets est positionné).

La réduction de la MTU côté client ne fait que déplacer le problème. La
solution consiste à appliquer une limite MSS sur les flux VPN (la valeur
doit être égale à la MTU actuelle, moins la taille de l'entête TCP, moins
la taille de l'entête IP, moins l'overhead de réencapsulation).

Attention: MSS est une option TCP, et ne sera donc appliquée qu'aux
connexions TCP.

Cordialement,
Mateusz Viste
Avatar
cyberjujum
Mateusz Viste a écrit le 25/06/2009 à 07h17 :
On Thursday 25 June 2009 00:27, cyberjujum wrote:
Le hic, c'est que j'ai quelques soucis :
- Impossible d'envoyer de "gros" mails (long contenu ou pièce
jointe),
l'envoi se bloque en plein milieu
- Impossible d'afficher certaines pages (genre certaines pages de
phpMyAdmin) - Déconnexions fréquentes en SSH (je parcours un
fichier et
pouf, la connexion SSH se gèle)

Ce qui selon ce que j'ai pu voir sur le net s'apparente à un
problème de
MTU.




Bonjour,

La réencapsulation de données, propre au mécanisme VPN
(que ce soit ESP,
GRE, ou autre), provoque une diminution de la MTU utile. Cela entraîne un
phénomène de fragmentation, voir de drop de paquet (si le bit DF
desdits
paquets est positionné).

La réduction de la MTU côté client ne fait que
déplacer le problème. La
solution consiste à appliquer une limite MSS sur les flux VPN (la valeur
doit être égale à la MTU actuelle, moins la taille de
l'entête TCP, moins
la taille de l'entête IP, moins l'overhead de réencapsulation).

Attention: MSS est une option TCP, et ne sera donc appliquée qu'aux
connexions TCP.

Cordialement,
Mateusz Viste


Bonjour,

Merci pour cette réponse rapide :)

L'application de la limite MSS se fait donc sur la passerelle ? Avec iptables ? Auriez-vous un exemple svp ?

Merci beaucoup !
Avatar
cyberjujum
Mateusz Viste a écrit le 25/06/2009 à 07h17 :
On Thursday 25 June 2009 00:27, cyberjujum wrote:
Le hic, c'est que j'ai quelques soucis :
- Impossible d'envoyer de "gros" mails (long contenu ou pièce
jointe),
l'envoi se bloque en plein milieu
- Impossible d'afficher certaines pages (genre certaines pages de
phpMyAdmin) - Déconnexions fréquentes en SSH (je parcours un
fichier et
pouf, la connexion SSH se gèle)

Ce qui selon ce que j'ai pu voir sur le net s'apparente à un
problème de
MTU.




Bonjour,

La réencapsulation de données, propre au mécanisme VPN
(que ce soit ESP,
GRE, ou autre), provoque une diminution de la MTU utile. Cela entraîne un
phénomène de fragmentation, voir de drop de paquet (si le bit DF
desdits
paquets est positionné).

La réduction de la MTU côté client ne fait que
déplacer le problème. La
solution consiste à appliquer une limite MSS sur les flux VPN (la valeur
doit être égale à la MTU actuelle, moins la taille de
l'entête TCP, moins
la taille de l'entête IP, moins l'overhead de réencapsulation).

Attention: MSS est une option TCP, et ne sera donc appliquée qu'aux
connexions TCP.

Cordialement,
Mateusz Viste


Re bonjour,

En cherchant un peu sur google je suis tombé là dessus :

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j TCPMSS --clamp-mss-to-pmtu
ou
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j TCPMSS --set-mss <valeur>

La première règle n'a absolument rien changé.

Par contre, la deuxième, avec un MSS très bas (128) a résolu mon problème ! L'envoi du mail est un peu long mais fonctionne. Par contre ça me chiffonne de fixer un MSS si bas... et quand j'augmente ça ne fonctionne plus, à 140 par exemple c'est déjà mort.

La méthode que j'ai suivie est-elle la bonne et y-a-t-il une explication à ce phénomène... plutôt bizarre ? Est-ce gênant d'avoir un MSS aussi bas ?
Avatar
Pascal Hambourg
Salut,

cyberjujum a écrit :

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j
TCPMSS --clamp-mss-to-pmtu
ou
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j
TCPMSS --set-mss <valeur>

La première règle n'a absolument rien changé.



Normal, la MTU d'eth0 est à 1500.

Par contre, la deuxième, avec un MSS très bas (128) a résolu mon problème !
L'envoi du mail est un peu long mais fonctionne. Par contre ça me chiffonne de
fixer un MSS si bas... et quand j'augmente ça ne fonctionne plus, à 140 par
exemple c'est déjà mort.

La méthode que j'ai suivie est-elle la bonne et y-a-t-il une explication à ce
phénomène... plutôt bizarre ? Est-ce gênant d'avoir un MSS aussi bas ?



Oui, c'est gênant car le rendement protocolaire est mauvais : pour un
segment TCP contenant 128 octets de charge utile, le total des en-têtes
IP+TCP est de 40 octets, sans compter l'encapsulation du VPN. Cela pèse
sur le débit utile comme tu l'as constaté. Pour mémoire, IPv6, le
successeur d'IPv4, impose un MTU minimum de 1280 octets afin de limiter
la surcharge protocolaire.

Il y a aussi un léger défaut dans ta règle : elle affecte indifféremment
toutes les connexions TCP passant par eth0, et pas seulement celles qui
passent à travers le VPN.

Mais surtout, je ne vois pas ce qui pourrait imposer une valeur de MTU
aussi basse. Il pourrait être intéressant de faire des tests de ping
pour voir quelle est la taille de paquet maximum qui passe dans chaque
sens, et de faire des captures de trafic à tous les points possibles
pour déterminer à quel endroit les paquets sont perdus : eth0, tun0,
trafic encapsulé, à l'autre bout du VPN. Quel est le type de VPN ?
OpenVPN, VTun, autre ?
Avatar
cyberjujum
Pascal Hambourg a écrit le 25/06/2009 à 13h03 :
Salut,

cyberjujum a écrit :

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j
TCPMSS --clamp-mss-to-pmtu
ou
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j
TCPMSS --set-mss <valeur>

La première règle n'a absolument rien changé.




Normal, la MTU d'eth0 est à 1500.

Par contre, la deuxième, avec un MSS très bas (128) a
résolu mon problème !
L'envoi du mail est un peu long mais fonctionne. Par contre ça me
chiffonne de
fixer un MSS si bas... et quand j'augmente ça ne fonctionne plus,
à 140 par
exemple c'est déjà mort.

La méthode que j'ai suivie est-elle la bonne et y-a-t-il une
explication à ce
phénomène... plutôt bizarre ? Est-ce gênant d'avoir
un MSS aussi bas ?




Oui, c'est gênant car le rendement protocolaire est mauvais : pour un
segment TCP contenant 128 octets de charge utile, le total des en-têtes
IP+TCP est de 40 octets, sans compter l'encapsulation du VPN. Cela pèse
sur le débit utile comme tu l'as constaté. Pour mémoire,
IPv6, le
successeur d'IPv4, impose un MTU minimum de 1280 octets afin de limiter
la surcharge protocolaire.

Il y a aussi un léger défaut dans ta règle : elle affecte
indifféremment
toutes les connexions TCP passant par eth0, et pas seulement celles qui
passent à travers le VPN.

Mais surtout, je ne vois pas ce qui pourrait imposer une valeur de MTU
aussi basse. Il pourrait être intéressant de faire des tests de
ping
pour voir quelle est la taille de paquet maximum qui passe dans chaque
sens, et de faire des captures de trafic à tous les points possibles
pour déterminer à quel endroit les paquets sont perdus : eth0,
tun0,
trafic encapsulé, à l'autre bout du VPN. Quel est le type de VPN
?
OpenVPN, VTun, autre ?


En effet, bien vu pour le MTU de eth0 :)

Pour le faible MSS je me doutais bien que c'était pas une bonne solution.

Pour la règle, effectivement un
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -i tun0 -o eth0 -j TCPMSS --set-mss 128

serait mieux pour ne modifier que les paquets qui viennent du VPN :)

Je vais essayer de faire quelques tests de ping. Le plus déconcertant c'est que depuis la passerelle tout roule (si je lance un client mail directement depuis la passerelle et que j'envoie un mail, no problemo).

Le VPN est un VPN Cisco IPSec, je m'y connecte avec vpnc.

PS : Comment faites-vous pour ne pas citer tout le message précédent ? Je n'ai vu que deux liens "Répondre à ce message" et "Répondre au sujet initial" qui me citent tous les deux automatiquement tout le message précédent en entier, c'est assez pénible :D
Avatar
Pascal Hambourg
cyberjujum a écrit :

Pour la règle, effectivement un
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -i tun0 -o
eth0 -j TCPMSS --set-mss 128

serait mieux pour ne modifier que les paquets qui viennent du VPN :)



Marchera pas. POSTROUTING voit les paquets sortants, et ne permet pas
l'option -i. Remplacer soit par PREROUTING et supprimer -o (prendra donc
aussi les paquets destinés à la machine locale), soit par FORWARD.

Je vais essayer de faire quelques tests de ping. Le plus déconcertant c'est que
depuis la passerelle tout roule (si je lance un client mail directement depuis
la passerelle et que j'envoie un mail, no problemo).



Ça c'est une information intéressante. Il faudrait capturer le trafic
dans les deux cas pour voir les différences.

Le VPN est un VPN Cisco IPSec, je m'y connecte avec vpnc.



Connais pas.

PS : Comment faites-vous pour ne pas citer tout le message précédent ?



Je coupe dans la citation.

Je n'ai
vu que deux liens "Répondre à ce message" et "Répondre au sujet initial" qui me
citent tous les deux automatiquement tout le message précédent en entier, c'est
assez pénible :D



La plupart des interfaces web-news sont mal foutues, je préfère utiliser
un vrai logiciel client de news bien plus ergonomique.
Avatar
GuiGui
Pascal Hambourg a écrit :
cyberjujum a écrit :
Le VPN est un VPN Cisco IPSec, je m'y connecte avec vpnc.



Connais pas.



Attention, vpnc utilise udp. Avez-vous essayé le client cisco en le
configurant pour se connecter en tcp (à condition que l'autre bout soit
configuré pour) ?
Avatar
Mateusz Viste
On Friday 26 June 2009 11:48, GuiGui wrote:
Attention, vpnc utilise udp.



Qu'importe, ce qui nous intéresse, c'est le flux déchiffré, pas le flux
ESP (ou UDP s'il y a du NAT-T). Le but de la limite MSS est de limiter le
payload des paquets en clair, de manière à ne pas dépasser la MTU
disponible après encapsulation...

Cordialement,
Mateusz Viste
Avatar
cyberjujum
Mateusz Viste a écrit le 26/06/2009 à 12h10 :
On Friday 26 June 2009 11:48, GuiGui wrote:
Attention, vpnc utilise udp.




Qu'importe, ce qui nous intéresse, c'est le flux
déchiffré, pas le flux
ESP (ou UDP s'il y a du NAT-T). Le but de la limite MSS est de limiter le
payload des paquets en clair, de manière à ne pas dépasser
la MTU
disponible après encapsulation...

Cordialement,
Mateusz Viste


Merci pour ces réponses :)

Pour le client news, je ne savais pas qu'on pouvait poster des messages ici de cette manière. Du coup j'utilise l'interface web qui n'est pas terrible en effet, et on ne peut pas tronquer les citations... Quelle est l'adresse du serveur de news ?

Merci également pour l'info pour la règle iptables !

Et voici un tcpdump de l'interface tun0 pendant que j'essaie d'envoyer un mail :

----------
15:49:07.065384 IP moi.43819 > serveurmail.smtp: S 1717000594:1717000594(0) win 5840 <mss 1460,sackOK,timestamp 633720 0,nop,wscale 6>
15:49:07.066732 IP moi.35643 > serveurdns.domain: 52908+ PTR? 46.9.83.195.in-addr.arpa. (42)
15:49:07.130446 IP serveurmail.smtp > moi.43819: S 2072462538:2072462538(0) ack 1717000595 win 5792 <mss 1380,sackOK,timestamp 1071302767 633720,nop,wscale 7>
15:49:07.130727 IP moi.43819 > serveurmail.smtp: . ack 1 win 92 <nop,nop,timestamp 633737 1071302767>
15:49:07.134995 IP serveurdns.domain > moi.35643: 52908* 1/3/3 (191)
15:49:07.135388 IP moi.60584 > serveurdns.domain: 64073+ PTR? 57.47.31.10.in-addr.arpa. (42)
15:49:07.198374 IP serveurmail.34866 > moi.auth: S 1572939353:1572939353(0) win 5840 <mss 1380,sackOK,timestamp 1071302784 0,nop,wscale 7>
15:49:07.198436 IP moi.auth > serveurmail.34866: R 0:0(0) ack 1572939354 win 0
15:49:07.203261 IP serveurdns.domain > moi.60584: 64073* 1/3/3 (205)
15:49:07.203643 IP moi.60479 > serveurdns.domain: 43596+ PTR? 11.9.83.195.in-addr.arpa. (42)
15:49:07.264861 IP serveurmail.smtp > moi.43819: P 1:83(82) ack 1 win 46 <nop,nop,timestamp 1071302801 633737>
15:49:07.265170 IP moi.43819 > serveurmail.smtp: . ack 83 win 92 <nop,nop,timestamp 633771 1071302801>
15:49:07.265458 IP moi.43819 > serveurmail.smtp: P 1:22(21) ack 83 win 92 <nop,nop,timestamp 633771 1071302801>
15:49:07.270499 IP serveurdns.domain > moi.60479: 43596* 1/3/3 (182)
15:49:07.334730 IP serveurmail.smtp > moi.43819: . ack 22 win 46 <nop,nop,timestamp 1071302818 633771>
15:49:07.335594 IP serveurmail.smtp > moi.43819: P 83:223(140) ack 22 win 46 <nop,nop,timestamp 1071302818 633771>
15:49:07.336450 IP moi.43819 > serveurmail.smtp: P 22:78(56) ack 223 win 108 <nop,nop,timestamp 633788 1071302818>
15:49:07.429453 IP serveurmail.smtp > moi.43819: P 223:286(63) ack 78 win 46 <nop,nop,timestamp 1071302842 633788>
15:49:07.431352 IP moi.43819 > serveurmail.smtp: P 78:111(33) ack 286 win 108 <nop,nop,timestamp 633812 1071302842>
15:49:07.501985 IP serveurmail.smtp > moi.43819: P 286:340(54) ack 111 win 46 <nop,nop,timestamp 1071302860 633812>
15:49:07.502559 IP moi.43819 > serveurmail.smtp: P 111:117(6) ack 340 win 108 <nop,nop,timestamp 633830 1071302860>
15:49:07.568847 IP serveurmail.smtp > moi.43819: P 340:396(56) ack 117 win 46 <nop,nop,timestamp 1071302877 633830>
15:49:07.578033 IP moi.43819 > serveurmail.smtp: . 117:1455(1338) ack 396 win 108 <nop,nop,timestamp 633849 1071302877>
15:49:07.578087 IP moi.43819 > serveurmail.smtp: . 1455:2793(1338) ack 396 win 108 <nop,nop,timestamp 633849 1071302877>
15:49:07.579856 IP moi.43819 > serveurmail.smtp: . 4213:5551(1338) ack 396 win 108 <nop,nop,timestamp 633849 1071302877>
15:49:07.700444 IP serveurmail.smtp > moi.43819: . ack 2793 win 88 <nop,nop,timestamp 1071302909 633849>
15:49:07.700829 IP moi.43819 > serveurmail.smtp: . 2793:2853(60) ack 396 win 108 <nop,nop,timestamp 633879 1071302909>
15:49:07.700926 IP moi.43819 > serveurmail.smtp: . 2853:4191(1338) ack 396 win 108 <nop,nop,timestamp 633879 1071302909>
15:49:07.700960 IP moi.43819 > serveurmail.smtp: P 4191:4213(22) ack 396 win 108 <nop,nop,timestamp 633879 1071302909>
15:49:07.730519 IP serveurmail.smtp > moi.43819: . ack 2793 win 88 <nop,nop,timestamp 1071302917 633849,nop,nop,sack 1 {198580283:198581621}>
15:49:07.730572 IP moi.43819 > serveurmail.smtp: R 1717003387:1717003387(0) win 0
15:49:07.769328 IP serveurmail.smtp > moi.43819: . ack 2853 win 88 <nop,nop,timestamp 1071302927 633879,nop,nop,sack 1 {198580283:198581621}>
15:49:07.769392 IP moi.43819 > serveurmail.smtp: R 1717003447:1717003447(0) win 0
15:49:07.799524 IP serveurmail.smtp > moi.43819: . ack 4191 win 108 <nop,nop,timestamp 1071302934 633879,nop,nop,sack 1 {198580283:198581621}>
15:49:07.799570 IP moi.43819 > serveurmail.smtp: R 1717004785:1717004785(0) win 0
15:49:07.803062 IP serveurmail.smtp > moi.43819: . ack 5551 win 108 <nop,nop,timestamp 1071302935 633879>
15:49:07.803690 IP moi.43819 > serveurmail.smtp: . 5551:6889(1338) ack 396 win 108 <nop,nop,timestamp 633905 1071302935>
15:49:07.803750 IP moi.43819 > serveurmail.smtp: P 6889:8227(1338) ack 396 win 108 <nop,nop,timestamp 633905 1071302935>
15:49:07.803774 IP moi.43819 > serveurmail.smtp: . 8227:9565(1338) ack 396 win 108 <nop,nop,timestamp 633905 1071302935>
15:49:07.896299 IP serveurmail.smtp > moi.43819: . ack 6889 win 129 <nop,nop,timestamp 1071302959 633905>
15:49:07.897011 IP moi.43819 > serveurmail.smtp: . 9565:10903(1338) ack 396 win 108 <nop,nop,timestamp 633928 1071302959>
15:49:07.925829 IP serveurmail.smtp > moi.43819: . ack 8227 win 150 <nop,nop,timestamp 1071302966 633905>
15:49:07.926486 IP moi.43819 > serveurmail.smtp: . 10903:12241(1338) ack 396 win 108 <nop,nop,timestamp 633936 1071302966>
15:49:07.926532 IP moi.43819 > serveurmail.smtp: . 12241:13579(1338) ack 396 win 108 <nop,nop,timestamp 633936 1071302966>
15:49:07.926555 IP moi.43819 > serveurmail.smtp: . 13579:14917(1338) ack 396 win 108 <nop,nop,timestamp 633936 1071302966>
15:49:07.954835 IP serveurmail.smtp > moi.43819: . ack 9565 win 171 <nop,nop,timestamp 1071302973 633905>
15:49:07.955513 IP moi.43819 > serveurmail.smtp: . 14917:16255(1338) ack 396 win 108 <nop,nop,timestamp 633943 1071302973>
15:49:07.955566 IP moi.43819 > serveurmail.smtp: . 16255:17593(1338) ack 396 win 108 <nop,nop,timestamp 633943 1071302973>
15:49:07.989376 IP serveurmail.smtp > moi.43819: . ack 10903 win 192 <nop,nop,timestamp 1071302982 633928>
15:49:07.990294 IP moi.43819 > serveurmail.smtp: . 17593:18931(1338) ack 396 win 108 <nop,nop,timestamp 633952 1071302982>
15:49:07.990346 IP moi.43819 > serveurmail.smtp: . 18931:20269(1338) ack 396 win 108 <nop,nop,timestamp 633952 1071302982>
15:49:08.020081 IP serveurmail.smtp > moi.43819: . ack 12241 win 213 <nop,nop,timestamp 1071302990 633936>
15:49:08.020807 IP moi.43819 > serveurmail.smtp: . 20269:21607(1338) ack 396 win 108 <nop,nop,timestamp 633959 1071302990>
15:49:08.020865 IP moi.43819 > serveurmail.smtp: . 21607:22945(1338) ack 396 win 108 <nop,nop,timestamp 633959 1071302990>
15:49:08.049333 IP serveurmail.smtp > moi.43819: . ack 13579 win 234 <nop,nop,timestamp 1071302997 633936>
15:49:08.078704 IP serveurmail.smtp > moi.43819: . ack 14917 win 255 <nop,nop,timestamp 1071303004 633936>
15:49:08.079368 IP moi.43819 > serveurmail.smtp: . 22945:24283(1338) ack 396 win 108 <nop,nop,timestamp 633974 1071303004>
15:49:08.079416 IP moi.43819 > serveurmail.smtp: . 24283:25621(1338) ack 396 win 108 <nop,nop,timestamp 633974 1071303004>
15:49:08.079439 IP moi.43819 > serveurmail.smtp: . 25621:26959(1338) ack 396 win 108 <nop,nop,timestamp 633974 1071303004>
15:49:08.079603 IP moi.43819 > serveurmail.smtp: . 26959:28297(1338) ack 396 win 108 <nop,nop,timestamp 633974 1071303004>
15:49:08.108045 IP serveurmail.smtp > moi.43819: . ack 16255 win 276 <nop,nop,timestamp 1071303012 633943>
15:49:08.138274 IP serveurmail.smtp > moi.43819: . ack 17593 win 297 <nop,nop,timestamp 1071303019 633943>
15:49:08.138981 IP moi.43819 > serveurmail.smtp: . 28297:29635(1338) ack 396 win 108 <nop,nop,timestamp 633989 1071303019>
15:49:08.139044 IP moi.43819 > serveurmail.smtp: . 29635:30973(1338) ack 396 win 108 <nop,nop,timestamp 633989 1071303019>
15:49:08.139070 IP moi.43819 > serveurmail.smtp: . 30973:32311(1338) ack 396 win 108 <nop,nop,timestamp 633989 1071303019>
15:49:08.139093 IP moi.43819 > serveurmail.smtp: . 32311:33649(1338) ack 396 win 108 <nop,nop,timestamp 633989 1071303019>
15:49:08.158690 IP unautrepc.50390 > moi.1111: UDP, length 11
15:49:08.158808 IP moi > unautrepc: ICMP moi udp port 1111 unreachable, length 47
15:49:08.159248 IP moi.45514 > serveurdns.domain: 37448+ PTR? 134.47.31.10.in-addr.arpa. (43)
15:49:08.166323 IP serveurmail.smtp > moi.43819: . ack 18931 win 318 <nop,nop,timestamp 1071303026 633952>
15:49:08.167007 IP moi.43819 > serveurmail.smtp: . 33649:34987(1338) ack 396 win 108 <nop,nop,timestamp 633996 1071303026>
15:49:08.167057 IP moi.43819 > serveurmail.smtp: . 34987:36325(1338) ack 396 win 108 <nop,nop,timestamp 633996 1071303026>
15:49:08.195412 IP serveurmail.smtp > moi.43819: . ack 20269 win 338 <nop,nop,timestamp 1071303033 633952>
15:49:08.225454 IP serveurmail.smtp > moi.43819: . ack 21607 win 359 <nop,nop,timestamp 1071303041 633959>
15:49:08.226065 IP moi.43819 > serveurmail.smtp: . 36325:37663(1338) ack 396 win 108 <nop,nop,timestamp 634011 1071303041>
15:49:08.226125 IP moi.43819 > serveurmail.smtp: . 37663:39001(1338) ack 396 win 108 <nop,nop,timestamp 634011 1071303041>
15:49:08.226140 IP moi.43819 > serveurmail.smtp: . 39001:40339(1338) ack 396 win 108 <nop,nop,timestamp 634011 1071303041>
15:49:08.226337 IP moi.43819 > serveurmail.smtp: . 40339:41677(1338) ack 396 win 108 <nop,nop,timestamp 634011 1071303041>
15:49:08.254248 IP serveurmail.smtp > moi.43819: . ack 21607 win 359 <nop,nop,timestamp 1071303048 633959,nop,nop,sack 1 {198599015:198600353}>
15:49:08.254310 IP moi.43819 > serveurmail.smtp: R 1717022201:1717022201(0) win 0
15:49:08.284515 IP serveurmail.smtp > moi.43819: . ack 21607 win 359 <nop,nop,timestamp 1071303056 633959,nop,nop,sack 1 {198599015:198601691}>
15:49:08.284578 IP moi.43819 > serveurmail.smtp: R 1717022201:1717022201(0) win 0
15:49:08.313098 IP serveurmail.smtp > moi.43819: . ack 21607 win 359 <nop,nop,timestamp 1071303063 633959,nop,nop,sack 1 {198599015:198603029}>
15:49:08.313156 IP moi.43819 > serveurmail.smtp: R 1717022201:1717022201(0) win 0
15:49:08.343255 IP serveurmail.smtp > moi.43819: . ack 21607 win 359 <nop,nop,timestamp 1071303070 633959,nop,nop,sack 1 {198599015:198604367}>
15:49:08.343296 IP moi.43819 > serveurmail.smtp: R 1717022201:1717022201(0) win 0
15:49:08.371335 IP serveurmail.smtp > moi.43819: . ack 21607 win 359 <nop,nop,timestamp 1071303077 633959,nop,nop,sack 1 {198599015:198605705}>
15:49:08.371373 IP moi.43819 > serveurmail.smtp: R 1717022201:1717022201(0) win 0
15:49:08.401478 IP serveurmail.smtp > moi.43819: . ack 21607 win 359 <nop,nop,timestamp 1071303085 633959,nop,nop,sack 1 {198599015:198607043}>
15:49:08.401518 IP moi.43819 > serveurmail.smtp: R 1717022201:1717022201(0) win 0
15:49:08.430462 IP serveurmail.smtp > moi.43819: . ack 21607 win 359 <nop,nop,timestamp 1071303092 633959,nop,nop,sack 2 {198612395:198613733}{198599015:198607043}>
15:49:08.430503 IP moi.43819 > serveurmail.smtp: R 1717022201:1717022201(0) win 0
15:49:08.460527 IP serveurmail.smtp > moi.43819: . ack 21607 win 359 <nop,nop,timestamp 1071303099 633959,nop,nop,sack 2 {198612395:198615071}{198599015:198607043}>
15:49:08.460575 IP moi.43819 > serveurmail.smtp: R 1717022201:1717022201(0) win 0
15:49:08.609247 IP moi.43819 > serveurmail.smtp: . 21607:22945(1338) ack 396 win 108 <nop,nop,timestamp 634107 1071303041>
15:49:09.377278 IP moi.43819 > serveurmail.smtp: . 21607:22945(1338) ack 396 win 108 <nop,nop,timestamp 634299 1071303041>
15:49:10.913294 IP moi.43819 > serveurmail.smtp: . 21607:22945(1338) ack 396 win 108 <nop,nop,timestamp 634683 1071303041>
15:49:13.166504 IP moi.46239 > serveurdns2.domain: 37448+ PTR? 134.47.31.10.in-addr.arpa. (43)
15:49:13.233928 IP serveurdns2.domain > moi.46239: 37448* 1/3/3 (207)
15:49:13.235227 IP moi.59615 > serveurdns.domain: 36409+ PTR? 12.9.83.195.in-addr.arpa. (42)
15:49:13.301892 IP serveurdns.domain > moi.59615: 36409* 1/3/3 (182)
15:49:13.985336 IP moi.43819 > serveurmail.smtp: . 21607:22945(1338) ack 396 win 108 <nop,nop,timestamp 635451 1071303041>
15:49:20.129406 IP moi.43819 > serveurmail.smtp: . 21607:22945(1338) ack 396 win 108 <nop,nop,timestamp 636987 1071303041>
----------

Voulez vous le même dans le cas d'un envoi depuis la passerelle (envoi qui fonctionne donc ?)

Et pour l'histoire du TCP/UDP, est-ce que ça vaut le coup que je change de client alors ? Sous Windows, le client Cisco a la facheuse tendance à "bloquer" toutes les autres connexions (plus de réseau local par exemple). Comme le VPN auquel je me connecte ne me donne accès qu'à une poignée de serveurs et oblige à passer par un proxy pour atteindre l'extérieur, c'est assez embêtant... vpnc n'a pas cet inconvénient, je ne sais pas si la version linux du client Cisco l'aura :)
Avatar
GuiGui
cyberjujum a écrit :


Et pour l'histoire du TCP/UDP, est-ce que ça vaut le coup que je change de
client alors ? Sous Windows, le client Cisco a la facheuse tendance à "bloquer"
toutes les autres connexions (plus de réseau local par exemple). Comme le VPN
auquel je me connecte ne me donne accès qu'à une poignée de serveurs et oblige à
passer par un proxy pour atteindre l'extérieur, c'est assez embêtant... vpnc n'a
pas cet inconvénient, je ne sais pas si la version linux du client Cisco l'aura
:)



Je parlais du client cisco linux, pas windows. Notes que le client linux
a le même défaut que le client windows : je n'ai jamais réussi à lui
faire passer du split-tunnel (en ayant bien sûr activé l'option des deux
cotés) tandis qu'un autre client (vpnc, anyconnect) passe sans problème
en split-tunnel dès que le serveur VPN pousse cette configuration vers
le client. Par contre, il est toujours possible de modifier les routes
après connexion, donc pour un test c'est jouable.
1 2 3 4