Je me suis gouré dans mes routes d'hier puisque qu'il faut obligatoirement que la passerelle soit sur le même sous-réseau (comme ai-je pû oublier cette règle élèmentaire  ), donc en théorie :

192.168.1.0/24 gateway 192.168.2.1
192.168.2.0/24 gateway 192.168.1.1

Mais toujours rien.

Me revoilà après avoir mis de côté ce projet, avec du nouveau :

Après de plus amples recherches, je viens enfin de comprendre pourquoi ajouter des routes ne fonctionne pas : strongswan construit par défaut un policy-based tunnel et non un route-based.

Et je viens de voir qu'il existe un moyen de créer un tunnel route based en se servant des VTI Devices. Cependant j'ai pas bien compris ce qu'il faut renseigner dans la commande :

Code: [Sélectionner]

ip tunnel add <name> local <local IP> remote <remote IP> mode vti key <number equaling the mark>
En particulier, dans local et remote. Ça correspond  a un subnet quelconque pour le tunnel ? Ou c'est les ip publiques de chaque routeur ? Si c'est les ip publiques, ça se passe comment vu que je suis en ip dynamique ? J'imagine qu'on ne peut pas rentrer des FQDN, si ?

Après je peux toujours essayer de le configurer via les policy, mais j'avoue que c'est assez indigeste, j'ai pas compris grand chose 

Attention je me trompe p-e, jamais fait d'ipsec sur openwrt.


J'utilise les vti sur nos UTM pour le taff, et le vti n’empêche pas d'utiliser la policy route, en faite c'est juste que la policy route permet d'atteindre l'interface VTI du routeur distant (une interface crée uniquement pour ça).

Exemple :

Routeur A Interface VTI 192.168.254.249/30
Routeur B Interface VTI 192.168.254.250/30

Et donc ton tunnel ipsec te permet juste le dialogue entre les VTI.

Mais du coup, grace à ça tu peux faire des routes statique pour atteindre un lan derrière :

Sur le routeur A :
Net : 192.168.2.0/24 GW 192.168.254.250

Sur le routeur B :
Net : 192.168.1.0/24 GW 192.168.254.249

Pourquoi c'est beaucoup plus puissant de faire ça plutot qu'envoyer les routes des lan directement dans la policy ipsec ?
 - Tout simplement car du coup, tu peux creer autant d'interface VTI que de lien WAN sur ton routeur, tu montes autant de tunnel ipsec vti vers vti que tu as de WAN, et donc tu peux avoir des routes statiques avec des metriques différentes pour atteindre les lan, afin d'avoir de la redondance sur ton vpn ipsec si le lien wan principal tombe par exemple .

En espérant que ce soit pareil sur openwrt, et que ça t'aide à la compréhension.
A+

Je ne sais pas pourquoi sur la doc que j'ai lue, ils disaient de renseigner les ip publiques...

Parce que c’est le cas...

D’ailleurs ça rend vti pratiquement inutilisable avec des IP dynamiques (sauf à faire un script exécuté par cron régulièrement pour reconfigurer le tunnel à chaque changement d’IP d’un des 2 bouts...).

Sinon, il semblerait que libreswan (que je n’ai pas testé en pratique) soit un peu plus souple dans sa gestion des interfaces vti et soit capable de les reconfigurer tout seul. A voir...

Donc en définitive, qui a raison ? Les deux sont possible ?

Si avec l'exemple d'ubune je fois bien comment ça fonctionne, avec les ip publiques j'ai un peu de mal.

J'ai pas bien compris la remarque, mais oui il faut toujours utiliser les ip publiques pour monter le tunnel (faut bien un dialogue IP_PubA vers IP_PubB..).
Et les VTI pourront dialoguer entre elles grace aux policy routes.

Quand j'aurai un peu de temps j'essaierai aussi, et je ferai un retour
A+

Non, les IP local et remote servent à indiquer au noyau quelle security policy rechercher quand un paquet entre sur l’interface. Rien à voir avec le routage. Si ton interface VTI est aussi utilisée pour faire du routage, alors il faut en plus lui affecter une adresse IP (ip addr add).

La documentation de strongswan concernant les route based policy est assez explicite sur ce point. D’ailleurs quand le cas des VPN road warrior il est possible de mettre 0.0.0.0/0 pour le remote, car les clients ont généralement une IP dynamique. L’inconvénient étant alors que cette interface va prendre tout le traffic IPSec entrant quelque soit la source, et qu’il est donc impossible d’utiliser une VTI supplèmentaire.

Je me goure encore peut-être : est-ce que le mode passthrough serait la solution pour que les LAN soient joignables de chaque côté sans config supplèmentaire ?

J'ai testé ce qui était dans la doc à savoir  :
conn passthrough-2
    # makes sure those conns are excluded from every conn selection
    left=127.0.0.1
    # Those are just example values. Replace them with the apropriate ones!
    leftsubnet=192.168.0.0/16
    rightsubnet=10.0.0.0/8
    # those two lines are critical.
    type=passthrough
    auto=route
Problème, le fait de mettre auto=route de chaque côté, le tunnel ne monte jamais. Aucun ne prend l'initiative d'initier la connexion (ils s'arrêtent au chargement de la configuration). Par contre dès que je mets add et start là ça marche mais du coup le passthrough ne fonctionne plus.

Ce qui est étrange c'est que ça fonctionnait parfaitement lorsque la config était sur les routeurs directement avec par contre type=tunnel (cette config là ne fonctionne pas non plus sur les VM... c'est la première que j'ai testée).

Un problème de version ? Sur OWRT c'est la 5.6.3, sur debian stretch 5.5.1.