VPN wireguard site à site et roadwarrior sur pfsense (partie 1)

Environnement

L’article décrit la mise en place d’un système de VPN avec la techno Wireguard en s’appuyant sur des parefeux sous pfsense.
Le but est de relier différents bureaux géographiquement éloignés, connectés au web via des connexions fibre.
Dans l’organisme, certains travailleurs sont nomades ou font du télétravail, le VPN roadwarrior leur permettra de se connecter à l’infrastructure.

Objectif initial, augmenter les débits dans ces tunnels VPN par rapport à OpenVPN qui, quelque soit les optimisations plafonne a 20-25 MB/s. Avec Wireguard, nous atteignons de 40 à 100 MB/s (d’après les tests que nous avons effectué).

Architecture

Ci-dessous le schéma de l’infrastructure :

Le serveur pfsense100 sera le noyau de l’infrastructure VPN. Tous les flux VPN passeront par lui et seront routés à la fois vers les autres sites géographiques, mais aussi vers les clients nomades. Tous les différents ’peers’ de ce VPN seront sur le même tunnel de réseau 10.1.0.0/24 .

Pourquoi cette solution ? Et bien parce qu’elle fonctionne !
En effet dans un premier temps, nous étions parti sur des tunnels wireguard indépendants entre chaque site, d’où un "paquet" de tunnels, et une connexion nomade déjà géré sur le pfsense100 avec openVPN. Seulement, il nous a été impossible de router les flux openvpn vers les tunnels wireguard dans pfsense. Je ne dis pas que c’est infaisable, mais pour notre part pas réussi.
Du coup premier changement, l’abandon total, et cohérent en terme de débit, d’openvpn pour gérer les connexions roadwarrior avec Wireguard sur le pfsense100. Une fois ce changement opéré, toujours impossible de router les flux nomades vers les tunnels site à site. Nous en arrivons donc à la solution décrite dans cet article d’un "mono-tunnet" avec un seul réseau.

Installation WireGuard sur pfsense

Depuis pfsense 2.7, le paquet wireguard est disponible dans le packet manager de la distrib,

• menu System->Package Manager->Available Packages
• chercher ’wireguard’ et lancer l’installation

Que faire si votre ’package manager’ ne fonctionne pas, traduisez il ne vous propose pas de paquets ? Même chose d’ailleurs si le ’system update’ de pfsense ne fonctionne plus. Voici les commandes magiques a lancer dans le terminal du pfsense :
certctl rehash
pkg-static -d update

Premier tunnel entre site ’100’ et ’18’

Sur le Pfsense100

Réglage VPN et interface réseau :

• menu VPN->Wireguard, commençons par activer wireguard dans l’onglet "settings",
  • cocher "enable wireguard"
  • modifier la valeur "Interface group Mambership" à "All tunnels" pour nous permettre de créer une règle globale dans le parefeu pour tous les flux VPN wireguard

    

• onglet tunnel, nous allons créer le tunnel sur ce serveur, bouton "Add tunnel",
  • donner une description à ce tunnel pour bien le repérer, ici nous le nommerons "region" car tous les flux de tous les sites de la région passeront par ce tunnel,
  • choisissez un port, nous allons utiliser le port par défaut,
  • genérer la clef en cliquant sur le bouton "generate", cette clef sera utilisé à plusieurs reprises par la suite,
  • sauvegarder le tunnel et appliquer les modifications,

    

  • remarqez à ce stade qu’il n’y a pas d’interface assignée, ce que nous allons corriger de suite
• Affectation d’une interface réseau, menu Interfaces->Assignements
  • à la dernière ligne de la liste des interfaces, vous trouvez "Available network ports : " avec une liste d’interface disponibles dans laquelle vous sélectionnez "tun_wg0" et cliquez sur le bouton vert "Add",

    

  • la nouvelle interface créée se nomme OPT, cliquer sur ce nom pour la renommer et la paramétrer
  • comme description nous allons mettre "WG_region",
  • au niveau IPV4 configuration, choisir "static IPV4",
  • définir cette adresse dans le champ "IPV4 Address" à ’10.1.0.1’, masque ’/24’,

    

