Auteur Sujet: VPN Wireguard entre 2 openWRT  (Lu 2615 fois)

0 Membres et 1 Invité sur ce sujet

renaud07

  • Client Orange adsl
  • *
  • Messages: 1 784
VPN Wireguard entre 2 openWRT
« Réponse #12 le: 04 mars 2019 à 14:24:11 »
Je m'attaque donc au tunnel IPsec. Avant de tout mettre à jour, est-ce bien la config correct pour un tunnel IPsec en PSK ? (Tiré de ce topic https://forum.openwrt.org/t/ipsec-site-to-site-tunnel/17920).


config 'ipsec'
list listen ''
option 'debug' '2'

config 'remote' 'other'
option 'enabled' '1'
option 'gateway' 'FQDN.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'

Et même code de l'autre côté en inversant remote/local subnet, ainsi que le FQDN.

Étant déjà en 18.06 sur un des routeurs, la config est bien générée, par contre sur celui resté en 17.01 ça ne fonctionne pas, j'ai fait boulette d'installer le paquet strongswan-full au lieu de strongswan et j'ai une erreur de script à la fin que je n'arrive pas à éradiquer (même en essayant de désinstaller/réinstaller) à moins que ça ne soit pas lié :
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

Même erreur lorsque je tente de démarrer le service. Je suis bon pour remettre à zéro encore une fois ?

kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 6 161
  • FTTH 1Gb/s sur Paris (75)
VPN Wireguard entre 2 openWRT
« Réponse #13 le: 04 mars 2019 à 14:50:12 »
fait un sujet a part si tu passe en IPsec ?

pour Wireguard,cf https://forum.openwrt.org/t/solved-setup-wireguard-connecting-two-networks/4215 ?

et y'a un tuto la: https://danrl.com/blog/2017/luci-proto-wireguard/ (pas forcement a jour).

renaud07

  • Client Orange adsl
  • *
  • Messages: 1 784
VPN Wireguard entre 2 openWRT
« Réponse #14 le: 04 mars 2019 à 15:38:12 »
Pour wireguard, ce n'est pas la configuration qui pose problème à priori (le tunnel montait bien), mais le fait que ça crash une fois sur 2 quand l'interface démarre. J'ai pas très envie de replanter les routeurs une autre fois... J'ai eu ma dose.

Je vais faire un autre sujet pour IPsec, t'as raison, ça sera plus clair  :)

Nh3xus

  • Réseau Deux Sarres (57)
  • Client K-Net
  • *
  • Messages: 2 532
  • Sarrebourg (57)
VPN Wireguard entre 2 openWRT
« Réponse #15 le: 04 mars 2019 à 18:28:58 »
C'est dommage que Wireguard ne soit pas encore intégré nativement au kernel Linux.

En dehors du manque d'audit de Wireguard, certains devs pensent que ce truc n'a rien à faire dans le noyau.

Je ne sais pas qui a raison.

En tout cas, Linus n'a rien trouvé à redire sur le code source de WG pour le moment.

renaud07

  • Client Orange adsl
  • *
  • Messages: 1 784
VPN Wireguard entre 2 openWRT
« Réponse #16 le: 17 avril 2019 à 00:13:52 »
J'ai décidé de retester wireguard sur des VM debian classique, mais conséquence : il y a du NAT de chaque côté.

Si les interfaces montent bien, je n'ai aucun handshake entre les deux. Pourtant j'ai bien forwardé le 51820 vers chaque serveur...

root@wgvpnlhst:~# wg
interface: wg0
  public key: xxxxxxxOYBAqxMvpK1g8rnCBFuXEpdXkZpnzf2o=
  private key: (hidden)
  listening port: 51820

peer: xxxxxxxWekC8dGl4tfWEqt5SQv5XROvk/2lhndISWc=
  endpoint: 90.14.5.x:51820
  allowed ips: 172.16.0.0/24, 192.168.1.0/24, fd63:13cf:cdb4::/64

