VPN OpenSwan&Xl2tp problem with big udp packets

[klimmrod]

Hi all,

I'm having a problem with my vpn server using openswan et xl2tp on a gentoo linux.

All the tcp traffic seems to work fine but my udp packets don't pass correctly inside the vpn. The application tries to send packets of 1500bytes. The problem is the packets are cut but all the payload doesn't pass to the ppp+ interface.

I saw it with iptraf and tcpdump tools.

I have set my LAN interface with a mtu of 1400 and the WAN interface have a mtu of 1500 set by the dhcp of my ethernet modem.

In the options.l2tpd file, the mtu and the mru are set to 1400.

I don't have the possibility to change the protocole used by the application because it's an electronic regulator and a non opensource application.æ

The client of the server is a modem/router/vpn client. But the problem is already in the server because I see the UDP packet truncated when they come from my local network.

Are there options to force the VPN to rebuild the udp packet as they arrived on the other side ?

Did I miss something in the configuration to force the application to use smaller udp packets ?

Thanks for all the help or advice you can give me.

[Franck78]

Hi,

Just a small schema with interface names, path etc. So that it is easy to see where you apply MTU size, where you capture packet (tcpdump).
Also produce an extract of failing exchange (tcpdump).

Not sure playing with MTU helps. But here is another one:
ipsec..conf=>
overridemtu=XXXX


Franck

[klimmrod]

La question que je me pose c'est quel est le comportement normal d'un packet udp d'une taille supérieure à 1400 octet lorsqu'il arrive du réseau local dans le serveur. Alors que le mtu de l'interface LAN est à 1400.

Il est visiblement tronqué à 1400 octet avant de passer dans le router/server/vpn.

Mais que se passe-t-il avec la fin du packet. Est-il transmis dans un second packet ? Je ne trouve aucune trace de celui-ci.

Pensez-vous qu'il existe un protocole vpn qui reconstruise à l'identique les packets tel qu'ils étaient avant d'entrer dans le tunnel lorsqu'ils ont été tronqués ? Si oui lequel ?

[arapaho]

Simple question avant de répondre: bloques-tu le protocole ICMP ?

[klimmrod]

Non le protocol icmp n'est pas bloqué d'ailleur je parviens sans problème à faire des ping à travers le vpn sans le moindre problème. Ainsi que passer des données TCP.

Seul les packets UDP de taille trop importante posent problème.

[arapaho]

La source du problème peut être multiple et tu ne donnes pas assez d'infos pour t'aiguiller correctement.