• premier pair (peer) pour le lien avec le pfsense18, retourner dans le menu VPN->wireguard, onglet tunnel. Nous observons que le tunnel a désormais une interface, celle définie précédemment,

  

• en cliquant sur le petit bonhomme, nous ajoutons un peer,
  • cocher la case "enable peer",
  • sélectionnez l’interface dans tunnel : ’tun_wg0 (Region)’,
  • description, notez ’R_vierzon’ pour indiquer que c’est le peer du pfsense18,
  • si ’Dynamic’ est coché, décochez le,
  • Notez dans Endpoint l’adresse IP du pfsense18 (ou à défaut d’IP fixe une valeur de domaine) et valider la valeur par défaut du port 51820,
  • Pour l’instant laisser la clef vide car sa valeur n’est pas encore définie. Il faudra prendre la cle publique du tunnel que nous allons créer par la suite sur le pfsense18,
  • au niveau du pre-shared key, nous alons la générer ici, nous la reporterons par la suite dans la déclaration du peer équivalent sur le pfsense18,
  • dans la partie "address configuration", nous allons indiquer les adresses IP que nous autorisons à passer par ce flux, à savoir en premier l’IP du tunnel en face (que l’on va configurer sur le pfsense18 ensuite), soit ’10.1.0.18/32’ , mais aussi le reseau du LAN derrière le pfsense18, à savoit le ’192.168.18.0/24’,
  • on enregistre le peer et valide les modifications. Il faudra revenir ici pour compléter les éléments qui nous manque à ce stade, à savoir la "public key" du tunnel du pfsense18

    

Pour que tous ces flux passent, il va falloir ajouter quelques règles sur le parefeu, côté WAN, Wireguard et outbound NAT :

• menu Firewall->Rules->onglet Wan,
• ajouter une regle qui autorise le flux UDP sur le port 51820 sur la patte WAN,

  

• deuxième chose, au niveau NAT (Firewall->NAT, onglet outbound), aller vérifier que vous êtes configuré en outbound avec génération de règles automatique. Deux options sont possibles dans la liste pour que çà se fasse :
  • "Automatic outbound NAT rule generation. (IPsec passthrough included)" ,
  • "Hybrid Outbound NAT rule generation.(Automatic Outbound NAT + rules below)"

    

• troisième élément à mettre en place, autoriser les flux qui passent dans le tunnel Wireguard a dialoguer avec les autres réseaux, pour cela menu Firewall->Rules dans l’onglet Wireguard, ajouter une règle qui autorise tout ce qui passe sur les interfaces réseaux de type VPN wireguard à circuler partout, quelque soit le port et le protocole,

  

  

  A noter que nous considérons pour notre part que les droits sont identiques quelque soit le tunnel VPN concerné. Si vous voulez faire des distinctions de droits, il faudra utiliser l’onglet spécifique à votre tunnel, ici visible en tant que "WG_region" pour mettre des règles spécifiques. Ces particularité vous obligeront à modifier le paramétrage de Wireguard (menu VPN->Wireguard, onglet settings) "Interface Group Membership" à "Only assigned Tunnel".

Sur le pfsense18

Nous allons faire ici quasiment les même opérations. Nous allons décrire uniquement les différences de valeur.
Configuration Wireguard et interface réseau

• tunnel :
  • la description peut être différence, on peut mettre ’tunnel100 ’ par exemple,
  • surtout, garder le même port (!),
  • générer une clé public, au passage, copier cette valeur quelque part car nous allons la reporter sur le pfsense100, peer "R_vierzon",
• interface réseau :
  • description, on peut la nommer WG_100,
  • IPV4 : la valeur ici va être 10.1.0.18/24 (comme indiqué dans le schéma initial du réseau),
• peer :
  • description, on peut noter pfsense100,
  • endpoint : indiquer l’IP publique du pfsense100,
  • port garder la même valeur (!),
  • public key : copier ici la public key provenant du pfsense 100, au niveau du tunnel "Region",
  • presharekey : copier ici la preshared key généré sur le pfsense100 au niveau du peer ’R_vierzon’,
  • Allowed IP : indiquez les valeurs suivantes : 10.1.0.1/32 (tunnel pfsense100), 192.168.100.0/24 (Lan derrière le pfsense100), 192.168.45.0/24 (LAN derrière le pfsense45), 10.1.0.0/24 (reseau que l’on servira avec le VPN roadwarrior)