root@wgvpnlpa:~# wg
interface: wg0
  public key: xxxxxxxkC8dGl4tfWEqt5SQv5XROvk/2lhndISWc=
  private key: (hidden)
  listening port: 51820

peer: xxxxxxxOYBAqxMvpK1g8rnCBFuXEpdXkZpnzf2o=
  endpoint: 90.14.0.x:51820
  allowed ips: 172.16.0.0/24, 192.168.2.0/24, fd63:13cf:cdb4::/64

# site A
[Interface]
Address = 172.16.0.1/24
PrivateKey = (hide)
ListenPort = 51820

# site B
[Peer]
PublicKey = xxxxxx6HgEnOYBAqxMvpK1g8rnCBFuXEpdXkZpnzf2o=
Endpoint = siteB.dyn.net:51820
AllowedIPs = 172.16.0.0/24, 192.168.2.0/24, fd63:13cf:cdb4::/64
PersistentKeepalive = 15

# site B
[Interface]
Address = 172.16.0.2/24
PrivateKey = (hide)
ListenPort = 51820

# site A
[Peer]
PublicKey =XXXXXXWWekC8dGl4tfWEqt5SQv5XROvk/2lhndISWc=
Endpoint = siteA.dyn.net:51820
AllowedIPs = 172.16.0.0/24, 192.168.1.0/24, fd63:13cf:cdb4::/64
PersistentKeepalive = 15

Une idée ?
« Modifié: 17 avril 2019 à 03:22:46 par renaud07 »

renaud07

  • Client Orange adsl
  • *
  • Messages: 1 784
VPN Wireguard entre 2 openWRT
« Réponse #17 le: 17 avril 2019 à 02:54:22 »
Testé en IPv6 : même résultat...  on pourra pas dire que c'est à cause du NAT, vu qui y'en a pas  :-\

Et oui j'ai bien pensé à ouvrir le port, et les 2 ip sont bien pingables :
« Modifié: 17 avril 2019 à 03:24:53 par renaud07 »

kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 6 161
  • FTTH 1Gb/s sur Paris (75)
VPN Wireguard entre 2 openWRT
« Réponse #18 le: 17 avril 2019 à 07:55:28 »
curieux cela a l'air correct. l'erreur type avec wg c'est l'inversion des public/private keys par exemple ou ouvrir tcp au lieu d'udp ou les valeurs des endpoints.

il faut aussi installer le routage si ce n'est pas  déja fait (ie si on utlise wg-quick ou pas).

sinon capture et recheck config firewall.


renaud07

  • Client Orange adsl
  • *
  • Messages: 1 784
VPN Wireguard entre 2 openWRT
« Réponse #19 le: 17 avril 2019 à 16:16:05 »
Je viens juste de démarrer ma VM et ça marche  :o :
root@wgvpnlpa:~# wg
interface: wg0
  public key: xxxxxxxxxWWekC8dGl4tfWEqt5SQv5XROvk/2lhndISWc=
  private key: (hidden)
  listening port: 51820

peer: xxxxxxxxgEnOYBAqxMvpK1g8rnCBFuXEpdXkZpnzf2o=
  endpoint: 90.14.0.x:51820
  allowed ips: 172.16.0.0/24, 192.168.2.0/24, fd63:13cf:cdb4::/64
  latest handshake: 43 seconds ago
  transfer: 188 B received, 180 B sent
  persistent keepalive: every 15 seconds
root@wgvpnlpa:~# ping 172.16.0.2
PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
64 bytes from 172.16.0.2: icmp_seq=1 ttl=64 time=44.7 ms
64 bytes from 172.16.0.2: icmp_seq=2 ttl=64 time=44.2 ms
64 bytes from 172.16.0.2: icmp_seq=3 ttl=64 time=46.6 ms
64 bytes from 172.16.0.2: icmp_seq=4 ttl=64 time=46.1 ms
64 bytes from 172.16.0.2: icmp_seq=5 ttl=64 time=44.9 ms
64 bytes from 172.16.0.2: icmp_seq=6 ttl=64 time=44.3 ms
64 bytes from 172.16.0.2: icmp_seq=7 ttl=64 time=44.2 ms
64 bytes from 172.16.0.2: icmp_seq=8 ttl=64 time=43.8 ms
64 bytes from 172.16.0.2: icmp_seq=9 ttl=64 time=44.1 ms
^C
--- 172.16.0.2 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8016ms
rtt min/avg/max/mdev = 43.897/44.828/46.625/0.916 ms

