OpenVpn dualwan

Bonjour à tous,

je mets en place une plateforme de test avec une passerelle possédant deux liens wan.(une réservée pour mon lien vpn(WAN1) et l’autre pour les consulations internet(WAN2) : http, mail etc… cette dernière sera mon chemin par défaut)

j’ai installé sans problème openvpn et je l’ai fait fonctionné sans souci avec un client.

Le problème c’est que j’aimerai créer la connexion sur mon deuxième lien wan qui n’est pas ma connexion par défaut. Pour palier à ce problème j’utilise iproute2 en suivant ce tuto

http://lartc.org/howto/lartc.rpdb.multiple-links.html

Il permet à toute connexion entrante par une interface de repartir par cette interface et éviter ainsi d’utiliser la passerelle par défaut de la table main(et donc l’interface WAN2).

Après mise en place il marche parfaitement puisque testé avec de l’udp et du tcp (dns imap smtp etc…). Les connexions entrantes par WAN1 qui n’est pas ma passerelle par défaut repartent bien par cette interface, sauf pour openvpn en UDP uniquement car en tcp tout marche parfaitement.

Effectivement le client se connecte sur l’interface WAN1 mais la réponse repart par l’interface WAN2 ce qui n’est évidemment pas bon(vu avec tcpdump). A noter que mon openvpn et en écoute sur ces deux interfaces au cas ou la ligne WAN1 serait coupée le client basculerait automatiquement sur le WAN2. A l’écoute uniquement sur l’interface WAN1, la connexion repart bien par cette dernière. Je souhaite pouvoir être à l’écoute sur les deux interfaces

C’est à me rendre chèvre, j’ai écumé les forums du net sans résultat à part deux trois cas sans réponses rien de plus. Peut-être un bug de openvpn je suis en debian 5.05 openvpn 2.1.

Si vous avez une idée votre aide me serait très précieuse,

merci d’avance

Cordialement

Comment as-tu fait le routage avancé ? Avec une règle ip rule from basée sur l’adresse source ?
Et si tu forces openvpn à n’écouter que sur l’adresse de WAN1 ?

Il me semble effectivement avoir entendu parler d’un “bug” d’openvpn en UDP, qui ne renvoie pas forcément les paquets avec la même adresse source que celle sur laquelle il a reçu les paquets. C’est en fait le fonctionnement normal par défaut d’UDP, qui est par définition un protocole non connecté avec des datagrammes indépendants. C’est par convention que certains protocoles basés sur UDP comme DNS forcent l’adresse et le port source de la réponse identiques à l’adresse et au port destination de la requête, de la même façon que TCP.

Suivant la logique de base d’UDP, openvpn envoie un paquet UDP avec l’adresse source par défaut, correspondant à l’interface de la route par défaut. Donc même si tu parviens à router les paquets de réponse par la bonne interface, ils auront encore la mauvaise adresse IP source, avec comme conséquences possibles :

  1. Le FAI de ce lien peut bloquer les paquets pour mauvaise adresse IP source.
  2. Un pare-feu ou dispositif NAT côté le client peut bloquer les paquets dont l’adresse source ne correspond pas à une connexion sortante connue.

Donc il te reste un peu de boulot :

  1. Trouver comment identifier et router les paquets UDP de réponse d’openvpn via la bonne interface. Certainement en les marquant avec la cible MARK d’iptables. On ne peut pas utiliser le marquage de connexion (CONNMARK) car l’adresse source ne correspond pas ; il reste éventuellement le port source, l’UID du processus openvpn si spécifique…
  2. Remettre la bonne adresse source avec une règle SNAT ou MASQUERADE. Ça, c’est facile.

Voilà, en espérant que ça aide.