Relier plusieurs sites via VPN avec pfSense (OpenVPN)

OpenVPN S2S multi-sites sur topologie Hub&Spoke.

Dans le monde professionnel, il n’est pas rare que l’on puisse vous demander comment connecter différents sites à un siège principal. Il existe plusieurs méthodes bien-entendu, mais ici nous allons utiliser notre bon vieux pfSense ainsi que la technologie OpenVPN pour réaliser une topologie de type « Hub & Spoke », c’est-à-dire que nous aurons un site central (Paris), et deux sites distants qui seront en mode Clients (New-York, et Bruxelles).

Étant donné qu’une image vaut mieux que mille mots, voici un rapide schéma :

Les deux flèches orange symbolisent la liaison OpenVPN à destination du serveur, le siège central.

Côté réseau, nous aurons donc ceci :

• prs-fw-01 :
  • WAN, 192.168.1.50/24
  • LAN, 192.168.10.1/24

• bxl-fw-01 :
  • WAN, 192.168.1.60/24
  • LAN, 192.168.20.1/24
• ny-fw-01 :
  • WAN, 192.168.1.70/24
  • LAN, 192.168.30.1/24

Classique, mais efficace. A noter qu’ici chaque réseau LAN possède un subnet différent, ce qui est préconisé par OpenVPN (sinon vous allez vous amuser avec le NAT et autre…). Par rapport au réseau utilisé pour le tunnel VPN lui-même, nous opterons pour un 10.0.0.0/27, ce qui nous offrira une trentaine d’hôtes disponibles, de quoi voir aisément venir si cette fameuse société fictive désire s’implémenter sur d’autres sites 😉 

Sans plus tarder, allons-y !

I) Installation des pfSense, et création de la CA

Ayant déjà fait bon nombre d’articles sur l’installation/configuration de base d’un pare-feu/routeur pfSense, je ne vais pas re-détailler tout le processus ici. Sachez simplement que pour le moment, les adresses IP ont juste été setupées, rien de plus.

Bien, désormais, nous allons créer notre CA (Certificate Authority) sur notre firewall de Paris, et ensuite nous allons pouvoir générer deux certificats clients que nous copierons sur celui de Bruxelles et de New-York.

Vous l’aurez compris, ici nous n’allons pas utiliser de simple pre-shared keys, mais bien des certificats. Rassurez-vous, c’est bien moins complexe qu’il n’y paraît !

Donc, pour créer notre CA (ici, elle sera créée directement sur le pfSense, mais sachez que j’ai réalisé un article expliquant comment créer une CA dédiée via easyRsa, disponible juste ici), nous nous rendons dans la partie System puis Cert. Manager et nous cliquons sur Add :

Ensuite, il convient d’ajuster les paramètres à vos besoins, mais globalement on choisi un nom descriptif, on coche éventuellement la case Randomize Serial, le type de clé (je vous conseille ECDSA quand c’est possible, ici la courbe utilisée à savoir prime256v1 est compatible avec OpenVPN donc pas de soucis), puis on renseigne ensuite les paramètres plus classique (CN, Country Code, Province, City…).

Et c’est tout ! Notre CA est désormais fonctionnelle. On pourrait éventuellement créer une CRL (fichier regroupant les différents certificats révoqués), mais ici cela reste un lab donc nous sauterons cette étape.

Vient ensuite la création de certificats pour nos deux sites distants ! Ici nous allons faire ça « proprement », c’est-à-dire que si vous êtes du genre pressé, vous pouvez directement créer les deux certificats clients sur le pfSense principal (Paris ici en l’occurence), et les envoyer aux deux autres, ou bien vous pouvez vous rendre sur les deux autres et créer une CSR (une demande de certificat, pour faire simple), puis importer cette CSR sur le pfSense principal pour les signer et générer les deux certificats.

Bref, rendons-nous donc sur celui de Bruxelles, toujours dans la partie Cert. Manager !

Ici, on remplis donc les champs de manière classique, en choisisant bien le Certificate Type à User certificate en bas de page. Et c’est tout !

Ensuite, dans la partie Certificates, nous avons un bouton permettant d’exporter la requête fraîchement créée :

On exporte le fichier, et on retourne sur Paris, toujours dans la partie Certificates :

Ici, on choisit donc Sign a CSR, on choisi la CA Root qui va signer le certificat (celle créée en début d’article), puis on colle les données CSR dans l’endroit prévu, et c’est tout ! Bien vérifier qu’en bas de page User Certificate soit toujours choisi, et le compte est bon. Au passage, vous verrez sur la droite de la capture d’écran le contenu du fichier CSR.

On valide, et la demande est signée !

Pour ensuite mettre à jour notre demande sur le pare-feux de Bruxelles, il nous faut donc exporter le certificat en cliquant sur l’icône adéquat (à ce stade, nous sommes toujours sur celui de Paris) :

Maintenant, avec ce fichier .crt en poche, on retourne une fois de plus sur celui de Bruxelles pour le mettre à jour. Il nous suffit de cliquer sur « Update CSR » (l’icône en forme de crayon…), toujours dans la partie Certificates, puis de coller le contenu du certificat :

On valide, et le tour est joué ! Notre certificat est bien signé 😀

Bien-entendu, il convient de répéter cette opération pour celui de New-York. L’avant-dernière étape côté certificats est donc de créer un dernier certificat, mais un certificat de type Server cette-fois ci, qui sera donc toujours notre firewall de Paris. Rien de très compliqué en soit, vous commencez à connaître :