root@wgvpnlhst:~# wg
interface: wg0
  public key: xxxxxxxxHgEnOYBAqxMvpK1g8rnCBFuXEpdXkZpnzf2o=
  private key: (hidden)
  listening port: 51820

peer: xxxxxxxxWekC8dGl4tfWEqt5SQv5XROvk/2lhndISWc=
  endpoint: 90.14.5.x:51820
  allowed ips: 172.16.0.0/24, 192.168.1.0/24, fd63:13cf:cda4::/64
  latest handshake: 1 minute, 58 seconds ago
  transfer: 12.20 KiB received, 1.06 MiB sent
  persistent keepalive: every 15 seconds
root@wgvpnlhst:~# ping 172.16.0.1
PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
64 bytes from 172.16.0.1: icmp_seq=1 ttl=64 time=45.4 ms
64 bytes from 172.16.0.1: icmp_seq=2 ttl=64 time=46.2 ms
64 bytes from 172.16.0.1: icmp_seq=3 ttl=64 time=44.7 ms
64 bytes from 172.16.0.1: icmp_seq=4 ttl=64 time=44.3 ms
64 bytes from 172.16.0.1: icmp_seq=5 ttl=64 time=44.2 ms
64 bytes from 172.16.0.1: icmp_seq=6 ttl=64 time=44.2 ms
^C
--- 172.16.0.1 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5008ms
rtt min/avg/max/mdev = 44.293/44.901/46.266/0.772 ms
root@wgvpnlhst:~#

Faudra qu'on m'explique...

kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 6 161
  • FTTH 1Gb/s sur Paris (75)
VPN Wireguard entre 2 openWRT
« Réponse #20 le: 17 avril 2019 à 16:46:23 »
quelques retours avec wireguard:

- on a pas besoin de mettre des IPv4 et/ou IPv6 sur l'interface wg0 elle meme. ca évite d'utiliser un /24 ou un /64 et de compliquer le plan d'adressage. Le mieux est de mettre une IPv6 link-local meme si on fait que de l'IPv4 (je mets juste fe80::X/64 ou X =1 , 2, 3 avec un numero par site facile a retenir). L'avantage d'une link-local est de permettre d'utiliser RIPng en IPv6, associé a DHCPv6-PD pour distribuer les /64 sur les peers wg  ca établie tout seul le routage dynamiquement. L’intérêt de mettre des mettre IPv4 et/ou IPv6 sur l'interface wg0 c'est si la machine est elle meme source/destination de traffic et qu'on veut identifier cette interface dans le firewalling par exemple.

- on n'a pas besoin d'ouvrir et figer le port et les IP des 2 cotés. Un seul coté suffit, l'autre peut être 100% dynamique. Il faut juste mettre un persistent keepalive qui maintienne le NAT. J'ai un site central avec une IP fixe et un port fixe . Tout les autres routeurs Openwrt sont sur des sites distants en double nat derriere une box opérateur sans ip public connues et port a ouvrir.

- si on utilise un fqdn pour l' endpoint comme dans ton exemple:  x.dyn.net:51820 , la résolution dns ne sera qu'une seule fois a l'installation et au reboot. il faut mettre un script a intervalle régulier (cron ou timer systemd) pour éventuellement actualiser l'endpoint (via la commande "wg set wg0 peer ... endpoint ...")

- penser a figer le mtu si la route par défaut est le tunnel wg (enlever 80 au mtu du réseau en dessous).

renaud07

  • Client Orange adsl
  • *
  • Messages: 1 784