• parefeu : établir exactement les mêmes règles en précisant l’interface réseau ’tunnel100’

Ajustement pfsense 100

Revenez bien sur le pfsense100 pour reporter la public key du tunnel du pfsense18 dans le peer ’R_vierzon’ au niveau de la public key.

Routing

A ce stade, vos connexions VPN wireguard ne doivent pas encore être fonctionnelle. En effet, il manque un élément capital, des règles de routing !
Nous allons commencer sur le pfsense100

• menu System->Routing, onglet Gateway, bouton ajouter
  • interfaces : choisir l’interface reseau WG_region (tunnel VPN de wireguard),
  • en description, mettons GW_R_vierzon (gateway vers le pfsense18 au travers du VPN wireguard),
  • gateway : mettre l’IP du pfsense18 sur le reseau VPN, à savoir 10.1.0.18
  • laisser toutes les autres options par défaut

    

    

    Sur la capture ci-dessus, vous noterez au passage la règle de routing du futur pfsense45.

• définir les routes statiques : en fonction des différents LAN auquels nous souhaitons accéder, nous allons indiquer à la table de routage par où elle doit passer
  • menu System->Routing, onglet "Static routes", bouton ajouter,
  • destination network : 192.168.18.0/24, LAN derrière le pfsense18 que l’on veut atteindre,
  • Gateway : dans la liste choisir "GW_R_vierzon" dont l’IP est 10.1.0.18,
  • description : indiquer LAN vierzon

    

    

    Dans la capture des listes de routes statiques ci-dessus, vous verrez déjà définie la route pour le LAN derrière le pfsense45.

Passons maintenant au pfsense18.

• la Gateway vers le pfsense100 a pour IP cible 10.1.0.1

  

• Et ajout d’une route statique par LAN à accéder, et là nous dirigeons tout les flux quelque soit la cible vers le pfsense100

  

  Notez bien que quelque soit le LAN cible, la route est la même. Et oui, vous avez bien compris, pour passer du pfsense45 au pfsense18, le flux passera par le pfsense100 ! Ce dernier joue le role de noeud d’eguyage.

Verifications

A ce stade votre VPN site à site doit être fonctionnel. Pour verifier :

• allons voir le statut dans le menu VPN-> Wireguard-> statut, derouler la liste des peers avec le bouton devant le tunnel, vous deviez obtenir quelque chose comme la capture ci dessous des 2 côtés

  

• tester des commandes ping depuis chaque LAN vers le LAN opposé,
• tester des commandes traceroute de chaque côté
  root@serveur18:~# traceroute 192.168.100.1
traceroute to 192.168.100.1 (192.168.100.1), 30 hops max, 60 byte packets
1  pfsense18.cen-centrevaldeloire.org (192.168.18.254)  0.858 ms  0.792 ms  0.790 ms
2  10.1.0.1 (10.1.0.1)  11.653 ms  11.512 ms  11.698 ms
3  192.168.100.1 (192.168.100.1)  11.866 ms  11.936 ms  11.662 ms
root@serveur18:~# traceroute 192.168.45.9
traceroute to 192.168.45.9 (192.168.45.9), 30 hops max, 60 byte packets
1  pfsense18.cen-centrevaldeloire.org (192.168.18.254)  0.742 ms  0.696 ms  0.682 ms
2  10.1.0.1 (10.1.0.1)  11.189 ms  11.264 ms  11.115 ms
3  10.1.0.45 (10.1.0.45)  26.208 ms  25.769 ms  25.964 ms
4  192.168.45.9 (192.168.45.9)  26.223 ms  25.658 ms *
  Notez bien dans le traceroute la petite différence de circuit entre un accès juste au LAN derrière le pfsense100 et celui vers un autre LAN, le routage apparaît de façon clair.

VPN roadwarrior

Il nous reste désormais à évoquer la gestion des VPN des postes nomades, dit roadwarrior, pour cela, passez à l’article suivant.