Une fonctionnalité pratique de pfSense, mais très méconnue, est la possibilité de définir des règles de filtrage qui seront appliquées en fonction de la date, du jour ou de l'heure.
On peut imaginer l'utilité pour ouvrir des accès temporaires le temps de mises à jour planifiées, pour différencier les horaires d'accès à Internet pour un usage professionnel / personnel ou encore pour un événement éphémère.
Ces règles de filtrage sont présentes avec les autres règles, mais elles seront actives uniquement sur les créneaux horaires définis. Le reste du temps, elles seront simplement ignorées par pfSense.
Configurer un calendrier
La première étape consiste à configurer un calendrier. Cela se passe dans le menu Firewall > Schedules :
Cliquer sur le bouton "+ Add".
Les champs à compléter sont les suivants :
- Schedule Name : le nom de votre "calendrier", sans espace ni caractères spéciaux.
- Description : champ purement informatif.
- Month : le mois et l'année applicable ; on ne peut sélectionner qu'un seul mois à la fois.
- Date : les jours où la condition horaire sera appliquée. Pour sélectionner chaque jour individuellement, il suffit de cliquer sur la case correspondante. Un jour sélectionné sera sur fond vert. Il est également possible de sélectionner toutes les occurrences d'un jour donné (par exemple tous les samedis) ; pour cela, on peut cliquer directement sur l'entête de colonne correspondant (Sat dans notre exemple du samedi). Les jours sélectionnés seront sur fond bleu.
- Time : l'horaire de début et de fin (se configure par tranche de quinze minutes)
Par exemple, si nous souhaitons sélectionner tous les samedis du mois de mai 2020 sur le créneau 12h - 14h, le résultat ressemblera à ceci :
Une fois notre configuration réalisée, il faut la valider en cliquant sur le bouton "+Add Time".
Cela permet également d'ajouter d'autres dates et d'autres créneaux horaires à notre calendrier.
Enfin, il reste à cliquer sur le bouton "Save" pour sauvegarder notre calendrier.
Appliquer le calendrier à une règle de filtrage
La création, ou la modification, d'une règle de filtrage s'effectue depuis le menu Firewall > Rules :
Une fois sur votre règle de filtrage, il faut se rendre dans les options avancées (Section "Extra Options", cliquer sur le bouton "Display Advanced" :
Puis pour le champ Schedule, choisir le calendrier créé précédemment :
Exemple de résultat obtenu :
Le pictogramme jaune indique que la règle n'est actuellement pas active ; c'est le cas de la première règle avec le calendrier "samedi_provya".
Le pictogramme vert indique que la règle est actuellement active ; c'est le cas de la seconde règle avec le calendrier "vendredi_provya".
Dernier élément pour conclure ce court article : par défaut les états sont réinitialisés dès l'expiration du calendrier.
Cela signifie que l'accès est immédiatement coupé y compris pour les sessions actives.
Si l'on souhaite conserver les sessions actives jusqu'à leur expiration, il faut cocher la case "Do not kill connections when schedule expires" accessible depuis System > Advanced, onglet "Miscellaneous".
Pour aller plus loin
Best practices / Recommandations pour la configuration de votre firewall
[pfSense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense
[pfSense] Troubleshooting / Dépannage de ses règles de filtrage
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez du matériel de qualité ? Alors contactez-nous.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : pfSense
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.
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 :
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 :
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
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 :
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
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
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez du matériel ou un support professionnel ? Alors contactez-nous.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : openVPNpfSense
English version: pfSense 2.4.5 now available
Jeudi 26 mars 2020 est sortie la dernière version de pfSense. La version 2.4.5.
Cette mise à jour comporte des correctifs de sécurité, plusieurs nouvelles fonctionnalités et des correctifs de stabilité.
Dans cet article, nous faisons le tour des éléments marquants de cette mise à jour.
Nouvelles fonctionnalités
Les nouvelles fonctionnalités majeures sont les suivantes :
- Le système d'exploitation est mis à jour vers FreeBSD 11.3 ;
- Ajout de la possibilité de faire des recherches et des filtres sur plusieurs pages, dont notamment, la page de gestion des certificats (System > Cert. Manager), la page de visualisation des baux DHCP (Status > DHCP Leases), la page de visualisation de la table ARP (Diagnostics > ARP Table) ;
- Ajout des groupes DH et PFS 25, 26, 27 et 31 pour les VPN ;
- Modification de la configuration par défaut du système de fichiers UFS à noatime pour les nouvelles installations (ce paramètre n'est pas appliqué si vous faites une mise à jour de votre pfSense). Cela permet de réduire les écritures inutiles sur le disque ;
- Ajout du paramètre autocomplete=new-password sur les formulaires de l'interface web contenant des champs d'authentification. Cela évite une auto-complétion par le navigateur ;
- Ajout de Gandi et Linode dans la gestion des DNS dynamique (Services > Dynamic DNS).
Sécurité
Les mises à jour de sécurité majeures sont les suivantes :
- Renforcement contre les attaques de type cross-site scripting (XSS) sur plusieurs pages de l'interface web ;
- Résolution d'un problème d'escalade de privilège : un utilisateur authentifié, qui était autorisé à accéder au widget d'image pouvait exécuter un code PHP arbitraire ou accéder à des pages pour lesquelles il n'avait normalement pas les droits ;
- Correction du format des messages d'échec d'authentification XMLRPC (servant pour la réplication sur une installation avec deux pfSense en cluster) afin que ces messages puissent être traités par sshguard ;
- Mise à jour de la page d'erreur CSRF (Cross-site request forgery).
Bugs
Plusieurs bugs importants ont également été corrigés. C'est une très bonne chose.
Les bugs en question sont les suivants :
- La durée de vie par défaut du certificat de l'interface web a été réduite à 398 jours. Ce qui est beaucoup plus conforme aux standards actuels. Un certificat avec une durée de vie trop longue entraînait des erreurs sur un certain nombre de plateformes (principalement iOS 13 et macOS 10.15). Si vous êtes sur une mise à jour et non pas sur une nouvelle installation, vous pouvez générer un nouveau certificat à partir de la console ou en SSH avec la commande : pfSsh.php playback generateguicert ;
- Corrections de plusieurs bugs sur les IPsec VTI (IPsec routé) ;
- Correction de plusieurs bugs d'affichage avec la gestion des vues personnalisées sur la page de supervision (Status > Monitoring) ;
- Correction du bug de redirection pour les utilisateurs (autre que le compte admin) qui étaient redirigés vers une mauvaise page lorsqu'ils souhaitaient accéder à la page de gestion des utilisateurs (System > User Manager) ;
- Correction d'un problème lors de la résolution des entrées FQDN dans les alias où certaines entrées pouvaient être manquantes.
Processus de mise à jour
En raison de la nature importante des changements dans cette mise à jour, des alertes ou des erreurs peuvent être affichées durant le process de mise à jour. Il ne faut pas spécialement en tenir compte. Notamment si vous voyez des erreurs concernant PHP ou la mise à jour de packages.
En conséquence, seules les erreurs qui persistent après la mise à jour sont significatives.
Dans tous les cas, pensez à faire une sauvegarde avant de lancer la mise à jour, et suivez notre tuto complet : [pfSense] Mettre à jour son serveur pfSense.
Enfin, vous pouvez consulter la liste complète des changements en visitant la page suivante : 2.4.5 New Features and Changes[EN]
Avertissement : Hyper-V
Attention, un bug a été rapporté pour les installations pfSense 2.4.5 fonctionnant sous Hyper-V (versions 2016 ou 2019). Il y a un emballement du CPU dès que plus de 2 CPU sont attribués à la VM faisant tourner pfSense.
Une solution de contournement consiste à réduire à un le nombre de CPU virtuel alloué à la VM.
Merci à @Hello qui a signalé ce problème en commentaire.
Mise à jour : l'origine du problème a été trouvé. Un bug a été ouvert : pf: tables use non SMP-friendly counters. Le bug apparaît lorsqu'un grande table est rechargée (la liste des bogons, par exemple) ; aussi une possible solution de contournement est de décocher la case "Block bogon networks" sur toutes les interfaces.
Pour aller plus loin
[pfSense] Mettre à jour son serveur pfSense
[pfSense] Configurer un cluster de 2 pfSense redondants (failover)
[pfSense] Tout comprendre aux alias
Best practices / Recommandations pour la configuration de votre firewall
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez du matériel ou un support professionnel ? Alors contactez-nous.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : mise à jour pfSensepfSense
Savoir lire les logs de pfSense concernant IPsec peut être difficile.
Nous donnons dans cet article les clefs pour comprendre les logs IPsec et identifier les erreurs de configuration associées.
Après notre article sur comment configurer un VPN IPsec sous pfSense, notre article sur les causes de défaillances généralement rencontrées sur un VPN IPsec et leurs solutions les plus probables, nous abordons dans cet article la gestion des logs d'IPsec sous pfSense et la signification des messages pouvant être rencontrés dans ces fichiers de journalisation.
Configurer les logs IPsec
Les logs pour les VPN IPsec peuvent être configurés pour apporter des informations utiles pour le debogage. Pour effectuer cette configuration, se rendre dans le menu VPN > IPsec, puis onglet Advanced :
Au sein de la rubrique "IPsec Logging Controls", configurer les options avec les valeurs suivantes :
- IKE SA : Diag
- IKE Child SA : Diag
- Configuration Backend : Diag
- Autres options : Control
Exemple de résultat obtenu :
Il est à noter que modifier ces options ne coupera pas le VPN IPsec.
Interpréter les logs IPsec liés à la phase 1
Les logs des VPN IPsec sont accessibles depuis le menu Status > System Logs, onglet IPsec :
Nous allons parcourir les messages que l'on peut rencontrer le plus couramment dans les logs.
La bonne manière de procéder, pour analyser les logs, consiste à rechercher les expressions clés indiquant quelles étapes fonctionnent ou, au contraire, échouent. Cela permet d'orienter très pécisément le diagnostique.
Par exemple, si l'on voit dans les logs "IKE_SA ... established", cela signifie que la phase 1 s'est déroulée avec succès et qu'une SA (Security Association) a été négociée. Ce qui signifie que les deux firewall établissant le tunnel IPsec arrivent à échanger de manière sécurisée.
Si l'on voit "CHILD_SA ... established", alors cela signifie qu'une phase 2 s'est déroulée avec succès également. Le tunnel doit être UP (en tout cas, pour au moins l'une des phases 2 ; dit autrement, pour au moins un sous-réseau local et un sous-réseau distant).
Connexions réussies
Lorsqu'un tunnel est correctement monté, les deux firewall doivent disposer dans leurs logs respectifs d'informations indiquant qu'un IKE SA et un Child SA ont été montés avec succès.
Quand il y a plusieurs phases 2, on doit visualiser un "CHILD_SA ... established" pour chacune d'entre elles.
Exemple de log d'un tunnel monté avec succès :
On voit sur cette capture d'écran que la phase 1 a été négociée avec succès (IKE_SA con2000[11] established) entre le firewall possédant l'adresse IP 192.0.2.90 et celui possédant l'adresse IP 192.0.2.74).
Puis, on voit qu'une phase 2 a été négociée avec succès (CHILD_SA con2000{2} established) permettant aux sous-réseaux 192.168.48.0/24 d'un côté et 10.42.42.0/24 de l'autre d'échanger entre eux.
Connexions échouées
Les exemples suivants montrent plusieurs cas de connexions IPsec échouées.
Un point important à avoir en tête est que dans la plupart des cas, le firewall initiant la connexion IPsec (initiateur) aura peu d'informations pertinentes dans ses logs (on ne saura pas précisément la raison de l'échec de la connexion) ; tandis que le firewall répondant à la demande de connexion IPsec (répondant) aura des informations beaucoup plus précises et détaillées. C'est normal. Il s'agit là d'un élément de sécurité : il serait en effet peu sûr de fournir à un attaquant potentiel trop d'informations sur la configuration du VPN.
Phase 1 - Écart de configuration Main / Aggressive
Dans cet exemple, l'initiateur est configuré en mode "Aggressive", tandis que le répondant est configuré en mode "Main".
Extrait des logs pour l'initiateur :
On lit bien dans les logs que la négociation de la phase 1 se fait en mode "Aggressive" et que l'authentification a échoué (AUTHENTICATION FAILED). Mais l'on ne connaît pas la raison de cet échec.
Extrait des logs pour le répondant :
On lit dans les logs que la négociation de la phase 1 a échoué et que la raison de cet échec est que le mode "Aggressive" n'est pas autorisé. Les logs sont bien plus explicites.
Phase 1 - Erreur d'identifiant
Lorsque l'identifiant ne correspond pas (pour rappel, l'identifiant est généralement configuré pour être l'adresse IP publique du firewall), l'initiateur montre seulement que l'authentification a échoué. Le répondant précise la raison de cet échec.
Extrait des logs pour l'initiateur :
On peut voir que l'erreur retournée est la même que dans le cas précédent : il s'agit d'une erreur d'authentification standard.
Extrait des logs pour le répondant :
Les logs sont beaucoup plus explicites : "no peer config found" ; l'identifiant correspondant à la requête n'a pas été trouvé.
Phase 1 - Erreur sur la Pre-Shared Key
Une erreur sur la PSK peut être difficile à diagnostiquer. En effet, on ne trouvera pas de message explicite dans les logs indiquant qu'il y a une erreur sur la Pre-Shared Key.
Les logs, aussi bien côté initiateur que répondant, ressembleront à ceci :
Si vous voyez ces messages apparaître dans vos logs IPsec, un conseil : vérifiez la valeur de votre Pre-Shared Key sur chaque firewall établissant le VPN IPsec.
Phase 1 - Écart sur le choix de l'algorithme de chiffrement ou de hachage
Extrait des logs pour l'initiateur :
Extrait des logs pour le répondant :
Les messages sont très explicites et indiquent le problème exact. Ici, l'initiateur était configuré avec de l'AES-128 et le répondant avec de l'AES-256.
Il est à noter que la portion de message "MODP" correspond au groupe Diffie-Hellman (DH group). Ici, on voit que les deux firewall ont bien la même configuration de groupe Diffie-Hellman "MODP_1024".
S'il y avait eu un écart, nous aurions eu deux valeurs différentes, comme par exemple MODP_1024 d'un côté et MODP_8192 de l'autre.
Enfin, la portion "HMAC" correspond à l'algorithme de hachage. Ici, la valeur est HMAC_SHA1_96. Encore une fois, s'il y a un écart entre les deux, il faut alors corriger.
Interpréter les logs IPsec liés à la phase 2
Phase 2 - Erreur sur la configuration des sous-réseaux
Dans l'exemple ci-dessous, la phase 2 du firewall initiateur est configurée avec le sous-réseau 10.3.0.0/24 vers le 10.5.0.0/24. Tandis que le firewall répondant est configuré avec 10.5.1.0/24 pour son côté.
Extrait des logs pour l'initiateur :
Extrait des logs pour le répondant :
Dans les logs du répondant, on peut visualiser les sous-réseaux présents dans la négociation de la phase 2 (ligne "looking for a child config for ...") et les sous-réseaux présents dans sa configuration locale (lignes "proposing traffic selectors for ...").
En comparant les deux, une erreur peut être détectée.
Enfin, la mention "no matching CHILD_SA config found" sera toujours présente dans les logs lorsqu'il y aura une erreur de configuration de ce type. Ce message signifie que pfSense n'a pas pu trouver de phase 2 correspondant à la requête du firewall initiateur.
Phase 2 - Écart sur le choix de l'algorithme de chiffrement ou de hachage
Extrait des logs pour l'initiateur :
Extrait des logs pour le répondant :
Dans ce cas, l'initiateur reçoit un message indiquant que le répondant n'a pas pu trouver de proposition correspondant à la demande (ligne "received NO_PROPOSAL_CHOSEN").
Côté répondant, les logs sont plus détaillés et précisent la proposition reçue (ligne received proposals) et la proposition configurée localement (ligne configured proposals).
Dans l'exemple ci-dessus, sur les extraits de logs, on voit que c'est l'algorithme de chiffrement qui est différent (AES_CBC_128 dans un cas et AES_CBC_256 dans l'autre).
La portion "HMAC" correspond à l'algorithme de hachage. Ici, la valeur est HMAC_SHA1_96. Encore une fois, s'il y a un écart entre les deux, il faut alors corriger.
Voilà ! Nous avons fait le tour des messages de logs les plus courants pour les VPN IPsec sous pfSense.
Pour aller plus loin
[pfSense] Configurer un VPN IPsec site à site
[pfSense] Les pannes courantes et leurs solutions sur un VPN IPsec
[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Troubleshooting / Dépannage de ses règles de filtrage
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez du matériel ou un support professionnel ? Alors contactez-nous.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : IPsecpfSenseVPN
English version: [pfSense] Configuring a Site-to-Site IPsec VPN
Dans cet article nous traitons de la configuration d'un VPN IPsec entre deux firewall.
La configuration porte sur un firewall pfSense, mais les grandes lignes de configuration sont applicables à tous les équipements du marché supportant IPsec.
1/4. Schéma de mise en œuvre
Nous suivrons la configuration présentée sur le schéma suivant :
Pour le site A :
- Adresse IP publique : 1.1.1.1
- Réseau local : 192.168.50.0/24
Pour le site B :
- Adresse IP publique : 2.2.2.2
- Réseaux locaux : 192.168.10.0/24 et 192.168.20.0/24
Nous présenterons la configuration pour le site A uniquement. La configuration pour le site B étant facilement déductible à partir de celle du site A.
2/4. Configuration de la Phase 1
Se rendre dans le menu VPN > IPsec
Cliquer sur le bouton "+ Add P1". Les éléments à configurer sont les suivants :
- Disabled : cocher cette case permet de désactiver la phase 1 du VPN IPsec (et donc de désactiver le VPN IPsec)
- Key Exchange version : permet de choisir la version du protocole IKE (Internet Key Exchange). Nous choisissons "IKEv2". Si l'autre pair ne support par l'IKEv2 ou si un doute subsiste, il est recommandé de choisir "Auto".
- Internet Protocol : IPv4 ou IPv6 ; dans notre cas, nous choisissons IPv4
- Interface : l'interface sur laquelle nous souhaitons monter notre tunnel VPN IPsec. Nous choisissons WAN
- Remote Gateway : l'adresse IP publique du site distant. Dans notre cas : 2.2.2.2
- Description : champ facultatif de commentaire (mais que nous conseillons de remplir pour une meilleure lisibilité)
- Authentication Method : la méthode d'authentification des deux pairs. Deux choix sont possibles : authentification par clé pré-partagée (PSK) ou par certificat (RSA). Le plus simple et le plus courant est de choisir "Mutual PSK" ; ce que nous faisons.
- My identifier : notre identifiant unique. Par défaut, il s'agit de l'adresse IP publique. Nous laissons donc la valeur "My IP address".
- Peer identifier : l'identifiant unique de l'autre pair. Par défaut, il s'agit de son adresse IP publique. Nous laissons la valeur "Peer IP address"
- Pre-Shared Key : la clé pré-partagée. Nous laissons pfSense la générer et cliquons pour cela sur "Generate new Pre-Shared Key". Cette clé pré-partagée devra être saisie sur l'autre firewall lors de sa configuration.
- Encryption Algorithm : l'algorithme de chiffrement. Si les deux parties supportent l'AES-GCM, nous recommandons l'utilisation d'AES256-GCM ou d'AES128GCM ; ce qui permettra de bénéficier d'un bon niveau de chiffrement et sera compatible avec l'accélération cryptographique offert par AES-NI. Autrement, choisir AES avec une longueur de clé de 256 bits dans l'idéal. Enfin, nous conservons SHA256 pour fonction de hachage et 14 ou 16 pour la valeur du groupe Diffie-Hellman (DH group - utilisé pour l'échange de clés).
- Lifetime (Seconds) : permet de définir la fréquence de renouvellement de la connexion. La valeur par défaut, 28800 secondes, reste un bon choix
- Advanced Options : nous laissons les valeurs par défaut
Exemple de résultat obtenu :
Nous cliquons sur le bouton "Save" pour enregistrer les changements.
3/4. Configuration des Phases 2
Sur la page des tunnels VPN IPsec (sur laquelle vous devez être actuellement), pour notre entrée P1 que nous venons de créer, nous cliquons successivement sur les boutons "Show Phase 2 Entries (0)", puis sur "+ Add P2".
Les éléments à configurer sont les suivants :
- Disabled : cocher cette case permet de désactiver cette phase 2 du VPN IPsec
- Mode : nous laissons le mode par défaut "Tunnel IPv4"
- Local Network : le réseau-local joignable par l'hôte distant sur ce VPN IPsec. Dans notre cas, nous choisissons "LAN subnet".
- NAT/BINAT translation : si l'on souhaite configurer du NAT sur le tunnel IPsec. Ceci peut être très utile si le plan d'adressage est le même sur les deux sites distants que nous souhaitons interconnecter. Ce n'est pas notre cas dans notre exemple. Nous laissons donc la valeur à "None".
- Remote Network : l'adresse IP ou le sous-réseau du site distant. Dans notre cas, nous renseignons ici le premier sous-réseau, soit 192.168.10.0/24 ; puis nous créerons une seconde phase 2 en précisant cette fois le second sous-réseau du site distant (192.168.20.0/24).
- Description : champ facultatif de commentaire (mais que nous conseillons de remplir pour une meilleure lisibilité)
- Protocol : nous choisissons ESP. AH est rarement utilisé en pratique. Techniquement, le protocole ESP permet de chiffrer l'intégralité des paquets échangés, tandis qu'AH ne travaille que sur l'entête du paque IP sans offrir la confidentialité des données échangées.
- Encryption Algorithms : Algorithmes de chiffrement. Comme pour la phase 1, si les deux parties supportent l'AES-GCM, nous recommandons l'utilisation d'AES256-GCM ou d'AES128GCM ; ce qui permettra de bénéficier d'un bon niveau de chiffrement et sera compatible avec l'accélération cryptographique offert par AES-NI. Autrement, choisir AES avec une longueur de clé de 256 bits dans l'idéal. Enfin, nous conservons SHA256 pour fonction de hachage et 14 ou 16 pour la valeur du groupe Diffie-Hellman (PFS key group).
- Lifetime : nous laissons la valeur par défaut, soit 3600 secondes
- Automatically ping host : une adresse IP à pinguer sur le site distant afin de conserver le tunnel actif. Ce peut être l'adresse IP du firewall sur le site distant par exemple ; nous indiquons 192.168.10.1 dans notre cas.
Exemple de résultat obtenu :
Nous cliquons sur le bouton "Save" pour sauvegarder notre configuration. Puis nous créeons une nouvelle phase 2 en indiquant cette fois, pour le champ "Remote Network", le second sous-réseau du site B (LAN 2 : 192.168.20.0/24) et choisissons, bien sûr, une adresse IP dans ce sous-réseau pour le champ "Automatically ping host".
Une fois ces configurations effectuées, nous obtenons le résultat suivant :
Il ne nous reste plus qu'à cliquer sur le bouton "Apply Changes" pour appliquer nos configurations.
À ce stade, le VPN IPsec doit être monté. Il ne nous reste plus qu'à configurer nos règle de filtrage afin d'autoriser le trafic.
4/4. Règles de filtrage
Il y a au moins deux règles de filtrage à implémenter : celles autorisant le trafic depuis le LAN vers les réseaux du site distant ; et celles autorisant le trafic depuis les deux sous-réseaux du site distant vers le LAN.
Soit, pour l'interface LAN, voici un exemple de règles :
Et pour l'interface IPsec, voici un exemple de règles :
Ces règles sont, en l'état, très permissives. Nous vous recommandons de les affiner afin qu'elles apportent une meilleure sécurité et qu'elles soient en conformité avec votre politique de filtrage.
Dernier élément, si vous avez modifié les options avancées accessibles depuis le menu System > Advanced, onglet Firewall/NAT et que vous avez coché la case "Disable all auto-added VPN rules", alors vous devrez créer des règles de filtrage sur l'interface WAN afin d'autoriser le trafic IPsec avec l'hôte distant. IPsec utilise les ports UDP 500 et 4500, ainsi que le protocole ESP (ou AH, le cas échéant).
La configuration est terminée et doit être fonctionnelle. Pour visualiser les logs associés au VPN IPsec, cela se passe dans le menu Status > System Logs, onglet Firewall.
Dans un autre article nous détaillons quelle procédure suivre pour dépanner et déboguer un tunnel IPsec qui ne fonctionne pas comme voulu.
Pour aller plus loin
[pfSense] Monter un VPN IPsec natté (Overlap network)
[pfSense] Les pannes courantes et leurs solutions sur un VPN IPsec
[pfSense] Comprendre et analyser les logs de son VPN IPsec
[pfSense] Monter un accès OpenVPN site-à-site
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez du matériel ou un support professionnel ? Alors contactez-nous.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : IPsecpfSensesécuritéVPN
Lorsque l'on essaie de diagnostiquer un problème de routage d'un flux réseau, l'une des premières choses à faire est de vérifier les routes connues par pfSense.
Dans cet article, nous présentons le fonctionnement de la table de routage sous pfSense et les détails à connaître pour un diagnostique efficace.
Visualiser les routes
Pour commencer, si vous n'êtes pas à l'aise avec cette notion de routes ou de table de routage, nous vous conseillons la lecteur du court article Table de routage sur Wikipédia.
Sous pfSense, il y a deux manières de visualiser les routes présentes dans la table de routage : via l'interface graphique ou en ligne de commande.
Pour visualiser la table de routage, nous nous rendons dans le menu Diagnostics > Routes :
Le résultat obtenu en ligne de commande est exactement le même que celui obtenu via l'interface graphique. La commande à saisir est :
netstat -rWn
Exemple de résultat obtenu :
L'explication du contenu de chaque colonne est la suivante.
Destination
Cette colonne contient l'hôte de destination (désigné par son adresse IP) ou le réseau de destination (désigné par son adresse IP et son masque de sous-réseau associé).
La destination default correspond à la route par défaut du pfSense. C'est vers la passerelle (gateway) associée que seront envoyés les flux destinés à un réseau qui n'est pas directement connu de pfSense.
Gateway
Une passerelle (gateway) est un routeur vers lequel le flux est envoyé afin qu'il soit routé vers une certaine destination. Si la colonne indique un lien comme link#1, alors cela signifie que le réseau est directement joignable sur l'interface du pfSense et qu'aucun routage complémentaire ne sera nécessaire pour acheminer le flux réseau.
Enfin, si c'est une adresse MAC qui est indiquée, cela signifie qu'il s'agit d'un hôte local directement joignable.
Flags
La signification de chaque flag (encore appelé indicateur ou drapeau en français) est la suivante :
- 1 (RTF_PROTO1) : routage spécifique au protocole flag #1
- 2 (RTF_PROTO2) : routage spécifique au protocole flag #2
- 3 (RTF_PROTO3) : routage spécifique au protocole flag #3
- B (RTF_BLACKHOLE) : suppression des paquets lors des mises à jour
- b (RTF_BROADCAST) : représente une adresse de broadcast
- D (RTF_DYNAMIC) : créée dynamiquement par redirection
- G (RTF_GATEWAY) : la destination est joignable via une gatway
- H (RTF_HOST) : entrée spécifique à un hôte (ou un réseau)
- L (RTF_LLINFO) : protocole de validation pour la translation d'adresse physique (ex : pour arp)
- M (RTF_MODIFIED) : modifiée dynamiquement par redirection
- R (RTF_REJECT) : hôte ou réseau injoignable
- S (RTF_STATIC) : entrée ajoutée manuellement
- U (RTF_UP) : route utilisable
- X (RTF_XRESOLVE) : un processus externe prend en charge la translation d'adresse physique
Par exemple, une route disposant des flags UGS signifie qu'elle est utilisable (U), que les paquets sont envoyés à une passerelle (G) et qu'elle a été ajoutée manuellement (S).
Use
Cette colonne est une compteur représentant le nombre total de paquets qui ont été envoyés via cette route. C'est très utile pour déterminer si une route est actuellement utilisée ; si c'est le cas, le nombre va continuer à s'incrémenter au fur et à mesure que des paquets réseaux passent par cette route.
MTU
La MTU configurée pour cette route.
Netif
L'interface réseau utilisée pour cette route (ex : igb0 ; igb1.10 ; ovpns1 ; ...).
Expire
Ce champ ne concerne que les entrées dynamiques. Il indique le délai au bout duquel la route va expirer si elle n'est plus utilisée.
Utiliser la commande traceroute
L'utilitaire traceroute est très pratique pour vérifier la bonne configuration de ses routes, notamment dans un environnement multi-WAN. Cet utilitaire présente le cheminement d'un flux réseau de routeur en routeur jusqu'à sa destination.
Sous pfSense, un traceroute peut être effectué depuis le menu Diagnostics > Traceroute :
Pour davantage d'informations sur le fonctionnement de cet utilitaire, vous pouvez lire le chapitre Fonctionnement de l'utilitaire traceroute sur Wikipédia.
Utilisé depuis son ordinateur (commande tracert sous les systèmes Windows) ou depuis pfSense, traceroute permettra de s'assurer qu'un flux réseau est dirigé vers la bonne gateway (le cas échéant, vers la bonne interface pour un environnement multi-WAN).
Routes et VPN
En fonction du type de VPN utilisé, une route peut être présente ou non dans la table de routage de pfSense. Par défaut, IPsec n'utilise pas la table de routage. IPsec maintient sa propre table de routage avec des entrées SPD (security policy database). Ainsi, la configuration manuelle d'une route statique sous pfSense ne permettra jamais de rediriger du trafic à travers un tunnel VPN IPsec. Il faut bien avoir cet élément en tête dans la configuration de sa stratégie de routage et dans la configuration de son tunnel VPN IPsec.
OpenVPN, quant à lui, utilise la table de routage de pfSense (pour être exact, il s'agit en fait de la table de routage de FreeBSD). Ainsi les réseaux joignables via un lien OpenVPN seront visualisables dans la table de routage.
De la même manière, il faut garder en tête que contrairement à OpenVPN, un tunnel IPsec lui-même n'a pas d'adresse IP. Ainsi, lors d'un traceroute, un timeout sera affiché pour le saut correspondant au tunnel IPsec.
Pour aller plus loin
[pfSense] Troubleshooting / Dépannage de ses règles de filtrage
[pfSense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense
[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Configurer un VPN IPsec site à site
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez du matériel ou un support professionnel ? Alors contactez-nous.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : pfSenseroutage
English version: [pfSense] Limit maximum bandwidth per users with Limiters
Les limiters sont une évolution des technologies de priorisation de trafic existante sur pfSense.
D'une façon générale, les limiters permettent de définir une bande-passante maximale pour un usage. Un limiter peut être utilisé pour limiter le trafic d'une adresse IP spécifique ou d'un sous-réseau, pour limiter le trafic pour un type de service spécifique (ex : e-mail, web, ...) ou encore pour répartir de manière équitable le trafic entre plusieurs utilisateurs.
Les usages classiques des limiters sont les suivants :
- limiter l'utilisateur X à 100 kbps de bande-passante Internet ;
- répartir équitablement 1 Mbps de bande-passante entre tous les utilisateurs du réseau "LAN" ;
- limiter le réseau "OPT" à 5 Mbps de bande-passante au total ;
- limiter le protocole FTP à 2 Mbps de bande-passante Internet
Si vous vous reconnaissez dans ces usages ou ces besoins, alors le présent article est fait pour vous. Si vous souhaitez mettre en place une solution de gestion de priorisation de trafic plus globale, alors notre article [pfSense] Configurer la priorisation de trafic avec CBQ est fait pour vous.
Les limiters permettent de définir une bande-passante maximale pour un usage. À l'inverse, la priorisation de trafic permet de garantir une bande-passante minimale.
Dans cet article, nous allons mettre en place des limiters afin de répartir équitablement la bande-passante de notre connexion Internet entre tous les usagers de notre réseau local.
Généralités sur les limiters
Tout comme pour la priorisation de trafic, la mise en place des limiters se fait en 2 étapes consistant à créer les limiters d'une part et à définir les règles d'affectation du trafic dans ces limiters d'autre part :
- Limiters : le limiter associé à un débit maximum et ses règles d'application globale ou par groupe d'adresses IP
- Rules : "règle d'affectation" définissant le limiter par laquelle un trafic spécifique va transiter. Ces règles sont les mêmes que pour la configuration du firewall : filtrage par port et adresse IP source, port et adresse IP de destination, protocole utilisé, etc.
Les limiters se créent généralement par paire : un limiter pour le trafic entrant (Download) et un limiter pour le trafic sortant (Upload).
Les limiters s'organisent de manières hiérarchiques. C'est-à-dire que l'on définit un limiter root (également appelé pipe), pour lequel on va généralement définir un débit et une latence, et des limiters enfants (appelés queues), pour lesquels on va généralement définir un poids (c'est-à-dire une priorité).
Cas d'usage : répartir équitablement la bande-passante Internet
Dans cet article nous partons du cas d'école suivant : nous disposons d'une connexion Internet ADSL offrant un débit descendant (download) de 20 Mbps et un débit montant (upload) de 1 Mbps.
Nous souhaitons que cette bande-passante soit automatiquement et dynamiquement partagée équitablement entre tous les utilisateurs.
C'est-à-dire que si nous avons 2 utilisateurs connectés en même temps, ils disposeront chacun de 10 Mbps en download et 0,5 Mbps en upload au maximum.
Si nous avons 10 utilisateurs connectés en même temps, ils disposeront chacun de 1 Mbps en download et 100kbps en upload au maximum.
pfSense gérera cette répartition équitable automatiquement et dynamiquement au fil de l'eau.
Notre schéma réseau est le suivant :
Démarrons la configuration sans plus attendre !
1. Création du limiter pour l'upload
Nous allons créer 2 limiters root : un pour l'upload et un pour le download.
La création s'effectue depuis le menu Firewall > Traffic Shaper :
Cliquer sur l'onglet Limiters, puis sur le bouton "+ New Limiter".
Les éléments à configurer sont les suivants :
- Enable : case à cocher pour activer le limiter root et ses queues
- Name : le nom de votre limiter root (caractères alphanumériques, tiret et underscore uniquement). Dans notre cas, nous l’appellerons "Upload"
- Bandwidth : la bande-passante de votre limiter root. Il est à noter que l'on peut définir une bande-passante en fonction d'un calendrier (option "Schedule"). Dans notre cas, nous choisissons "1 Mbps"
- Mask : ce paramètre permet de définir comment la limitation va s'appliquer sur le trafic. 3 choix sont possibles :
- none : la limitation s'appliquera à tout le trafic comme un ensemble unique. Dans notre cas, c'est ce que nous choisissons pour le limiter root "Upload" (on veut que l'ensemble du trafic soit limité à 1 Mbps).
- Source addresses : la limitation s'appliquera par adresse IP source (ou groupe d'adresses IP source, suivant le masque). Ainsi, pour effectuer une limitation par adresse IP d'un réseau, on choisira "Source addresses" et préciserons un masque /32. C'est cette valeur que nous choisirons lorsque nous configurerons la queue de notre limiter root d'Upload.
- Destination addresses : la limitation s'appliquera par adresse IP destination (ou groupe d'adresses IP destination, suivant le masque). Ainsi, pour effectuer une limitation par adresse IP d'un réseau de destination, on choisira "Destination addresses" et préciserons un masque /32. C'est cette valeur que nous choisirons lorsque nous configurerons la queue de notre limiter root de Download.
- Description : champ de description, purement informatif
- Advanced Options : permet de définir des paramètres avancés comme la latence ou le taux de perte de paquets. Ces paramètres sont utiles pour simuler des connexions Internet limitées ou de mauvaises qualités (ou pour faire une mauvaise blague à un collègue...). Nous ne l'utiliserons pas dans notre cas, mais le nom de chaque champ parle de lui-même
Exemple de résultat obtenu :
Nous pensons bien-sûr à cliquer sur le bouton "Save" pour sauvegarder notre configuration.
À ce stade, nous avons un limiter root qui va nous permettre de limiter notre trafic à une bande-passante maximale de 1 Mbps.
L'étape suivante est de créer une queue rattachée à ce limiter root et préciser que cette queue sera applicable par utilisateur. C'est-à-dire par adresse IP source avec un masque à /32.
C'est comme si virtuellement, autant de queues étaient dynamiquement créées pour chaque utilisateur, avec les mêmes caractéristiques (le même poids) et qu'elles allaient se répartir la bande-passante du limiter root auquel elles sont rattachées (1 Mbps).
En bas de la page du limiter que nous venons de créer, nous cliquons sur le bouton "+ Add new Queue".
Les éléments à configurer sont les suivants :
- Enable : nous cochons cette case pour activer la queue que nous sommes en train de créer
- Name : le nom de notre queue. Dans notre cas, nous l'appellerons "LAN_Upload"
- Mask : le maque à appliquer, fonctionnant sur le même principe que pour le limiter root. Dans notre cas, nous choisissons "Source addresses" afin d'appliquer une limite sur le trafic en upload, donc quittant notre réseau local avec une adresse IP source locale. Nous souhaitons que cette limitation s'applique pour chaque utilisateur, c'est-à-dire par adresse IP ; nous choisissons donc "32" comme taille du masque.
- Description : champ de description, purement informatif
- Weight : le poids de la queue allant de 1 (priorité la plus faible) à 100 (priorité la plus forte). Pour une répartition équitable de la bande-passante du limiter root, on peut laisser ce champ vide. Si l'on souhaite donner davantage de bande-passante à certains utilisateurs qu'à d'autres, alors il faut jouer sur cette valeur. Dans notre cas, nous laissons le champ vide (la répartition sera équitable).
- Advanced Options : les autres options permettent de simuler des connexions limitées ou de mauvaises qualités. Nous laissons ces champs vides.
Exemple de résultat obtenu :
Nous pensons bien-sûr à cliquer sur le bouton "Save" pour sauvegarder notre configuration. Puis sur "Apply Changes" pour que la nouvelle configuration soit prise en compte par pfSense.
Nos limiters (limiter root et queue) sont prêts pour le trafic sortant (upload). Il nous reste à faire la même configuration pour le trafic entrant (download).
2. Création du limiter pour le download
Nous cliquons sur le bouton "+ New Limiter". La configuration est la même que pour l'upload. Il faut simplement penser à choisir le bon débit (dans notre cas, 20 Mbps) et à changer son nom (dans notre cas, nous l'appellerons "Download").
Exemple de résultat obtenu :
Nous pensons bien-sûr à cliquer sur le bouton "Save" pour sauvegarder notre configuration.
Comme pour la partie upload, nous allons créer une queue, pour cela, nous cliquons sur le bouton "+ Add new Queue".
La configuration est presque la même que pour la queue d'upload. La différence réside dans le choix "Destination addresses" pour l'option "Mask".
En effet, nous souhaitons ici que virtuellement des queues soient créées dynamiquement pour le trafic entrant (download) à destination d'adresses IP locales.
Exemple de résultat obtenu :
Nous pensons bien-sûr à cliquer sur le bouton "Save" pour sauvegarder notre configuration. Puis sur "Apply Changes" pour que la nouvelle configuration soit prise en compte par pfSense.
Nos limiters sont créés :
Il ne nous reste plus qu'à adapter nos règles de filtrage pour les mettre en application.
3. Création des règles d'application
La dernière étape consiste à configurer le firewall pour lui indiquer quel trafic va passer par quel limiter.
Cette configuration se fait depuis le menu Firewall > Rules.
Choisir l'onglet LAN et éditer les règles de filtrage.
Sur chaque règle, se rendre dans les options avancées (bouton "Display Advanced") :
En bas de page, pour l'option "In / Out pipe", choisir "LAN_Upload" pour la première liste déroulante et "LAN_Download" pour la seconde :
Attention : il est nécessaire de faire cette manipulation sur toutes les règles de filtrage de votre interface LAN (ou de vos interfaces locales d'une façon générale) pour l'accès à Internet.
Pour être sûr d'affecter le bon limiter au bon champ In ou Out, il faut avoir en tête que ces champs représentent la vue depuis le firewall. C'est-à-dire que le champ IN correspond au trafic qui entre (incoming) sur cette interface, soit dans notre cas au trafic qui provient d'un utilisateur du LAN et va vers Internet ou un autre réseau.
C'est donc le limiter d'upload qu'il faut assigner à ce champ.
A contrario, le champ Out correspond au trafic qui sort (outgoing) par cette interface, soit dans notre cas le trafic qui provient d'Internet ou d'un autre réseau et qui est à destination d'un ordinateur du LAN.
C'est donc le limiter de download qu'il faut assigner à ce champ.
La limitation de trafic par utilisateur est en place !
4. Vérifier le bon fonctionnement
Pour vérifier que les limiters fonctionnent correctement, il faut se rendre dans Diagnostics > Limiter Info.
Chaque root limiter et ses queues sont présentés au format texte avec leurs paramètres et leurs valeurs.
Pour aller plus loin
[pfSense] Comprendre la priorisation de trafic
[pfSense] Configurer la priorisation de trafic avec CBQ
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : limiterspfSenserépartition bande-passante
Vous avez peut-être déjà rencontré des problèmes de grosses lenteurs d'accès au dashboard de pfSense ?
Nous aussi !
Ces lenteurs apparaissent lorsque pfSense n'arrive plus à se connecter à Internet ou, pour être plus précis, n'arrive plus à joindre un serveur de Netgate.
Edit : ce bug est maintenant corrigé.
Nous avons cherché à comprendre le problème et à le corriger. En parallèle de ce travail, nous avons constaté que cette anomalie avait déjà été rapportée et qu'un ticket était ouvert sur le redmine de pfSense.
Nous pensions initialement que le problème serait corrigé rapidement. Mais comme ce n'est visiblement pas le cas, nous avons pensé qu'il pouvait être utile de partager la solution de contournement et d'en profiter pour présenter la méthodologie d'analyse que nous avons suivie.
Dans cet article, nous partageons la méthodologie d'analyse suivie afin de comprendre l'origine du problème rencontré et, bien-sûr, trouver la solution au problème.
1. Le problème : le tableau de bord est lent lorsque pfSense n'a plus accès à Internet
Le contexte est généralement le suivant : vous disposez d'une interface WAN active, mais non-connectée à Internet.
Les raisons à ce type de situations sont nombreuses : perte de la connexion Internet, serveurs DNS inaccessibles, règles d'Outbound NAT mal configurées, cas où pfSense est configuré en tant que firewall de cœur de réseau n'ayant pas vocation à avoir accès à Internet, etc.
Mais le problème peut également survenir alors que votre connexion Internet est parfaitement fonctionnelle.
Le problème : l'interface d'administration de pfSense semble devenir très lente uniquement sur certaines pages. Et notamment lors de l'accès au tableau de bord (c'est-à-dire la page principale, le Dashboard). La page met alors une bonne minute à se charger. Seule cette page serait concernée par ce phénomène de lenteur à l'affichage. Mais, en pratique, d'autres pages sont également concernées lorsque l'on effectue une modification (lorsque l'on fait une modification quelconque depuis la page System > General Setup, par exemple).
La version de pfSense concernée : 2.4.4
Note : il semblerait que le problème ne soit présent que si votre interface WAN est configurée avec une adresse IP fixe.
Note 2 : pour être précis, en fait le problème ne se produit pas lorsque pfSense n'a plus accès à Internet, mais lorsque pfSense n'arrive pas à joindre un serveur hébergé chez Netgate (l'éditeur du logiciel pfSense).
tl;dr : dans la section suivante, nous partageons la méthodologie d'analyse que nous avons suivie pour trouver l'origine du problème. Si vous le souhaitez, vous pouvez vous rendre directement à la dernière section "3. Solution" si vous souhaitez connaître le problème exact et la solution de contournement proposée.
2. Méthodologie d'analyse
Nous avons appliqué une méthodologie visant à cibler la source exacte du problème et avons suivi les étapes ci-dessous :
2.1. Serait-ce un widget qui n'arrive pas à se charger ?
Nous avons d'abord pensé que la source du problème était un widget présent sur la page d'accueil qui faisant une requête vers un serveur web externe qui était inaccessible (la suite nous montrera que nous avions vu juste...).
La première étape de la démarche de recherche a donc consisté à faire le tour des différents widgets présents sur la page d'accueil et à les supprimer les uns après les autres afin de voir si une amélioration était constatée.
Difficile d'avoir un dashboard plus épuré...
=> Résultat obtenu : aucune amélioration. Même sans aucun widget sur le dashboard, le problème est toujours présent. Le problème semble donc, à première vue, ne pas venir d'un widget en particulier.
2.2. Serait-ce lié aux serveurs DNS ?
Nous avons ensuite soupçonné un problème de résolution DNS (le délai d'environ une minute avant que la page ne se charge ressemblait fortement à un délai de timeout).
Nous avions toujours dans l'idée que le problème pouvait être lié à un serveur web externe inaccessible.
Nous avons donc essayé de modifier ou de supprimer les serveur DNS renseignés sur l'interface d'administration du pfSense (menu System > General Setup). Peut-être étaient-ils à l'origine de cette lenteur.
Même sans serveur DNS de configuré, le résultat est toujours le même
=> Résultat obtenu : aucune amélioration.
2.3. Désactivons l'interface WAN !
Nous avons alors essayé de désactiver l'interface WAN. Nous nous rendons pour cela dans le menu Interfaces > Wan, et nous décochons la case "Enable interface".
=> Résultat obtenu : ça marche ! Il n'y a plus aucune lenteur !
Il semble donc que ce soit lié au fait que l'interface WAN soit active, mais déconnectée, ou tout du moins que le problème se produit lorsque l'interface WAN est active et n'arrive pas à joindre un serveur web externe. À noter, pour être exact, que la suite de nos tests nous a permis de constater que c'est précisément lorsque l'interface WAN est à l'état "UP" que le problème peut survenir.
À ce stade nous avons compris (au moins partiellement) quelle était la configuration à l'origine du problème. Problème qui devient donc maintenant reproductible.
En revanche, nous ne savons toujours pas quelle est la cause. Que se passe-t-il exactement ? Pourquoi le fait de perdre son accès à Internet entraîne une lenteur uniquement sur la page principale (Dashboard) ?
Dégainons notre meilleure arme pour essayer de comprendre ce qu'il se passe : faire une capture réseau et analyser !
2.4. Lançons un tcpdump sur l'interface WAN
Nous réactivons l'interface WAN et nous laçons une commande tcpdump sur celle-ci. Cette commande peut être exécutée depuis le menu Diagnostics > Packet Capture.
Nous utilisons Wireshark pour analyser nos paquets capturés.
Requête DNS pour l'enregistrement ews.netgate.com
Sur la capture d'écran, nous constatons qu'il y a une requête DNS pour un domaine particulier : ews.netgate.com
Pour les plus curieux, la série de requêtes ICMP visible sur la capture d'écran correspond à la supervision de sa passerelle par défaut (10.10.10.1) par pfSense (10.10.10.10).
Nous avons alors ajouté une entrée DNS statique sur pfSense afin que le domaine ews.netgate.com soit résolu par une adresse IP locale (127.0.0.1 ou 0.0.0.0) et, bingo plus aucune lenteur ! (Nous expliquons dans le dernier paragraphe comment reproduire cette solution).
À ce stade, nous avons l'élément à l'origine du problème de lenteur. Il reste à déterminer pourquoi pfSense demande à son serveur DNS de résoudre le domaine ews.netgate.com et pourquoi lorsque cette résolution n'aboutit pas ou que le serveur ews.netgate.com est injoignable, le chargement du tableau de bord est ralenti.
Bonne nouvelle, pfSense est open-source ! Nous allons donc pouvoir étudier le code source pour comprendre quelles pages font appel à ce domaine et que cherchent-elles à récupérer sur ce domaine.
2.5. Analyse du code source
Le code source de pfSense est accessible sur le site GitHub : https://github.com/pfsense/pfsense.
Une recherche sur le nom de domaine ews.netgate.com sur le dépôt pfSense nous permet de comprendre pourquoi une requête est effectuée vers ce nom de domaine :
Lorsque l'on charge la page d'accueil (index.php), si le fichier copyright n'existe pas où qu'il n'a pas été mis à jour depuis au moins 24 heures, pfSense cherche à le télécharger via https://ews.negate.com/copyright.
Le code est ainsi fait (requête cURL en PHP) que cette requête est bloquante pour le chargement du reste de la page.
Un rapport de bug a été rédigé. Il est consultable ici : https://redmine.pfsense.org/issues/8987. La solution n'est pas triviale. Si vous avez une idée de solution et que vous souhaitez contribuer, vous savez ce qu'il vous reste à faire... ;-)
3. Solution
Edit : comme rappelé en début d'article, ce bug est maintenant corrigé.
Pour résumer, le problème est le suivant : depuis pfSense 2.4.4, lorsque l'on charge la page d'accueil (index.php), si le fichier copyright n'existe pas où qu'il a pas été mis à jour depuis plus de 24 heures, pfSense cherche à le télécharger via https://ews.negate.com/copyright.
Si lors de cette mise à jour, pfSense n'arrive pas à joindre le serveur ews.netgate.com, alors le chargement de la page est bloquée jusqu'au timeout DNS (d'environ 60 secondes) de la requête de résolution de nom.
Un rapport de bug a été rédigé. Il est consultable ici : https://redmine.pfsense.org/issues/8987. La solution n'est pas triviale. Si vous avez une idée de solution et que vous souhaitez contribuer, vous savez ce qu'il vous reste à faire... ;-)
Le nom de domaine ews.netgate.com est utilisé pour trois choses :
- télécharger la licence applicable à pfSense
- télécharger les informations liées au Support
- rechercher les mises à jour disponibles
Aussi, une solution de contournement que nous proposons (nous en proposons également deux autres en fin d'article) est d'ajouter une entrée DNS pour le domaine ews.netgate.com sur le résolveur de pfSense afin qu'il pointe vers son adresse IP de localhost.
Pour cela, se rendre dans le menu Services > DNS Resolver :
Nous ajoutons une entrée de type Host overrides (en bas de page) en cliquant sur le bouton "+Add" :
Les champs à compléter sont les suivants :
- Host : le nom de l'hôte, sans la partie domaine. Soit, dans notre cas : ews
- Domain : le domaine parent de l'hôte. Soit, dans notre cas : netgate.com
- IP Address : l'adresse IP correspondante. Dans notre cas : 127.0.0.1
- Description : une description facultative
Exemple de résultat obtenu :
Nous cliquons sur "Save", puis "Apply Changes" pour valider nos changements.
Attention : comme le fait très justement remarqué Albirew en commentaire, en procédant ainsi, nous bloquons également les recherches de mises à jour par pfSense. En effet, pfSense recherche les mises à jour en effectuant une requête vers https://ews.netgate.com/pfupdate.
La solution proposée est donc bien une solution de contournement temporaire. Ce n'est pas une solution idéale.
Deux autres solutions moins impactantes sont également possibles :
1. Modifier le code source du fichier index.php pour supprimer la recherche liée à la licence (il suffit de commenter la ligne « require_once("copyget.inc"); » (ligne 469) du fichier « /usr/local/www/index.php »).
2. Ajouter une tâche cron mettant à jour le fichier « /cf/conf/copyright » (ex : « touch /cf/conf/copyright ») exécutée toutes les 20 heures, par exemple. Merci à Albirew pour cette proposition.
Voilà, vous ne devriez plus rencontrer ce problème de lenteur lors du chargement du tableau de bord de pfSense lorsque le serveur ews.netgate.com est inaccessible !
Pour aller plus loin
[pfSense] Troubleshooting / Dépannage de ses règles de filtrage
[pfSense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense
[pfSense] Gardez son firewall toujours à l'heure avec une puce GPS
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : pfSense
English version: [pfSense] Multiple WAN Connections
Nous allons voir dans cet article comment configurer pfSense pour disposer de deux connexions Internet (ou plus encore) utilisables en loadbalancing ou en fail-over.
Ces configurations permettent d'accroître le débit disponible pour l'accès Internet ou d'assurer une continuité de service en cas de panne du lien principal, par exemple.
Avant de commencer, les questions à se poser...
Combien peut-on avoir de connexions Internet en simultané ?
Il n'y a pas de limites théoriques.
Nous avons de très nombreux exemples d'installations disposant de 2, 3 ou 4 connexions Internet.
Le déploiement le plus important que nous avons rencontré est de 12 connexions Internet simultanées.
Une haute-disponibilité peut-elle être assurée via deux connexions Internet du même type chez le même opérateur
Généralement, la réponse est plutôt non. Il faut privilégier des connexions Internet chez des opérateurs différents. En effet, lorsqu'un opérateurs rencontre une panne (sur son DSLAM, par exemple), la panne est présente sur tous ses liens arrivant au même endroit.
Disposer de plusieurs connexions chez le même opérateur peut être une bonne approche si l'objectif recherché est d'accroître son débit.
Vaut-il mieux une connexion Internet disposant d'un bon débit ou de plusieurs connexions Internet disposant d'un débit moindre
La réponse va dépendre du prix et de la garantie de temps de rétablissement dont vous disposez sur chaque lien. Ce sont les deux principaux critères de décision.
Principe de fonctionnement
Dans notre article nous prendrons l'exemple suivant : une entreprise disposant de 2 connexions ADSL de débit similaire, sur lesquels nous souhaitons mettre en place de la répartition de charge (load-balancing).
Le schéma réseau serait le suivant :
La configuration de la haute-disponibilité ou du failover des liens Internet se fait au niveau de la gestion des passerelles et des groupes de passerelles.
Nous allons donc configurer pfSense pour qu'il utilise telle ou telle passerelle (et donc telle ou telle connexion Internet) en fonction de priorité que nous définirons.
Pour cela, nous créerons un groupe de passerelles dans lequel nous définirons quelles connexions Internet utiliser, avec quelles priorités et le cas échéant selon quelles règles de bascule de l'une à l'autre.
Il faut avoir en tête que la configuration du routage sur pfSense se fait de 3 façons, de la priorité la plus forte à la moins forte :
- Forcer la gateway dans les règles de firewall : permet de forcer le routage pour une règle de firewall précise (cela se configure dans les options avancées des règles de firewall) - dans cette configuration, on peut choisir une passerelle ou un groupe de passerelles.
- Définir une route : permet de forcer le routage pour une adresse IP ou une plage d'adresses IP destination (cela se configure dans le menu System > Routing) - dans cette configuration, on peut choisir une passerelle, mais pas un groupe de passerelles.
- Définir une passerelle par défaut : par défaut, tous les flux sortants utiliseront cette passerelle (plus exactement, tous les flux à destination d'un réseau inconnu de pfSense) - dans cette configuration, on peut choisir une passerelle, mais pas un groupe de passerelles.
Les pré-requis [1/2] : disposer d'interfaces WAN fonctionnelles
Dans notre exemple, le premier lien Internet est connecté sur l'interface "WAN", le second lien Internet est connecté sur l'interface "WAN2".
Exemple de configuration obtenue :
La configuration des interfaces WAN et WAN2 n'entrent pas dans le périmètre de cet article. Que ces interfaces soient configurées en adresses IP statiques ou dynamiques (DHCP) n'a pas d'importance.
Ce qui est important est que vous disposiez de 2 interfaces configurées pour vos connexions Internet.
Les pré-requis [2/2] : disposer d'un serveur DNS sur chaque passerelle WAN
En cas de perte d'un des liens Internet, il est important que les requêtes DNS continuent de fonctionner. Pour cela, il faut définir au moins un serveur DNS par gateway WAN.
Cette configuration se fait dans System > General Setup.
La configuration se fait dans la partie "DNS Server Settings". Par exemple, en utilisant les DNS de Google :
Nous utilisons les serveurs DNS de Google à titre d'exemple. Il est à noter que si vous ne souhaitez pas utiliser les serveurs DNS de votre fournisseur d'accès, alors il est préférable d'utiliser d'autres serveurs DNS que ceux de Google, comme ceux de French Data Network (80.67.169.12 et 80.67.169.40) ou de Quad9 (9.9.9.9).
Les pré-requis étant levés, passons maintenant à la configuration.
1. Créer un groupe de passerelles
Nous allons créer un groupe de passerelles comprenant la passerelle de l'interface WAN et la passerelle de l'interface WAN2.
La création s'effectue depuis le menu System > Routing.
Se rendre dans l'onglet Gateway Groups.
Puis cliquer sur le bouton "+ Add".
Les éléments à configurer sont les suivants :
- Group Name : le nom du groupe de passerelles. Dans notre exemple, nous choisissons "Groupe_Gateway" (attention, pas d'espace, tiret ou de caractères spéciaux dans le nom).
- Gateway Priority : pour chaque passerelle, nous donnons une priorité d'utilisation. La priorité la plus faible l'emporte toujours. C'est-à-dire que si pour la passerelle de l'interface WAN, vous choisissez une priorité 1 et pour la passerelle de l'interface WAN2 une priorité 2, alors le trafic s'écoulera exclusivement par la passerelle de l'interface WAN. Le trafic s'écoulera via la passerelle de l'interface WAN2 si et seulement si la passerelle de l'interface WAN est hors-service.
Ainsi, si vous souhaitez faire de la répartition de bande-passante entre vos 2 connexions Internet, il faut choisir le même niveau de priorité.
Si vous souhaitez configurer une connexion Internet en secours d'une principale, alors il faut jouer sur le niveau de priorité.
pfSense gère jusqu'à 5 niveaux de priorités allant de "Tier 1" (priorité la plus forte) à "Tier 5" (priorité la plus faible).
Dans notre cas, nous souhaitons faire de la répartition de charge, nous choisissons donc "Tier 1" pour le WAN et pour le WAN2.
- Virtual IP : sur chaque interface, vous pouvez choisir l'adresse IP avec laquelle pfSense va émettre ses paquets. Soit c'est l'adresse IP de l'interface, soit c'est une adresse IP virtuelle précédemment créée. Ce peut être utile si vous avez 2 pfSense redondants, par exemple (cf. notre article [pfSense] Configurer un cluster de 2 pfSense redondants (failover)).
- Trigger Level : permet de définir le déclencheur qui permettra à pfSense de choisir quand basculer vers un lien disposant d'une priorité plus faible. Il existe 4 valeurs possibles :
- Member down : lorsqu'une passerelle est considérée comme non-joignable (c'est-à-dire lorsque l'adresse IP de monitoring associée n'est plus joignable par un ping)
- Packet Loss : lorsque le taux de perte de paquets maximum configuré pour cette passerelle est atteint
- High Latency : lorsque la latence maximale définie pour cette passerelle est atteinte
- Packet Loss or High Latency : lorsque le taux de perte de paquets maximum ou la latence maximale est atteint
Ces paramètres (taux de perte de paquets maximum, latence maximale, etc.) se définissent dans la configuration de la passerelle.
Dans notre cas, nous choisissons "Member down".
- Description : champ optionnel purement cosmétique
Exemple de résultat obtenu :
Nous sauvegardons et cliquons ensuite sur "Apply changes" pour appliquer la configuration.
À ce stade, nous avons créé un groupe de passerelles qui permet de répartir équitablement le trafic Internet sur nos deux connexions. Il nous reste à indiquer à pfSense quel trafic doit utiliser ce groupe de passerelles.
2. Mettre en service le dual-WAN
La (presque) dernière étape consiste à configurer le firewall pour lui indiquer par quelle passerelle (ou plutôt quel groupe de passerelles dans notre cas) faire passer le trafic. Comme vu en début d'article, sans précision de notre part, le firewall utilisera la passerelle par défaut. Il est évidemment possible de définir soi-même quelle est la passerelle par défaut. En revanche, il n'est pas possible de définir qu'il faut utiliser un groupe de passerelles par défaut.
Il nous faut donc préciser dans chacune des règles du firewall que le trafic doit s'écouler par notre passerelle par défaut.
Cette configuration se fait depuis le menu Firewall > Rules.
Choisir l'onglet LAN et éditer les règles de filtrage.
Sur chaque règle, se rendre dans les options avancées (bouton "Display Advanced") :
En bas de page, préciser le groupe de passerelles dans le champ Gateway :
Attention : il est nécessaire de faire cette manipulation sur toutes les règles de filtrage de votre interface LAN (ou de vos interfaces locales d'une façon générale) pour l'accès à Internet.
Exemple de résultat obtenu :
Félicitations, votre dual-wan est en place !
3. Configuration des services spécifiques
Configuration du service OpenVPN server
Si un serveur OpenVPN est configuré sur le pfSense, il est nécessaire de modifier l'interface d'écoute du service (normalement "WAN") pour la remplacer par le groupe de passerelle (Groupe_Gateway).
Cette modification s'opère dans "OpenVPN" > "Servers".
Davantage d'informations sur la configuration du service OpenVPN : [pfSense] Monter un accès OpenVPN site-à-site.
Configuration du service VPN IPsec
Si un tunnel IPsec est configuré sur le pfSense, il est nécessaire de modifier l'interface d'écoute du VPN IPsec (normalement "WAN") pour la remplacer par le groupe de passerelles (Groupe_Gateway).
Cette modification s'opère dans "VPN" > "IPsec". La modification s'effectue sur la phase 1.
4. Load-balancing avancé
Il est possible de définir des poids, ou des priorités, à chaque passerelle de sorte que le load-balancing ne soit pas fait obligatoirement suivant un ratio équitable (de type 50%-50% pour du dual-wan ou 33%-33%-33% dans le cas de trois connexions Internet).
Ces poids se définissent de 1 à 30. Par défaut, le poids de chaque passerelle est de 1.
Le mode de fonctionnement des poids est le suivant :
- s'il y a 2 passerelles et qu'elles disposent chacune d'un poids de 1, alors la répartition de bande passante sera de 1/2 pour chacune, soit 50%.
- si l'une dispose d'un poids de 1 et la seconde d'un poids de 2, alors la première prendra 1/(1+2) = 33% du trafic et la seconde 2/(1+2) = 67% du trafic.
- si l'une dispose d'un poids de 5 et l'autre d'un poids de 12, alors la première prendre 5/(5+12) = 30% du trafic et la seconde 12/(5+12) = 70% du trafic.
Il est ainsi donc possible de définir des rapports de répartition du trafic sortant jusqu'à un rapport de 1 à 30.
Cette personnalisation s'opère dans la configuration de la passerelle depuis le menu System > Routing.
Il faut modifier la passerelle (icône en forme de crayon) et se rendre dans les options avancées (Display Advanced), puis modifier le champ "Weight".
Cette fonctionnalité est très pratique si l'on veut coupler 2 connexions ne disposant du même débit (une connexion ADSL et une connexions SDSL, par exemple).
5. Vérifier le bon fonctionnement
Une manière simple de vérifier que le trafic passe bien maintenant par les 2 connexions Internet est de se rendre dans Status > Traffic Graph.
En sélectionnant les interfaces WAN et WAN2, vous devriez voir le trafic s'écouler via les 2 liens.
Ensuite, pour tester le bon fonctionnement de la haute-disponibilité de vos liens, plusieurs tests peuvent être réalisés. En voici quelques exemples :
- débrancher et rebrancher successivement le câble réseau de l'interface WAN puis WAN2
- télécharger un fichier ou lancer des requêtes ping lorsque que vous ferez la manipulation précédente afin de constater la bonne bascule du trafic sur un lien Internet puis l'autre
À ce stade, pensez à faire une sauvegarde de la configuration de votre pfSense ("Diagnostics" > "Backup & Restore") ;-)
Pour aller plus loin
[pfSense] Configurer un cluster de 2 pfSense redondants (failover)
[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Configurer ses VLAN
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : dual-wanhaute-disponibilitémulti-wanpfSense
pfSense supporte depuis de nombreuses années des fonctionnalités de gestion du Wi-Fi lui permettant d'agir comme un point d'accès sans-fil ou de se connecter à un point d'accès existant.
Pour pouvoir profiter pleinement de toutes les fonctionnalités offertes par pfSense dans la gestion du Wi-Fi, il est important de bien choisir sa carte Wi-Fi afin qu'elle soit pleinement compatible.
Dans cet article, nous faisons un tour d'horizon des caractéristiques supportées par pfSense pour la gestion des réseaux sans-fil et détaillerons comment bien choisir sa carte Wi-Fi et où l'acheter au meilleur prix !
Attention : plusieurs utilisateurs rapportent des instabilités du Wi-Fi depuis la dernière version de pfSense (2.4.5-RELEASE-p1). Aussi, pour le moment, nous ne recommandons pas d'utiliser pfSense comme point d'accès Wifi pour les nouveaux déploiements ou en environnement professionnel.
[Introduction] L'ensemble de normes 802.11
Le fonctionnement des réseaux Wi-Fi est normalisé à travers l'ensemble de normes 802.11.
Cet ensemble de normes comporte plusieurs protocoles, dont les principaux sont les suivants :
- 802.11a : offre un débit jusqu'à 54 Mbps sur la bande des fréquences des 5 GHz
- 802.11b : offre un débit jusqu'à 11 Mbps sur la bande des fréquences des 2,4 GHz
- 802.11g : offre un débit jusqu'à 54 Mbps sur la bande des fréquences des 2,4 GHz
- 802.11n : offre un débit théorique jusqu'à 450 Mbps par multiplexage "MIMO" sur les bandes des fréquences 2,4 et 5 GHz
- 802.11 ac : offre un débit théorique en Gbps sur la bande des fréquences des 5 GHz
Pour en savoir plus sur le fonctionnement des réseaux sans-fil et de ces normes, nous vous recommandons la lecture de l'article Wi-Fi n, ac, ad, ax… : tout savoir sur le réseau sans fil et ses débits du site FrAndroid.
Il est important de savoir qu'il existe plusieurs protocoles et d'identifier quels protocoles sont supportés par pfSense ou par sa carte Wi-Fi afin d'être certain de faire le bon choix en fonction de ses besoins.
Support du 802.11b, 802.11g, 802.11n
Les versions actuelles de pfSense supportent ces 3 protocoles sur une variété de matériels.
Il est difficile de dresser la liste exhaustive des matériels supportés. D'autant que certains matériels peuvent fonctionner, mais à des débits très faibles...
C'est pourquoi, avant de choisir une carte Wi-Fi, il vaut mieux s'assurer qu'elle soit effectivement annoncée comme étant compatible pfSense par le fabricant ou le revendeur (qui l'aura donc préalablement testée).
Support du 802.11ac
C'est très simple, il n'y a actuellement aucun support du 802.11ac sous pfSense.
Fréquences radio et dual-band
Certaines cartes Wi-Fi supportent les fréquences sur la bande des 2,4 Ghz et sur la bande des 5 GHz. Cependant, actuellement il n'y a aucune carte qui puisse fonctionner sous pfSense en opérant à la fois dans la bande des fréquences des 2,4 GHz et des 5 GHz.
L'idée d'utiliser 2 cartes différentes dans le même boîtier (afin d'en configurer une qui fonctionnerait sur la bande des 2,4 GHz et la seconde sur la bande des 5 GHz) est à proscrire car cela créerait inévitablement des interférences radio.
Aussi, s'il est nécessaire de disposer d'un point d'accès supportant ce fonctionnement dual-band (pour des raisons de compatibilité avec des terminaux spécifiques, notamment), alors nous recommandons clairement l'utilisation d'un point d'accès externe dédié.
Point d'accès multi-SSID
Une fonctionnalité très utile est la capacité à pouvoir diffuser plusieurs SSID (plusieurs réseaux Wi-Fi) indépendants dans leur configuration et dans leur mode de fonctionnement (l'un avec authentification par clé WPA/WPA2, l'autre avec une authentification par portail captif, ...) depuis la même carte Wi-Fi.
Un exemple concret d'utilisation serait que notre pfSense diffuse un réseau Wi-Fi pour les collaborateurs de l'entreprise et en parallèle diffuse également un second réseau Wi-Fi "invité" (sur lequel on pourra d'ailleurs configurer un portail captif depuis pfSense) pour les personnes externes à l'entreprise de passage dans les locaux.
pfSense supporte pleinement cette fonctionnalité. Cependant, toutes les cartes Wi-Fi ne peuvent pas fonctionner avec ce mode... Si cette fonctionnalité vous intéresse, il est donc nécessaire que la carte Wi-Fi que vous choisirez la supporte.
Nous avons fait le tour des éléments à prendre en considération dans le choix de sa carte Wi-Fi.
Est-ce une bonne idée de faire porter par pfSense le point d'accès Wi-Fi de son réseau ?
C'est une question fréquente. Dans la même logique, une question qui revient souvent est de se demander s'il est pertinent de faire supporter par pfSense plusieurs fonctionnalités (firewall, serveur DHCP, point d'accès WiFi, ...).
Nous profitons de cet article pour y apporter notre réponse.
Cette réponse va dépendre principalement du contexte et de la taille de la structure concernée. De notre point de vue, il faut distinguer 2 cas :
1. Cas d'un usage SOHO / TPE / PME
Dans le cas d'un usage personnel ou pour une petite structure (de l'ordre de moins d'une vingtaine d'utilisateurs), il apparaît comme tout à fait pertinent de confier à pfSense la gestion de son point d'accès sans-fil.
La totalité des fonctionnalités attendues est normalement pleinement couverte par pfSense et cela permet de bénéficier d'un usage de pfSense de type "BOX professionnelle".
On peut alors voir pfSense comme une BOX s'occupant de délivrer l'ensemble des services réseaux nécessaires : routeur, filtrage firewall, serveur DHCP, serveur ou relais DNS, point d'accès sans-fil, serveur VPN, proxy, portail captif, etc.
C'est un choix rationnel qui permet de centraliser et d'administrer l'ensemble de ces fonctionnalités réseau à travers une seule interface et sur un produit open-source dans lequel on a pleinement confiance.
C'est également un choix économiquement intéressant car il n'y a alors qu'un seul matériel à acquérir (la "BOX" pour pfSense).
Enfin, sachez qu'il existe de très nombreux retours d'expérience probants quant à l'utilisation de pfSense en point d'accès quels que soient les équipements se connectant dessus (Mac, iPhone, Android, Windows, Xbox, ...).
2. Cas d'un usage grosse entreprise type ETI / Grand Compte
Dans les plus gros environnements de production, cela a beaucoup moins de sens de vouloir faire porter par pfSense le rôle de point d'accès sans-fil.
La fonctionnalité première de pfSense est de garantir la sécurité des flux sur le réseau de l'entreprise.
Sans parler des problématiques de sécurité du fait de vouloir faire porter trop de fonctionnalités par un seul équipement (défense en profondeur, notamment), il y a de nombreux cas d'utilisation où pfSense ne sera pas le plus adapté.
En particulier pour les déploiements répondant à des exigences telles que le support du 802.11ac, la possibilité de fonctionner en simultanée sur la bande des 2,4 et des 5 GHz ou les réseaux sans-fil maillés, etc.
Il faut également réfléchir à la localisation du point d'accès car bien souvent le firewall n'est pas placé au meilleur endroit pour diffuser un réseau sans-fil.
Enfin, les besoins pour ce type d'environnement sont très différents et pfSense n'est pas une solution adaptée pour y répondre : gestion des réseaux sans-fil étendu, cartographie, ... sont autant de fonctionnalités que n'offre pas pfSense pour la gestion d'un réseau Wi-Fi de grande envergure.
Si vous êtes dans ce cas d'usage et que vous avez un besoin Wi-Fi, nous recommandons l'utilisation des solution d'Ubiquiti Networks ou d'autres solutions spécialisées.
On résume : comment choisir sa carte Wi-Fi
Si vous souhaitez utiliser pfSense en point d'accès Wi-Fi ou en client Wi-Fi dans le cadre d'un usage particulier ou petite entreprise, c'est tout à fait possible.
Les éléments à prendre en compte sont :
- s'assurer que la carte Wi-Fi soit compatible pfSense et supporte les protocoles 802.11b/g/n
- s'assurer que la carte Wi-Fi puisse fonctionner sous pfSense aussi bien en mode client qu'en mode point d'accès
- s'assurer que la carte Wi-Fi supporte la possibilité de diffuser plusieurs réseaux Wi-Fi (plusieurs SSID) en parallèle
- s'assurer du débit offert par la carte Wi-Fi en fonctionnant sous pfSense
Il faut avoir conscience des limitations suivantes :
- pfSense ne supporte par le protocole 802.11ac
- aucune carte Wi-Fi ne peut actuellement fonctionner sous pfSense en diffusant à la fois dans la bande des 2,4 et des 5 GHz
- pfSense n'est clairement pas adapté pour servir de point d'accès Wi-Fi dans le cadre d'un réseau sans-fil d'envergure
D'une façon générale, nous recommandons uniquement les cartes Atheros. Et uniquement elles.
Les appareils sans-fil les plus couramment utilisés par les développeurs et les utilisateurs de FreeBSD ou pfSense sont ceux qui utilisent des pièces fabriquées par Atheros.
Où acheter sa carte Wi-Fi ?
Netgate propose sur sa boutique en ligne la carte WLE200NX (chipset Atheros AR9280) : https://store.netgate.com/WLE200NX-80211nabg-miniPCIe-Card-P1763.aspx. Cette carte répond normalement à tous les pré-requis vu précédemment.
Nous proposons sur notre boutique en ligne la carte Atheros AR9287. Cette carte répond à tous les pré-requis vu précédemment. Elle est garantie 3 ans.
Il existe, bien évidemment, beaucoup d'autres endroits ailleurs sur Internet où acheter une carte Wi-Fi. Nous vous recommandons de vous assurer que la carte que vous choisirez dispose bien d'un chipset Atheros, qu'elle supporte les fonctionnalités détaillées dans cet article et que le revendeur communique les débits attendus en fonctionnement sous pfSense.
Pour aller plus loin
[pfSense] Bien choisir et dimensionner son firewall
[pfSense] Configurer son point d'accès Wi-Fi
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : matérielpfSenseWi-Fi
05/05/2020 - Aucun commentaire