VPN Wireguard entre 2 openWRT
« Réponse #21 le: 17 avril 2019 à 16:52:54 »
Merci pour ces précisons. Visiblement c'était un coup de chance puisque j'ai voulu redémarrer la 2nd VM (lhst) et la connexion est de nouveau impossible...

Je ne savais pas pour les endpoint dynamique que ça ne se faisait qu'une seule fois. Du coup je ferais mieux de faire fonctionner en ipv6 direct vu qu'elle est fixe.

Allez hop c'est reparti pour essayer de faire fonctionner ça pour de bon.

renaud07

  • Client Orange adsl
  • *
  • Messages: 1 784
VPN Wireguard entre 2 openWRT
« Réponse #22 le: 17 avril 2019 à 19:09:57 »
Ça ne veut toujours pas fonctionner...

# siteA
[Interface]
Address = fe80::1/64
PrivateKey = (hide)
ListenPort = 51820

# siteB
[Peer]
PublicKey = xxxxxxxxgEnOYBAqxMvpK1g8rnCBFuXEpdXkZpnzf2o=
AllowedIPs = 172.16.0.0/24, 192.168.2.0/24, fd63:13cf:cdb4::/64, fe80::/64
# siteB
[Interface]
Address = fe80::2/64
PrivateKey = (hide)

# siteA
[Peer]
PublicKey = xxxxxxxWWekC8dGl4tfWEqt5SQv5XROvk/2lhndISWc=
Endpoint = 2001:470:1f13:629:x:x:x:x:51820
AllowedIPs = 172.16.0.0/24, 192.168.1.0/24, fd63:13cf:cda4::/64, fe80::/64

root@wgvpnlhst:~# wg
interface: wg0
  public key: xxxxxxgEnOYBAqxMvpK1g8rnCBFuXEpdXkZpnzf2o=
  private key: (hidden)
  listening port: 57031

peer: xxxxxxWekC8dGl4tfWEqt5SQv5XROvk/2lhndISWc=
  endpoint: [2001:470:1f13:629:x:x:x:x]:51820
  allowed ips: 172.16.0.0/24, 192.168.1.0/24, fd63:13cf:cda4::/64, fe80::/64
root@wgvpnlhst:~#
root@wgvpnlpa:~# wg
interface: wg0
  public key: xxxxxxxWWekC8dGl4tfWEqt5SQv5XROvk/2lhndISWc=
  private key: (hidden)
  listening port: 51820

peer: xxxxxxxHgEnOYBAqxMvpK1g8rnCBFuXEpdXkZpnzf2o=
  allowed ips: 172.16.0.0/24, 192.168.2.0/24, fd63:13cf:cdb4::/64, fe80::/64


Et un TCPDUMP sur le routeur ne donne rien, aucun paquet reçu  :(

root@BT-LPA:~# tcpdump -i 6in4-HENET 'port 51820'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 6in4-HENET, link-type RAW (Raw IP), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

renaud07

  • Client Orange adsl
  • *
  • Messages: 1 784
VPN Wireguard entre 2 openWRT
« Réponse #23 le: 17 avril 2019 à 20:54:09 »
Y'a aussi un truc qui me chiffonne :
root@wgvpnlhst:~# ip link add wg0 type wireguard
root@wgvpnlhst:~# wg-quick up wg0
wg-quick: `wg0' already exists

root@wgvpnlhst:~# wg-quick down wg0
[#] ip link delete dev wg0
root@wgvpnlhst:~# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip address add fe80::2/64 dev wg0
[#] ip link set mtu 1200 up dev wg0
[#] ip route add fe80::/64 dev wg0
RTNETLINK answers: No such device
[#] ip link delete dev wg0
root@wgvpnlhst:~#

Pourquoi ce RTNETLINK answers: No such device à chaque fois ? C'est pénible... alors qu'on voit bien qu'il fait un ip link add au début...

Debian se traîne une version buggée ?

C'est seulement quand je tente un démarrage à la main, s'il se lance avec systemd c'est ok apparemment.

 

Mobile View