Provya

Sécurité et téléphonie

Articles & Tutoriaux  -  Liens & Actualités

[pfSense] Aider la montée en charge (scalabilité) de ses liens OpenVPN

icon 14/04/2020

Dans cet article nous allons voir les bonnes pratiques à connaître et appliquer afin d'accompagner le mieux possible la montée en charge de ses accès OpenVPN.
Le but est d'améliorer le débit et le nombre maximum d'utilisateurs simultanés.

Dans cet article, nous nous concentrons sur les accès OpenVPN. Dans un prochain article, nous nous attaquerons à IPsec.



IPsec est plus rapide

De part son mode de fonctionnement et son implémentation, IPsec offre de meilleures performances qu'OpenVPN.
Aussi, une solution (radicale ?), pour accroître la capacité de vos liens VPN est de basculer d'OpenVPN vers IPsec.

IPsec peut être utilisé aussi bien pour établir un lien VPN entre deux sites distants, que pour des utilisateurs nomades. Quoique nous ne recommandions pas IPsec pour les utilisateurs distants (OpenVPN est bien plus pratique et facile à mettre en œuvre et passe bien mieux les problématiques de NAT ou CGN).

Notre recommandation est d'utiliser IPsec pour les liens VPN en mode site-à-site, et d'utiliser OpenVPN pour les accès utilisateurs distants.



Utiliser UDP

Lors de la configuration d'OpenVPN, vous avez le choix du protocole de transport TCP ou UDP.
De par son mode de fonctionnement (transmission sans connexion, contrairement à TCP), UDP sera plus efficace et plus rapide.

Ainsi, il vaut donc mieux conserver UDP qui est le protocole par défaut.



Utiliser TLS uniquement pour l'authentification

OpenVPN peut utiliser le protocole TLS aussi bien pour l'authentification que pour le chiffrement du Control Channel (c'est-à-dire le canal de communication établi entre le serveur et le client OpenVPN).
Il est possible d'utiliser TLS uniquement pour l'authentification. Il s'agit d'ailleurs de la configuration par défaut proposée sous pfSense.

TLS pour l'authentification OpenVPN sous pfSense - Provya


Dans tous les cas, le trafic VPN sera chiffré.



Utiliser l'accélération cryptographique

De plus en plus de firewall sont pourvu d'une puce d'accélération cryptographique (AES-NI). La différence de performance pour les liens VPN entre les firewall supportant l'AES-NI et les autres est véritablement importante, d'environ un facteur 10, voire davantage.

Si votre firewall le supporte, il faut activer l'accélération cryptographique AES-NI et BSD Cryptodev depuis le menu System > Advanced ; onglet Miscellanous :

Menu System > Advanced > Miscellaneous - pfSense - Provya


Pour l'option "Cryptographic Hardware", choisir "AES-NI and BSD Crypto Device (aesni, cryptodev)" et penser à valider le changement en cliquant sur le bouton "Save" en bas de page :

Activer l'accélération cryptographique sous pfSense - Provya


Il faut ensuite configurer votre VPN avec un algorithme de chiffrement compatible avec l'accélération cryptographique AES-NI, comme par exemple AES-GCM ou AES-CBC.



Utiliser AES-GCM

L'utilisation d'un chiffrement efficace comme les codes AEAD (authenticated encryption with associated data), qui combinent chiffrement et authentification, permet d'accroître la sécurité et les performances.
Aussi bien IPsec, qu'OpenVPN peuvent utiliser AES-GCM, qui est un code AEAD. En revanche, le support côté client peut varier selon la plate-forme.

C'est pourquoi pour les accès OpenVPN pour les utilisateurs distants, il est conseillé de proposer en priorité AES-GCM, tout en autorisant la négociation des paramètres cryptographiques (NCP - Negotiable Cryptographic Parameters) si besoin.

D'un point de vue configuration de votre serveur OpenVPN, la configuration ressemblera à cela :

  • Encryption Algorithm : choisir AES-GCM
  • Enable NCP : cocher la case Enable Negotiable Cryptographic Parameters
  • NCP Algorithms : choisir AES-GCM (à placer en premier) ainsi que les autres algorithmes que vous souhaitez activer

Utiliser AES-GCM pour OpenVPN sous pfSense - Provya




Réduire le chiffrement au strict minimum

Pour la configuration des liens VPN, nous recommandons généralement d'opter pour de l'AES-256 ou supérieur. Cependant, dans le cas d'une forte activité ou si vous constatez des lenteurs, il est possible de diminuer le niveau de chiffrement et par conséquent le niveau de sécurité au pallier inférieur. Le strict minimum aujourd'hui est l'utilisation d'une clef de 128 bits.

