La Fibre
Télécom => Réseau => 
VPN => Discussion démarrée par: renaud07 le 04 mars 2019 à 15:55:26
-
Bonjour,
Après mes déboires avec wireguard (https://lafibre.info/vpn/vpn-wireguard-entre-2-openwrt/), j'ai décidé de passer sur IPsec on ne peut plus stable.
Voici une config que je pense correcte :
Routeur A
config 'ipsec'
list listen ''
option 'debug' '2'
config 'remote' 'other'
option 'enabled' '1'
option 'gateway' 'domaine.routeur.B'
option 'authentication_method' 'psk'
option 'pre_shared_key' 'xxxxxx'
option 'exchange_mode' 'aggressive'
option 'local_identifier' 'tunnelid'
list 'crypto_proposal' 'pre_g14_aes_sha1'
list 'tunnel' 'other_lan'
config 'crypto_proposal' 'pre_g14_aes_sha1'
option 'encryption_algorithm' 'aes128'
option 'hash_algorithm' 'sha1'
option 'dh_group' 'modp2048'
config 'tunnel' 'other_lan'
option 'local_subnet' '192.168.1.0/24'
option 'remote_subnet' '192.168.2.0/24'
option 'crypto_proposal' 'g14_aes_sha1'
config 'crypto_proposal' 'g14_aes_sha1'
option 'dh_group' 'modp2048'
option 'encryption_algorithm' 'aes128'
option 'hash_algorithm' 'sha1'
Routeur B
config 'ipsec'
list listen ''
option 'debug' '2'
config 'remote' 'other'
option 'enabled' '1'
option 'gateway' 'domaine.routeur.A'
option 'authentication_method' 'psk'
option 'pre_shared_key' 'xxxxxx'
option 'exchange_mode' 'aggressive'
option 'local_identifier' 'tunnelid'
list 'crypto_proposal' 'pre_g14_aes_sha1'
list 'tunnel' 'other_lan'
config 'crypto_proposal' 'pre_g14_aes_sha1'
option 'encryption_algorithm' 'aes128'
option 'hash_algorithm' 'sha1'
option 'dh_group' 'modp2048'
config 'tunnel' 'other_lan'
option 'local_subnet' '192.168.2.0/24'
option 'remote_subnet' '192.168.1.0/24'
option 'crypto_proposal' 'g14_aes_sha1'
config 'crypto_proposal' 'g14_aes_sha1'
option 'dh_group' 'modp2048'
option 'encryption_algorithm' 'aes128'
option 'hash_algorithm' 'sha1'
Comme dit précédemment (https://lafibre.info/vpn/vpn-wireguard-entre-2-openwrt/msg629759/#msg629759), sur le routeur resté en 17.01, j'ai une erreur de script, faut-il remettre à zéro ou un upgrade en 18.06 devrait résoudre le problème ? :
root@LEDE:~# opkg install strongswan
Installing strongswan (5.5.3-1) to root...
Downloading http://downloads.lede-project.org/releases/17.01.4/packages/mips_24kc/packages/strongswan_5.5.3-1_mips_24kc.ipk
Configuring strongswan.
/etc/rc.common: line 145: ipsec: not found
Merci d'avance
-
Visiblement j'ai raté un truc... lorsque je démarre ipsec, la config est bien générée, par contre aucun log... Du coup je ne sais pas si ça essaie de se connecter.
Faut rajouter une ligne pour lui dire d'écrire dans les log ?
De même je pense que la config n'est pas bonne, il faut mettre 2 ID différents en spécifiant l'option 'remote_identifier' ?
Voici les 2 config générées, est-ce ok ? :
Routeur A
conn routeurB-routeurB_lan
left=%any
right=domaine.routeurB
leftsubnet=192.168.1.0/24
ikelifetime=3h
lifetime=1h
margintime=9m
keyingtries=3
dpdaction=none
dpddelay=30s
leftauth=psk
rightauth=psk
rightsubnet=192.168.2.0/24
auto=route
leftid=routeurA
rightid=routeurB
keyexchange=ikev2
esp=aes128-sha1-modp2048
ike=aes128-sha1-modp2048
type=tunnel
Routeur B
conn routeurA-routeurA_lan
left=%any
right=domaine.routeurA
leftsubnet=192.168.2.0/24
ikelifetime=3h
lifetime=1h
margintime=9m
keyingtries=3
dpdaction=none
dpddelay=30s
leftauth=psk
rightauth=psk
rightsubnet=192.168.1.0/24
auto=route
leftid=routeurB
rightid=routeurA
keyexchange=ikev2
esp=aes128-sha1-modp2048
ike=aes128-sha1-modp2048
type=tunnel
-
J'ai ajouté les règles de firewall, comme indiqué sur le topic que j'avais trouvé (https://forum.openwrt.org/t/ipsec-site-to-site-tunnel/17920/8) mais toujours aucune trace d'ipsec dans les logs. Pourant, strongswan.conf contient :
root@LEDE:~# cat /var/ipsec/strongswan.conf
# generated by /etc/init.d/ipsec
charon {
load_modular = yes
install_routes = yes
plugins {
include /etc/strongswan.d/charon/*.conf
}
syslog {
identifier = ipsec
daemon {
default = 2
}
auth {
default = 2
}
}
}
Donc en théorie ça devrait m'afficher quelque chose, non ? En tout cas toujours pas de tunnel établi.
Je sèche un peu là... On dirait que le script se contente de générer la config sans démarrer le service.
-
J'ai enfin quelque chose ! Il fallait en fait bien que j'installe le paquet strongswan-full.
Désormais une connexion semble se faire puisque j'ai vu passer dans les log :
Thu Mar 7 16:44:25 2019 authpriv.info ipsec: 14[IKE] IKE_SA routeurB-routeurB_lan[1] established between 90.14.131.xx[routeurA]...90.14.5.xx[lrouteurB]
Thu Mar 7 16:44:25 2019 daemon.info ipsec: 14[IKE] IKE_SA routeurB-routeurB_lan[1] established between 90.14.131.xx[routeurA]...90.14.5.xx[routeurB]
Thu Mar 7 16:44:25 2019 authpriv.info ipsec: 14[IKE] IKE_SA routeurB-routeurB_lan[1] state change: CONNECTING => ESTABLISHED
Thu Mar 7 16:44:25 2019 daemon.info ipsec: 14[IKE] IKE_SA routeurB-routeurB_lan[1] state change: CONNECTING => ESTABLISHED
Ainsi que :
Thu Mar 7 16:44:26 2019 authpriv.info ipsec: 14[KNL] using 193.253.160.3 as nexthop and pppoe-wan as dev to reach 90.14.5.x/32
Thu Mar 7 16:44:26 2019 daemon.info ipsec: 14[KNL] using 193.253.160.3 as nexthop and pppoe-wan as dev to reach 90.14.5.x/32
Thu Mar 7 16:44:26 2019 authpriv.info ipsec: 14[IKE] CHILD_SA routeurB-routeurB_lan{2} established with SPIs cfba3032_i c7fb0926_o and TS 192.168.1.0/24 === 192.168.2.0/24
Thu Mar 7 16:44:26 2019 daemon.info ipsec: 14[IKE] CHILD_SA routeurB-routeurB_lan{2} established with SPIs cfba3032_i c7fb0926_o and TS 192.168.1.0/24 === 192.168.2.0/24
Thu Mar 7 16:44:26 2019 authpriv.info ipsec: 14[CHD] CHILD_SA routeurB-routeurB_lan{2} state change: INSTALLING => INSTALLED
Thu Mar 7 16:44:26 2019 daemon.info ipsec: 14[CHD] CHILD_SA routeurB-routeurB_lan{2} state change: INSTALLING => INSTALLED
Problème quand je veux faire un ping j'ai toujours packet filtered du côté routeur A et ça n'a pas l'air de fonctionner côté routeur B (aucun retour).
Les règles de firewall ajoutées sur routeurA censés autoriser le trafic (bien sûr sur routeurB c'est subnet 192.168.2.0/24) :
config rule
option name Allow-IKE-input
option src wan
option proto udp
option dest_port '500 4500'
option target ACCEPT
config rule
option name Allow-ESP-input
option src wan
option proto esp
option target ACCEPT
option extra_src '-m policy --dir in --pol none'
option extra_dest '-m policy --dir out --pol none'
config zone
option name vpn
option input ACCEPT
option output ACCEPT
option forward ACCEPT
option subnet 192.168.1.0/24
option extra_src '-m policy --dir in --pol ipsec --proto esp'
option extra_dest '-m policy --dir out --pol ipsec --proto esp'
option mtu_fix 1
-
J'avais placé
option extra_src '-m policy --dir in --pol none'
option extra_dest '-m policy --dir out --pol none'
au mauvais endroit, il fallait en fait les mettre à chaque fois dans lan et wan et désormais je peux pinger les routeurs réciproquement, on avance :D
Maintenant il reste a résoudre le problème de l'accès à partir du lan puisque un ping à partir de mon PC me revoie un destination unreachebable.
-
Il faut ajouter une route statique sur les 2 routeurs vers le réseau LAN d'en face.
-
C'est bien ce qu'il me semblait. Je test ça en rentrant :)
-
Soit je ne sais plus faire une table de routage, soit il y a un bug...
-routeur A 192.168.1.1/24
-Table : 192.168.2.0/24 gateway 192.168.2.1 sur l'interface lan
-routeur B 192.168.2.1/24
-Table : 192.168.1.0/24 gateway 192.168.1.1 sur l'interface lan
Si c'est bien ça je ne comprends pas pourquoi une fois appliqué ça n’apparaît pas quand je fais un route -n.
-
Montre ta table de routage.
-
Routeur A
root@LEDE:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 193.253.160.3 0.0.0.0 UG 0 0 0 pppoe-wan
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan
193.253.160.3 0.0.0.0 255.255.255.255 UH 0 0 0 pppoe-wan
Routeur B
root@LEDE:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 193.253.160.3 0.0.0.0 UG 0 0 0 pppoe-wan
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan
193.253.160.3 0.0.0.0 255.255.255.255 UH 0 0 0 pppoe-wan
-
En regardant la liste des routes actives, je vois que le subnet d'en face a déjà une gateway prédéfinie sur l'ip du BAS, c'est pas pour ça que ça coince ? Vu que les 2 ont le même métrique...
-
Plus je regarde d'exemples de doc, plus je me mélange les pinceaux... certains font du NAT, d'autres un simple routage...
D'autres encore ont une interface et un subnet pour le tunnel, hors dans mon cas il n'y en a pas. Dans le doute voici l'état du tunnel, peut-être qu'un truc m'échappe.
root@LEDE:~# ipsec status
Routed Connections:
routeurB-routeurB_lan{1}: ROUTED, TUNNEL, reqid 1
routeurB-routeurB_lan{1}: 192.168.1.0/24 === 192.168.2.0/24
Security Associations (1 up, 0 connecting):
routeurB-routeurB_lan[9]: ESTABLISHED 2 hours ago, 90.14.131.x[routeurA]...90.14.5.x[routeurB]
routeurB-routeurB_lan{116}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: cbe3683e_i c0d7716b_o
routeurB-routeurB_lan{116}: 192.168.1.0/24 === 192.168.2.0/24
-
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 : 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 :-\
-
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 : 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+
-
Merci pour ta réponse. J'ai pu créer le VTI d'un côté :) Donc en fait c'est bien pour créer un subnet pour le tunnel. Je ne sais pas pourquoi sur la doc que j'ai lue, ils disaient de renseigner les ip publiques...
Maintenant il faut que j'aille débugger le routeur d'en face, à force de triturer, je me suis encore bloqué l'accès ::) Pour être exact c'est le serveur qui me permet de monter le tunnel SSH que j'ai planté en voulant activer l'ipv6... il n'a pas apprécié le networking restart...
-
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.
-
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+
-
De ce que j'ai compris les VTI servent d'interface pour le routage à l’intérieur du tunnel donc il faut bien des ip privées. Donc mettre les ip WAN à la place je trouve ça bizarre.
Après pour monter le tunnel en lui même oui il faut les ip publiques (normal).
-
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.
-
D'accord... je suis totalement à côté de la plaque. Faut que je relise à tête reposée. A force de passer mes soirées à essayer de faire fonctionner le bouzin, j'ai vraiment du mal à intégrer les choses :P
-
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.