1 : La gestion ipsec d'un des côté est buggée / mal implémentée/configurée
2 : Le client embarque une pile ip foireuse, voir à le mettre à jour
3 : Mauvaise gestion du pmtu
4 : [Je pars du principe que tu te trouves sur des opérateurs ADSL au moins d'un côté du VPN] Un des opérateur entrant en jeu dispose d'une QoS qui fout tout en l'air: une fois le VPN établi, si un ping -s 1000 ou un ping -s 5000 traversant ne passe pas, alors mauvais opérateur, changer opérateur.

[klimmrod]

Merci pour tes infos,

Je ne comprends pas pourquoi le test de ping -s 5000 puisque le mtu est à 1500 maximum ?
Par contre je vais tester les autres valeurs.

Le client est un router hardware donc je ne sais pas si une mise à jour est possible.
Je passe bien par 1 fournisseur d'accès ADSL qui est le même des 2 côtés mais on ne doit pas être dans la même classe de réseau puisque un possède une ip fix et l'autre pas.

Quand au serveur, c'est une gentoo avec un kernel 2.6.19. Je n'ai rien lu de spécial à son sujet.

Le pmtu est censé être géré par l'application ou l'OS ?

[arapaho]

Je ne comprends pas pourquoi le test de ping -s 5000 puisque le mtu est à 1500 maximum ?

Si déjà là dessus, le ping ne passe pas, alors il y a un problème de communication entre les deux hôtes (configuration, QoS, opérateur, autre ...). Grossièrement (je vais pas reprendre les docs présentes partout sur le Net), ils doivent se mettre d'accord sur le plus petit mtu a employer, en fonction du pmtu, gérer les MSS etc ... Les icmps doivent se dire "haha attention, il faut te fragmenter etc ..."

Le client est un router hardware donc je ne sais pas si une mise à jour est possible.
Je passe bien par 1 fournisseur d'accès ADSL qui est le même des 2 côtés mais on ne doit pas être dans la même classe de réseau puisque un possède une ip fix et l'autre pas.

Et bien voilà, on en sait un peu plus ! Donc l'application n'est pas le point final du VPN. Ce serait pas mal d'avoir un petit schéma représentant l'application, le routeur, le serveur VPN, la connexion Internet, etc, avec les mtu que tu connais (par défaut, pas modifiés). Est-ce que tes connexions ADSL sont de type ppp* ? Tu utilises ipsec en mode transport ou tunnel ?

Le pmtu est censé être géré par l'application ou l'OS ?

C'est géré par l'OS. Ce serait pas mal de spécifier les OS dans le schéma stp.

[klimmrod]

Merci bcq pour tes réponses Arapaho.

Le ping passe sans problème ainsi que les transferts de données TCP.
Je me posais la question de l'intérêt de faire des ping de plus 1500octets de donnée comme on sait très bien que le mtu est à 1500 maximum.

Seul le passage de donnée udp semble poser problème sur l'installation


Au niveau topologie on a :

GestionRégulateur ---------Serveur Gentoo xl2tp/openswan ------------ router harware ------------------ Régulateur
mtu1500 192.168.0.2 mtu1400 192.168.0.1 mtu1500 WAN mtu ???? mtu ??? mtu non définissable
IP Statique x.x.x.x IP Dynamique 192.168.1.1 192.168.1.2


Si je mets mon PC à la place du régulateur je peux communiquer ping+donnée TCP avec le PC de gestion.
Si je me le régulateur à la place de mon PC pas de problème non plus sur le ping du PC de gestion vers le régulateur.

Lorsque je sniff les packets sur le serveur je vois de petits packets udp passer entre le régulateur et le PC de gestion.
Mais après qqn packetsUDP qui semblent être d'aknoledgment le PC de gestion envoit plusieurs packets de 1500 octets et le régulateur ne répond plus.

Malheureusement je ne peux comprendre ce qui passe dans les packets car ce n'est pas un protocole UDP ouvert.

Toute fois il semble que le problème soit que les packets soient émis avec une taille de 1500 et ramenés par le serveur à une taille de 1400. Ensuite les packets étant incomplet le régulateur ne sait plus quoi faire.

Si je reconfigure l'interface LAN à un mtu de 1500, j'observe des packets de 1500octets arrivant sur l'interface LAN et ensuite les packets ont une taille de 1400 une fois sur l'interface PPP0(tunnel) sans avoir un deuxième plus petit packet qui suivrait avec le reste des données.
Est-ce le comportement normal ?

Je pense que c'est le mode tunnel qui est employé. Si j'utilisais le mode transport est-ce que la taille du payload devrait aussi être réduite ? Pour ma part je pense que c'est obligatoire sauf si le protocole permet de recomposer les packets à l'identique.

Merci pour toutes vos remarques qui m'aiderraient à progresser.

klimmrod

[arapaho]

Pourquoi le MTU côté LAN du serveur gentoo est à 1400 ?

[klimmrod]

Bonjour,

C'était pe une $%#&! en effet, je viens de le remettre à 1500. C'était pour que les données échangées sur le LAN ne soient pas plus grande que ce qu'il est permis d'échangé sur le vpn.

Par contre g un nouvel indice, que je ne parviens pas à interpréter, lorsque le le vpn reste connecté un long moment et que le les machines s'envoient des données, le server fini par se retrouver par terre niveau réseau.

Plus moyen de faire un route ça prend la blinde de temps.

Lorsque je fais un iptables -L -n -v la partie Chain Input sort instantanément par contre la partir Chain forward prends énormément de temps je sais même plus si g eu la patience d'attendre.

Comment peut on voir l'état du NAT ? Si il est saturé ou quoi ?

JE n'ai rien trouvé et puis je pouvais plus browser le net à ce moment là.

Merci