Dans son Référentiel Général de Sécurité (RGS), l'ANSSI recommande l'utilisation de clés symétriques d'une taille d'au moins 128 bits.



Désactiver la compression

Il peut être tentant d'activer la compression sur les liens à faible débit. En réalité, c'est inefficace et non-sécurisé.

Aujourd'hui, la plupart des données qui transitent via les liens VPN est déjà chiffrée ou incompressible. Aussi, activer la compression sur le lien OpenVPN va juste gaspiller du CPU, sans réellement réduire la consommation de bande-passante.
De plus, la compression utilisée par OpenVPN est sensible à des attaques telles que VORACLE (EN).

Aussi, côté serveur OpenVPN, il faut conserver la compression désactivée dans tous les cas. Il s'agit du choix par défaut sur pfSense.
Le paramètre Compression doit rester à Disable Compression :

Désactiver la compression LZO sur les liens OpenVPN sous pfSense - Provya




Utiliser plusieurs serveurs OpenVPN

OpenVPN ne supporte pas le multithreading. Aussi, si votre serveur dispose de plusieurs CPU, un seul sera utilisé par votre serveur OpenVPN.
Ainsi, si le CPU est le facteur limitant, une bonne solution de contournement consiste à configurer plusieurs serveur OpenVPN.

Deux approches sont possibles :

  • Répartir de manière fixe la charge sur plusieurs serveurs OpenVPN : certains clients auront accès à un serveur OpenVPN, d'autres à un autre serveur. Il s'agit de la solution la plus simple et rapide à mettre en œuvre (mais pas nécessairement la meilleure).
  • Répartir la charge aléatoirement sur les plusieurs serveurs OpenVPN : pour cela, il faut que la configuration soit la même pour les deux serveurs OpenVPN (même CA, mêmes paramètres de chiffrement, etc.), mais avec un sous-réseau différent pour chacun. Puis, il faut ajouter le paramètre remote-random dans la configuration du client afin qu'il se connecte de manière aléatoire sur l'un des serveurs OpenVPN configurés. Il s'agit de la solution optimale d'un point de vue scalabilité.

Attention, en démultipliant le nombre de serveurs OpenVPN en fonctionnement sur un même serveur pfSense, on augmente forcément la consommation de mémoire-vive.



Réduire le MSS

Il est possible que vous rencontriez des lenteurs importantes pour des accès via VPN à des partages de fichiers Windows ou à des sites web (ou d'une façon générale à des services utilisant TCP). Dans ce cas, il peut être très utile de réduire le MSS (Maximum Segment Size).

Ce paramètre se définit en ajoutant le code suivant dans le champ "Custom Options" de votre serveur OpenVPN :
mssfix 1400

Régler MSS MTU d'OpenVPN sous pfSense - Provya


Notre recommandation est de démarrer avec une valeur à 1400, puis, si ça fonctionne, l'augmenter progressivement jusqu'à ce que les problèmes réapparaissent. Une fois atteint le point de dysfonctionnement, il suffit de réduire de nouveau très légèrement la valeur du MSS.


Nous avons fait le tour des recommandations de configuration pour l'optimisation de ses accès OpenVPN. D'autres réglages sont également possibles et peuvent permettre, suivant les cas, d'aider à la montée en charge de son VPN, mais ces réglages sont souvent expérimentaux et générateurs de bugs ou entraînent de grosses lacunes de sécurité ; c'est la raison pour laquelle nous ne les présentons pas ici.



Pour aller plus loin

[pfSense] Sécurisez l'accès distant de vos collaborateurs nomades avec OpenVPN
[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Configurer un VPN IPsec site à site
[pfSense] Les pannes courantes et leurs solutions sur un VPN IPsec


Vous avez aimé cet article ? Vous cherchez du matériel ou un support professionnel ? Alors contactez-nous.


Découvrez nos firewall SSD pour pfSense, assemblés en France, compatibles AES-NI


           

store.provya.fr

icon Tags de l'article :

2 commentaires

Eric - 26/04/2020 à 13:11:57

Bravo pour votre travail très complet et clair.
Ayant passé un BTS réseaux, nous avons galéré comme pas permis à l'école avec pfsense.
tellement peu d'explications et voués à nous même !! dommage qu'on ait pas eu ça à l'époque.

@répondre #lien

Guillaume - 27/04/2020 à 14:59:20

@Eric :
Bonjour Eric,

Merci pour votre sympathique commentaire.

Cordialement,

Guillaume
--
Provya

@répondre #lien

icon Flux RSS des commentaires de cet article