Et enfin (promis, on touche au but !) il convient d’exporter le certificat de notre CA Root sur nos deux clients. Pour ce faire, on se rend dans la partie CAs, puis nous cliquons sur le bouton Export certificate :

Ensuite, on clique sur Add sur nos clients et on importe notre certificat, rien de plus facile !

Cette-fois, c’est fini pour de bon côté certificats ! Passons au VPN lui-même…

II) Création du serveur OpenVPN sur prs-fw-01

Toujours sur notre firewall principal, nous allons donc sans surprise dans la partie OpenVPN puis Servers.

Ici, nous rentrons notamment les informations suivantes :

• Server Mode: Peer to Peer SSL/TLS ;
• Local Port: 1194 (mais libre à vous de le changer) ;
• TLS Configuration: Use a TLS Key + Automatically generate a TLS Key
• Peer Certificate Authority: CA-PARIS-01 (notre CA Root générée en début) ;
• Server Certificate: celui créé en dernier, certificat pour le firewall de Paris ;
• ECDH Curve: prime256v1 ;
• Data Encryption Algorithms: valeurs par défaut, à noter que si vous possédez un pare-feu physique sous ARM, restreindre le choix de l’algorithme à CHACHA peut être un bon choix, car les processeurs ARM n’ont pas les jeux d’instructions pour AES ;
• Certificate Depth: One (Client + Server). Nous aurons créé une CA Intermedite (voir un autre de mes articles), nous aurions pu augmenter la profondeur ;
• IPv4 Tunnel Network: 10.0.0.0/27 ;
• IPv4 Local Network: 192.168.10.0/24 ;
• IPv4 Remote Networks: 192.168.20.0/24,192.168.30.0/24 ;
• Custom Options: ici nous pouvons éventuellement rajouter « tls-version-min 1.3 » pour des raisons de sécurité, mais nous n’allons pas le faire ici. Cela peut être cependant très intéressant dans le cadre de VPN client-2-site !

Et c’est tout ! Pas si mal tout de même… on peut donc valider et voilà notre serveur créé.

Passons donc aux clients désormais !

III) Configuration des clients OpenVPN

Commençons par Bruxelles, à noter que ce que nous allons faire ici sera donc à répliqué sur Paris aussi.

Toujours dans la partie OpenVPN, on se rend sur Clients cette-fois ci, puis Add.

Les champs intéressants sont les suivants :

• Server Mode: Peer to Peer (SSL/TLS) ;
• Server Host: 192.168.1.50 ;
• TLS Configuration: Use a TLS Key, + copier/coller la clé TLS créée sur le serveur OpenVPN (sur le firewall de Paris donc) ;
• Peer Certificate Authority: CA-PARIS-01 ;
• Client certificate: CERT-OPENVPN-BXL-FW-01 ;
• IPv4 Tunnel Network: 10.0.0.0/27 ;
• IPv4 Remote Network: 192.168.10.0/24 ;
• Gateway creation: Both (même si nous n’utilisons pas IPv6 ici) ;

Et c’est tout bon ! On peut donc valider, et réaliser le même processus côté New-York.

En redémarrant ensuite le service OpenVPN côté serveur (et éventuellement côté Client), vous devriez obtenir ceci :

Nos deux sites sont bien reliés ! Mais se pose alors une question… au niveau du routage, si un client présent à Paris souhaite communiquer avec New-York ou bien Bruxelles, comment pfSense sait quelle route emprunter ?

C’est ce que nous allons voir ici !

IV) Règles de pare-feux, Client Specific Overrides, et tests finaux

Car oui, la première étape avant toute chose est d’autoriser la communication… donc pour cela, rendez-vous dans Firewall, puis Rules, et enfin OpenVPN :

Ici nous rajoutons une simple règle autorisant tout le trafic, ni plus, ni moins ! Libre à vous de l’adapter bien-entendu.

Ensuite, on peut vérifier si Paris arrive à ping l’interface LAN de Bruxelles et de New-York :

Ce n’est pas le cas… pas de soucis, on va vérifier ça par la suite. Quid de Bruxelles ou New-York à destination du LAN de Paris justement ?

Ah ! Ici, ça fonctionne ! Donc nos clients arrivent à accéder au LAN de notre site principal, mais ce dernier n’arrive pas à accéder à leurs LAN…

Et oui, il faut indiquer à pfSense (ou plutôt, à OpenVPN) quel chemin utiliser pour quel LAN… on se rend donc dans la partie Client Specific Overrides d’OpenVPN, sur notre firewall de Paris.

Ici, il faudra donc rajouter une première configuration pour BXL puis ensuite pour NY. Rien de très sorcier :

On choisi notre serveur OpenVPN (nous n’en avons qu’un), puis on renseigne le CN du certificat utilisateur utilisé par le client distant, avec une éventuellement description (ici j’ai remis le CN mais libre à vous de mettre autre chose).

Plus bas on ré-écrit les paramètres réseaux, càd le network pour le tunnel VPN, le LAN, et enfin le Remote network.

Et c’est tout, à faire de même pour celui de NY en adaptant les valeurs bien-entendu.

Et désormais, si on retente un ping de NY par exemple vers Paris :

Toujours fonctionnel, et maintenant de Paris à NY :

It works désormais ! Vous avez donc votre VPN Site-to-Site sur base de topologie Hub&Spoke ! Pas mal !

Cet article est à présent terminé, j’espère comme d’habitude vous avoir appris quelques bricoles voir plus, et je vous reviens bientôt pour d’autres articles (après une bonne période à bas-régime) ! 😉