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
Comprendre l'ordre dans lequel les règles de NAT et de filtrage sont appliquées est important lorsque l'on configure son firewall.
Dans cet article nous détaillons l'ordre dans lequel pfSense applique ses règles de filtrage, de translation de port et de NAT et l'impact que cela a sur l'écriture de nos règles.
1. L'ordre de traitement - schéma global
Un bon schéma étant souvent plus parlant qu'un long texte, l'ordre de traitement des paquets réseaux par pfSense peut se résumer par le schéma suivant :
Ce schéma de fonctionnement présente le cheminement suivi pour le trafic sortant (quittant le réseau local à destination d'Internet) et pour le trafic entrant (depuis Internet vers le réseau local ou une DMZ). Le cheminement est exactement le même dans les deux sens.
Pour chacune des étapes, si aucune règle n'existe, alors celle-ci sera simplement ignorée et pfSense passera à la suivante.
Prenons le cas d'un paquet réseau quittant le LAN à destination d'Internet. En suivant les numéros présents sur notre schéma, l'ordre de traitement détaillé est le suivant :
- tcpdump : réalisé sur l'interface LAN (accessible via l'outil "Packet Capture" du menu "Diagnostics" de pfSense). Lorsque la capture est effectuée sur l'interface LAN (pour un paquet quittant le LAN à destination d'Internet), aucun traitement n'a encore été effectué par pfSense (NAT, filtrage, routage, etc.). Nous capturons donc le paquet "brut" tel qu'il est émis par l'ordinateur. Le détail du fonctionnement de l'outil Packet Capture fera l'objet d'un prochain article.
- Port forward ou 1:1 NAT configurés sur l'interface LAN. On configure rarement des règles de redirection de ports (port forward) ou de NAT 1 pour 1 (1:1 NAT) sur l'interface LAN, mais nous rencontrerons des règles de NAT équivalentes lorsque nous utilisons un proxy ou des redirecteurs DNS. Dans ces cas-là, on parle également de "DNAT" pour Destination NAT ; c'est-à-dire des règles de NAT qui s'appliquent par rapport à l'adresse IP de destination.
- Règles de filtrage configurées pour l'interface LAN. Les règles de filtrage sont appliquées dans l'ordre suivant : règles de floating, règles de groupe d'interfaces, puis finalement les règles de l'interface elle-même.
- 1:1 NAT ou règles d'Outbound NAT configurés sur l'interface WAN. Dans ce cas-là, on parle de "SNAT" pour Source NAT ; c'est-à-dire des règles de NAT qui s'appliquent par rapport à l'adresse IP source. C'est à cette étape que le paquet réseau prend comme adresse IP source l'adresse IP de l'interface WAN de pfSense.
- Règles de filtrage de type floating dans le sens "out" pour l'interface WAN. C'est un cas très spécifique. Pour un usage de base, c'est rarement utilisé. Ces règles de floating peuvent être très utiles lorsque l'on souhaite configurer de la priorisation de trafic sur un environnement multi-VLAN. Il faut garder en tête qu'à cette étape, le NAT sortant (Outbound NAT) a déjà été appliqué et que les adresses IP source des paquets ne sont donc plus les adresses IP privées du LAN, mais l'adresse IP de l'interface WAN (ou celle qui a été configurée dans les règles d'Outbound NAT).
- tcpdump : réalisé sur l'interface WAN. À ce stade, tous les traitements ont été effectués par pfSense (NAT, filtrage, routage, etc.). Nous capturons donc le paquet tel qu'il est transmis vers Internet (ou vers le routeur de l'opérateur, par exemple)
L'outil tcpdump est toujours le premier et le dernier à voir le trafic, en fonction de l'interface sur laquelle il est effectué et de la direction du trafic.
Ainsi, dans le cas d'un trafic du LAN vers le WAN, un tcpdump exécuté sur l'interface LAN verra les paquets réseaux tel qu'ils sont émis par l'ordinateur
Un tcpdump exécuté sur l'interface WAN verra les paquets modifiés par pfSense tel qu'ils sont transmis en sortie de pfSense.
Il s'agit donc d'un outil de diagnostique très pratique dans le suivi de l'acheminement et du traitement des paquets réseaux.
Nous avons pris dans notre exemple le cas d'une architecture simple avec une interface LAN et une interface WAN. Le principe de fonctionnement est exactement le même sur une architecture disposant d'un plus grand nombre d'interfaces réseaux. Les étapes suivies seront toujours les mêmes.
2. Impact sur la configuration de ses règles
Ainsi, pour une interface donnée, les règles de NAT s'appliquent toujours avant les règles de filtrage. C'est la raison pour laquelle il faut adapter ses règles de filtrage avec les bonnes adresses IP sources/destinations.
Prenons un exemple : nous souhaitons rediriger le trafic arrivant sur le port 80 de l'adresse IP publique de notre firewall vers le port 80 d'un serveur local. Le schéma réseau ressemble à celui-ci :
Dans cet exemple, nous allons créer une règle de redirection de port (port forward) depuis le menu Firewall > NAT, puis onglet Port Forward (onglet par défaut) :
Nous cliquons sur le bouton "Add" ; les champs à compléter sont les suivants :
- Disabled : permet de désactiver la règle sans la supprimer. Nous laissons cette case décochée.
- No RDR (NOT) : permet de désactiver la redirection pour le trafic correspondant à cette règle. Cette option sera très peu utilisée dans la pratique. On préférera filtrer/affiner nos règles de redirection via des règles de filtrage.
- Interface : l'interface d'arrivée des paquets. Dans notre exemple, il s'agit de l'interface WAN.
- Protocol : le protocole concerné. Dans notre exemple, nous choisissons TCP.
- Source : il est rarement nécessaire de préciser la source sur une redirection de port pour du trafic entrant. Nous laissons ces champs vides.
- Destination : l'adresse IP de destination sur laquelle le trafic externe arrive. Soit, dans notre cas, l'adresse IP de notre WAN. Nous choisissons donc "WAN Address".
- Destination port range : le port réseau de destination. Dans notre cas, nous souhaitons rediriger le trafic arrivant sur le port 80. Nous pouvons ainsi choisir "HTTP" dans la liste déroulante ou choisir "Other" et indiquer 80 dans le champ Custom.
- Redirect target IP : il s'agit de l'adresse IP privée vers laquelle nous souhaitons rediriger le trafic. Dans notre exemple : 192.168.1.10.
- Redirect target port : le port d'écoute de la machine locale. Il s'agit généralement du même port que celui indiqué précédemment. Dans notre cas "HTTP".
- Description : un champs purement informatif.
- No XMLRPC Sync : cocher cette case pour ne pas synchroniser cette règle vers les autres membres CARP.
- NAT reflection : il s'agit d'un mode avancé permettant à un client interne d'accéder à une ressource interne en passant par son adresse IP externe. Notre exemple ne porte pas sur cet usage, nous laissons la valeur par défaut, "Use system default", ce qui revient à choisir "Disable".
- Filter rule association : cette option permet de laisser pfSense générer la règle de filtrage nécessaire pour le fonctionnement de notre redirection de port. Pour un utilisateur avancé, nous recommandons de choisir "None" et de configurer par soi-même la règle de filtrage afin d'être certains de la positionner là où on le souhaite parmi nos autres règles et de pouvoir la personnaliser si nécessaire. Par simplicité, pour notre exemple, nous laissons le choix par défaut "Add associated filter rule".
Exemple de résultat obtenu :
Sur notre interface WAN, une règle a été créée (si nous avons choisi "None" pour l'option Filter rule association, alors il faut créer soi-même cette règle) :
Nous constatons que l'adresse IP Destination de notre règle de filtrage est l'adresse IP privée (ici, 192.168.1.10). La raison est que le NAT est appliqué avant le filtrage. Ainsi, l'adresse IP de destination du paquet réseau a été modifiée par le firewall et correspond à ce stade à l'adresse IP privée de destination. Le filtrage doit donc bien porter sur l'adresse IP privée de destination.
Il nous reste à penser à cliquer sur "Apply Changes" aussi bien sur la page de gestion des règles de filtrage que sur celle de gestion des règles de NAT.
La redirection de port est en place.
Voila, vous savez maintenant parfaitement l'ordre que suit pfSense pour le traitement des paquets réseaux (NAT, filtrage, routage, etc.).
Nous verrons dans un prochain article la puissante de l'outil "packet capture" intégré à pfSense et la méthodologie d'utilisation que nous proposons pour faire ses analyses réseau.
Pour aller plus loin
[pfSense] Troubleshooting / Dépannage de ses règles de filtrage
Best practices / Recommandations pour la configuration de votre firewall
[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 : NATpfSense
Sous pfSense, et sous la plupart des firewall modernes, il est possible de définir des alias. Ces alias nous seront utiles dans l'implémentation de nos règles de filtrage, de NAT, de redirection de ports, etc.
C'est un outil pratique qui permet de gagner en lisibilité sur nos règles.
Qu'est-ce qu'un alias ?
Sous pfSense, un alias permet de définir un groupe de ports réseaux, d'hôtes ou de sous-réseaux.
Ces alias peuvent ensuite être utilisés dans les règles de filtrage, les règles de redirection de ports, les règles de NAT, etc. Utiliser des alias est une bonne pratique pour disposer de règles claires, courtes, simples et lisibles sur notre firewall.
Il est à noter que certains firewall obligent en la création d'alias pour l'écriture des règles de filtrage (il est impossible de spécifier une adresse IP, il faut avoir préalablement créé un alias contenant cette adresse IP). pfSense n'impose pas ce mode de fonctionnement strict.
Les différents types d'alias
Les alias sont configurables depuis le menu Firewall > Aliases :
Il existe cinq catégories d'alias.
Host
Ce type d'alias peut contenir des adresses IP seules et des noms d'hôtes (hostname). Ces alias s'ajoutent depuis l'onglet "IP".
Lorsque l'on renseigne un nom de domaine, pfSense va le résoudre à intervalle régulier. Par défaut, la fréquence de mise à jour est de 5 minutes. Il est possible de modifier cette fréquence depuis le menu System > Advanced, onglet Firewall & NAT. Il faut personnaliser la valeur du champ "Aliases Hostnames Resolve Interval" :
Network
Ce type d'alias peut contenir des sous-réseaux en notation CIDR, des noms d'hôtes, des plages d'adresses IP ou des adresses IP seules.
Il est également possible de renseigner un intervalle d'adresses IP. Par exemple : 192.168.0.10-192.168.0.30. Il faut laisser le masque sur /32.
Cet intervalle sera traduit en autant de sous-réseaux nécessaires au format CIDR.
Par exemple, si l'on renseigne l'intervalle 10.3.0.100-10.3.0.200 :
Une fois sauvegardé, il sera traduit par pfSense en autant de sous-réseaux :
Port
Ce type d'alias peut contenir une liste de ports réseaux ou une plage de ports réseaux pour TCP et UDP.
Le protocole (TCP, UDP) n'est pas renseigné dans l'alias. Il faudra le préciser (TCP, UDP ou les deux) dans les règles de filtrage ou de NAT qui feront appel à cet alias.
URL
Cet alias est construit à partir du fichier fourni par l'URL indiquée. Attention, ce fichier n'est lu qu'une seule fois lors de la création de l'alias. Il n'est ensuite pas mis à jour automatiquement.
Le fichier doit être au format txt et contenir une information par ligne (une adresse IP par ligne, par exemple).
Chaque URL peut pointer vers un fichier disposant de 3 000 entrées maximum.
URL Table
Cet alias est construit à partir du fichier fourni par l'URL indiquée. Cet alias est mis à jour automatiquement en retournant chercher le fichier fourni par l'URL indiquée. La fréquence de mise à jour se défini en nombre de jours.
Contrairement aux alias de type "URL", il n'y a pas de limite au nombre d'entrées pour chaque fichier (il peut en contenir plusieurs dizaines de milliers).
Techniquement, le package pfBlocker utilise ce type d'alias pour la gestion de ses listes d'adresses IP par pays, par exemple.
Sur la capture d'écran ci-dessus, l'alias est configuré pour être mis à jour tous les 3 jours.
Fonctionnalités avancées sur les alias
Imbrication d'alias
Il est possible d'imbriquer un alias dans un autre alias à condition que les deux alias soient du même type.
Par exemple, si l'on créé un alias "web_server" contenant l'adresse de notre serveur web, un alias "smtp_server" contenant l'adresse de notre serveur SMTP, il est possible de créer un troisième alias contenant les deux alias précédents :
Sur la capture d'écran ci-dessus, l'alias "all_servers" contient les deux alias "web_server" et "smtp_server".
Utilisation des noms d'hôtes dans des alias
Des noms d'hôtes peuvent être utilisés dans des alias. Chaque nom d'hôte sera résolu périodiquement par pfSense pour vérifier son adresse IP correspondante. Si un nom d'hôte dispose de plusieurs adresses IP, alors toutes les adresses IP seront ajoutées à l'alias.
Attention, cette option n'est pas efficace si nous cherchons à autoriser ou interdire l'accès à un site web en particulier (comme par exemple facebook.com). Ces gros sites web disposent bien souvent de mécanismes de répartition de charge par round-robin DNS, ce qui ne permet pas de garantir que pfSense disposera de la totalité des adresses IP associées au nom de domaine concerné.
Cette solution peut donc fonctionner pour des petits sites web, mais pas pour les plus gros.
Alias et IPv6
pfSense supporte pleinement IPv6. Il en est logiquement de même pour les alias.
Il est également possible de mixer la présence d'adresses IPv4 et IPv6 au sein d'un même alias.
Taille maximale des alias
Il n'existe pas de taille maximale théorique. Il faut simplement s'assurer de deux éléments :
1. Être sûrs que la taille des alias n'excède pas la moitié du nombre maximum d'entrées dans la table du firewall (qui est de 200 000, par défaut).
2. Disposer de suffisamment de mémoire-vive sur son firewall. Grosso-modo, en prenant de la marge, il faut compter 1K par entrée.
Utilisation des alias
Les alias peuvent s'utiliser dans les règles de filtrage et de NAT. Ils peuvent être saisis à la place d'une adresse IP ou d'un nom d'hôte.
Par exemple, dans la création de votre règle de filtrage, choisir, pour source ou destination, "Single host or alias" et renseigner le nom de l'alias :
On peut voir sur la capture d'écran ci-dessus que pfSense propose une aide à la saisie par auto-complétion.
Une fois la règle de filtrage saisie, il est possible de visualiser le contenu de l'alias en positionnant le curseur de la souris dessus :
Voilà ! Vous connaissez tout ce qu'il faut savoir sur la gestion des alias sous pfSense.
Pour aller plus loin
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 un support professionnel ? Alors contactez-nous.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : aliaspfSense
Le choix du bon matériel pour accueillir pfSense est toujours délicat. Il n'est pas évident de dimensionner correctement son firewall par rapport à son besoin, ni de choisir les bons composants lorsque l'on souhaite assembler son matériel soi-même.
Nous présentons dans cet article les éléments à prendre en considération pour le dimensionnement de son firewall, ainsi que les points de vigilance à avoir dans le choix des composants.
[Intro] Dimensionner son firewall, qu'est-ce que cela signifie ?
Avant de rentrer dans le vif du sujet, il est important de donner la définition du terme "dimensionner". Dans le choix d'un firewall, il va être important de définir les paramètres suivants :
- Débit attendu : élément essentiel du choix du matériel. Quel débit maximal souhaitons-nous que le firewall puisse supporter ?
- Mémoire-vive : de quelle quantité de mémoire-vive le firewall a-t-il besoin et quel est l'impact des services ou packages que j'active sur la consommation de mémoire ?
- Processeur : comment choisir correctement son processeur pour être sûr qu'il ne soit pas le goulet d'étranglement de mon firewall ?
- Disque-dur : quelle taille de disque-dur prévoir ? Faut-il opter pour un disque-dur SSD ?
Ces éléments sont les principales caractéristiques de dimensionnement à prendre en compte dans le choix de son firewall.
1. Quel débit ?
Le premier élément à prendre en considération est le débit souhaité. Est-ce 100 Mbps ? 1 Gbps ? 10 Gbps ? Ou davantage ?
Il faut également se poser la question de la connectique attendue : Ethernet (RJ45), Fibre Optique, WiFi, ... ?
Le débit standard actuel des réseaux modernes pour des entreprises de type TPE/PME est de 1 Gbps.
C'est un débit suffisant pour offrir de bonnes conditions de travail tout en répondant aux besoins d'évolutivité des débits des prochaines années. C'est donc le débit qu'il conviendra de retenir dans l'immense majorité des usages.
Ainsi, il nous paraît indispensable que votre firewall soit équipé de ports RJ45 Gigabits.
De plus, si votre firewall dispose de plusieurs ports réseaux 1 Gbps, il vous sera possible de faire de l'agrégation de liens afin d'accroître le débit offert (par exemple : 2x1 Gbps, 4x1 Gbps, ...).
Il est important de préciser ici que si votre firewall dispose de ports Gigabits, mais que vos switch disposent uniquement de ports Fast Ethernet (c'est-à-dire fonctionnant au maximum à 100 Mbps), alors le débit maximum que pourra offrir votre firewall sur chacune de ses interfaces connectée au switch sera de 100 Mbps.
Pour un usage intensif, de type très grande entreprise ou Centre de données (data center), il conviendra de prévoir une connectique fibre optique offrant des débits de 10 Gbps ou davantage.
Dans tous les cas, il est parfaitement inutile de voir trop large et de choisir des débits largement surdimensionnés ; cela augmentera sensiblement vos coûts d'acquisition sans aucun bénéfice à l'appui.
Dans l'article [pfSense] Comment bien choisir sa carte Wi-Fi, nous détaillons comment choisir sa carte WiFi pour pfSense afin d'être certain de faire le bon choix.
Enfin, et pour conclure sur le débit, il est important d'avoir conscience que ce n'est pas parce que votre firewall dispose de ports Gigabits que le débit maximum délivré sera d'1 Gbps sur chaque port !
En effet, si les autres composants matériels ne sont pas correctement dimensionnés (CPU trop faible, par exemple), si vous utilisez un VPN à haut niveau de chiffrement sans disposer d'accélération cryptographique ou si vous faites de l'inspection de trafic par exemple, alors le débit risque très fortement d'être ralenti.
D'une façon générale, les modules faisant de l'inspection de trafic (comme squidGuard, Snort, Suricata, ...) vont forcément légèrement ralentir le débit.
La plupart des autres modules disponibles sur pfSense ne vont pas ralentir le débit, mais vont principalement augmenter le besoin en ressource processeur ou en mémoire-vive.
2. L'impact des fonctionnalités sur le dimensionnement
Fonctionnement de base de pfSense
Pour fonctionner correctement, pfSense nécessite dans son installation par défaut de disposer de 256 à 512 Mo de mémoire-vive.
Ensuite, dans le fonctionnement de pfSense (et dans le fonctionnement de n'importe quel autre matériel de type stateful), chaque connexion est suivie dans la table d'état.
Pour chaque connexion, il y a 2 états de stockés dans la table : une pour la connexion entrante sur le firewall, l'autre pour la connexion sortante.
Un exemple simple d'une connexion est un ordinateur connecté sur le réseau local (sur le LAN) qui consulte le site web google.fr.
Attention : si l"utilisateur consulte en parallèle le site wikipedia.fr, alors il consomme une deuxième connexion, etc. Il ne faut donc pas penser qu'un ordinateur = une connexion qui sera stockée dans la table d'état. C'est potentiellement beaucoup plus.
La table d'état est stockée en mémoire-vive. Sa taille a donc un impact sur la mémoire-vive nécessaire. Il faut considérer que la consommation en mémoire-vive est la suivante :
- 50 000 connexions = 100 000 états = ~ 100 Mo de RAM
- 500 000 connexions = 1 000 000 états = ~ 1 Go de RAM
VPN
D'une façon générale, les VPN IPsec offrent un meilleur débit que les VPN OpenVPN.
L'impact du VPN sur le débit maximal possible va dépendre du choix du chiffrement. Si le matériel ne dispose pas d'accélération cryptographique, les débits vont très rapidement s'effondrer. En revanche, si le matériel supporte le jeu d'instruction AES (également appelé AES-NI), alors l'impact sur le débit sera extrêmement minime.
Ainsi, notre recommandation est clairement d'opter pour un processeur supportant l'AES-NI que vous utilisiez ou non la fonctionnalité VPN.
Snort/Suricata
Les modules Snort et Suricata vont avoir une consommation de mémoire-vive de l'ordre de 1 à 2 Go.
Leur impact sur le débit est très dur à quantifier et va dépendre principalement du processeur et du nombre d'instructions d'inspection de trafic qui sera configuré.
Squid
Squid utilise beaucoup le disque-dur (contrairement à pfSense qui, dans son usage par défaut, est très peu consommateur d'espace disque).
La quantité d'espace disque nécessaire va dépendre de la quantité de données que l'on souhaite conserver en cache et se paramètre dans la configuration de squid.
Pour le choix du type de disque-dur, on considère que jusqu'à environ une centaine d'utilisateurs, n'importe quel disque-dur (disposant d'une vitesse de rotation de 7 200 tour/min, qui est le standard) fera l'affaire.
Au-delà, le choix d'un disque SSD est clairement à privilégier. Si vous faites le choix d'un disque-dur SSD, il est indispensable de choisir un disque-dur SSD de qualité, autrement le nombre élevé de lecture-écriture produit par le proxy va provoquer une fin de vie rapide de votre SSD...
Concernant la mémoire-vive consommée par squid, il faut compter environ 15 Mo de mémoire-vive pour 1 Go de cache sur le disque-dur.
Soit, pour un cache de 100 Go, il faut compter 1,5 Go de mémoire-vive.
3. Bien choisir son matériel
Une fois le dimensionnement de son firewall défini, il est important de bien choisir son matériel afin qu'il soit pleinement compatible avec pfSense et pleinement évolutif.
Nos principales recommandations sont :
- Architecture 64 bits : les architectures 32 bits ne sont officiellement plus supportées à la fin du mois d'octobre 2018. Il est indispensable de choisir une architecture 64 bits ;
- Support de l'AES-NI : AES-NI permet une amélioration conséquente des débits offerts sur les connexions VPN. Il est indispensable de choisir un firewall équipé d'un processeur supportant la technologie AES-NI.
Si vous achetez un firewall déjà assemblé pour pfSense :
- Acheter son matériel en France et bénéficiant d'un remplacement/échange sous 24-48h : en cas de panne de votre firewall vous vous retrouvez bloqués (plus d'accès à Internet, plus d'accès distants, plus de VPN, etc.) ; pour les installation critiques, la mise en place de pfSense en haute-disponibilité est très fortement conseillée ; pour les autres installations, il est indispensable de pouvoir obtenir un matériel de remplacement rapidement ;
- Disposer d'une garantie matérielle d'au moins 3 ans : c'est la garantie que les composants sont tous de qualité ;
- Éviter les plateformes type Ebay, alibaba, etc. : les délais de livraisons sont très longs, vous risquez d'avoir à régler des droits de douane et des frais de dédouanement et la garantie sera compliquée à mettre en œuvre si votre matériel tombe en panne après plusieurs mois de fonctionnement ;
- Choisir un revendeur de confiance : il vous proposera du matériel de qualité et un service après-vente performant en cas de besoin.
Où acheter son firewall pour pfSense ?
De notre expérience, nous estimons qu'il existe aujourd'hui 2 solutions :
1/ Acquérir du matériel officiel vendu par la société Netgate (éditeur du logiciel pfSense). L'avantage est que vous bénéficiez du matériel officiel avec la garantie absolue qu'il est totalement supporté par l'éditeur. Les inconvénients principaux à nos yeux sont : les durées de garantie extrêmement courtes, le temps nécessaire pour un échange, le prix.
Boutique en ligne Netgate : https://store.netgate.com
2/ Acquérir du matériel vendu par Provya : face au besoin de disposer de matériel fiable et économique et au manque de solutions qui étaient disponibles sur le marché, nous avons décidé de façonner notre propre matériel, avec des composants de qualité et au meilleur coût. L'assemblage, le support et la garantie sont effectués par nos soins depuis la France ; tous nos matériels sont garantis 3 ans avec remplacement/échange en 24-48h, et les composants sont choisis avec soin pour fonctionner au mieux et durablement avec pfSense (support AES-NI, disque SSD de qualité, ...).
Boutique en ligne Provya : https://store.provya.fr
Vous avez maintenant toutes les cartes en main pour dimensionner correctement votre firewall pour pfSense !
Pour aller plus loin
[pfSense] Comment bien choisir sa carte Wi-Fi
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 un support professionnel ? Alors contactez-nous.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : matérielpfSense
En informatique, il est important d'avoir ses équipements (ordinateurs, serveurs, routeurs, switch, etc.) qui soient toujours à l'heure. Pour cela, il est possible d'utiliser le protocole NTP et envoyer ses requêtes vers un serveur NTP public ou bien alors d'utiliser une puce GPS !
Dans cet article, nous présenterons comment installer et utiliser une clé GPS avec pfSense afin qu'il soit toujours à l'heure et l'intérêt de cette méthode par rapport à d'autres.
Être à l'heure : pourquoi ?
Tout équipement informatique dispose d'un horloge matérielle ou logicielle à laquelle il fait référence pour horodater des fichiers, des transactions, des courriers électroniques, des baux DHCP, des autorisations d'accès, etc.
Cette horloge, aussi précise soit-elle va dériver dans le temps comme toute montre ordinaire. Ceci va poser des problèmes de sécurité, notamment en terme de traçabilité et d'auditabilité. Ainsi que des problèmes de contrôles des accès.
Pour pallier ce problème, il est possible d'utiliser des serveurs de temps de référence qui seront interrogés via le protocole NTP. De nombreux serveurs NTP sont accessibles en libre accès sur Internet et il est également possible d'implémenter son propre serveur NTP.
pfSense peut parfaitement servir de serveur NTP interne pour vos équipements. Pour garder notre serveur pfSense à l'heure, il est nécessaire soit de le synchroniser avec un autre serveur NTP de référence (accessible via Internet), soit de lui ajouter une clé GPS afin qu'il se synchronise par satellite. Cette seconde solution offre généralement une meilleure précision sur le temps fourni et permet surtout d'être indépendant de tous serveurs NTP externes.
La solution GPS, généralement peu connue du grand public et des PME, est celle majoritairement adoptée par les Grands comptes et par les Datacenters.
Activer le service NTP et la clé GPS sur pfSense
La première étape consiste à activer le service NTP pour que pfSense joue le rôle de serveur NTP pour les équipements du réseau. Pour cela, nous nous rendons dans le menu Services > NTP :
Nous sommes redirigés par défaut sur l'onglet Settings. Les paramètres à configurer sont les suivants :
- Interface : précise la ou les interfaces sur laquelle pfSense va agir en tant que serveur NTP. Dans notre exemple, nous choisissons les interfaces LAN et WIFI. Il est à noter que pour des raisons de sécurité, il ne faut pas rendre accessible par Internet le service NTP de pfSense.
- Time Servers : la liste de serveurs NTP avec lesquels pfSense pourra se synchroniser. Après avoir installé la clé GPS, ces serveurs serviront de serveurs de secours en cas de panne ou de défaillance de la clé GPS. Dans notre cas, nous utilisons le pool de serveurs par défaut 0.pfsense.pool.ntp.org. Si vous choisissez d'autres serveurs NTP, veillez à ajouter un pool ou une liste d'au moins 4 ou 5 serveurs.
Il reste à cliquer sur le bouton "Save" en bas de page.
Exemple de résultat obtenu :
Nous basculons sur l'onglet "Serial GPS". Les paramètres à configurer sont les suivants :
- GPS Type : sélectionnez votre modèle de GPS s'il figure dans la liste. Dans notre cas, il n'apparaît pas, nous choisissons donc Default.
- Serial Port : le port sur lequel le GPS est connecté. S'il s'agit d'un port série, le nom du port aura pour forme cuau (cuau0, cuau1, ...). S'il s'agit d'un port USB, le nom aura pour forme cuaU (cuaU0, cuaU1, ...). Dans notre cas, notre clé GPS étant connectée sur un port USB, nous choisissons cuaU0.
- Fudge Time 2 : ce champ permet de préciser un offset pour notre clé GPS. Si votre GPS est branché sur un port série, il faut laisser ce champ vide. En revanche, si vous utilisez un GPS connecté sur un port USB, alors il est nécessaire de préciser un offset de 0,5 seconde afin de compenser la latence introduite par le port USB. Dans notre cas, notre clé GPS étant connectée sur un port USB, nous indiquons la valeur 0.5.
- Flags : s'assurer que la case "Prefer this clock" soit bien cochée (par défaut).
Il reste à cliquer sur le bouton "Save" pour valider sa configuration et c'est tout ! Notre clé GPS est prête à fonctionner.
Exemple de résultat obtenu :
Vérifier le bon fonctionnement
Pour vérifier le bon fonctionnement du service NTP, se rendre dans le menu Status > NTP.
Exemple dans notre cas :
On peut voir que la clé GPS est le peer actif pour servir de référence de temps à pfSense.
On peut voir que le pool 0.pfsense.pool.ntp.org comporte bien plusieurs serveurs de temps joignables (4 sur la capture d'écran) prêts à prendre le relais en cas de problème avec la puce GPS.
On peut également voir la localisation (latitude et longitude) de sa clé GPS, avec un lien vers Google Maps.
Sur la capture d'écran suivante, on peut constater un problème avec la clé GPS (statut False Ticker) et qu'un serveur NTP tiers à pris le relais :
Cela arrive si votre clé GPS n'arrive pas à capter correctement le signal satellitaire ou si vous avez oublié de saisir un offset de 0,5 seconde pour un GPS connecté en USB.
Comment choisir sa clé GPS compatible pfSense
Pour le choix de sa clé GPS, il est indispensable de s'assurer que celle-ci soit compatible avec le logiciel pfSense et qu'elle dispose d'un câble suffisamment long. Ce qui n'est pas le cas de toutes les puces GPS...
Nous proposons sur notre boutique en ligne une clé GPS connectable en USB et 100% compatible avec les systèmes pfSense, FreeBSD et Linux. D'autres choix sont bien-sûr possibles. Il faut simplement s'assurer que la clé GPS choisie soit bien compatible.
Pour aller plus loin
[pfSense] Bien choisir et dimensionner son firewall
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] Configuring High Availability.
Dans cet article, nous allons voir comment configurer deux serveurs pfSense en mode cluster afin d'assurer un service en haute-disponibilité.
Il est à noter que pfSense est l'une des rares solutions open-source offrant des techniques de haute-disponibilité permettant de garantir que le firewall ne puisse pas être un point individuel de défaillance (SPOF).
Dans cet article, nous nous baserons sur l'architecture suivante pour réaliser nos configurations :
pfSenseA - WAN : 172.25.46.101
pfSenseB - WAN : 172.25.46.102
@IP virtuelle - WAN : 172.25.46.100
pfSenseA - LAN : 192.168.0.11
pfSenseB - LAN : 192.168.0.12
@IP virtuelle LAN : 192.168.0.10
Principe de fonctionnement
pfSense communique sur les réseaux LAN & WAN avec ses adresses IP virtuelles ; il n'utilise jamais l'adresse IP assignée à son interface.
En cas de défaillance de pfSenseA (pfSense primaire), pfSenseB (pfSense secondaire) prend le relais sans aucune interruption de service. La bascule de pfSenseA vers pfSenseB est totalement transparente.
Afin d'assurer la réplication du serveur pfSenseA vers le serveur pfSenseB, 3 éléments doivent être configurés : CARP, pfsync et XML-RPC.
CARP
CARP (Common Address Redundancy Protocol) est un protocole permettant à plusieurs hôtes présents sur un même réseau de partager une adresse IP.
Ici, nous utilisons CARP afin de partager une adresse IP WAN et une adresse IP LAN sur nos serveurs pfSense.
C'est cette adresse IP virtuelle que pfSense va utiliser pour sa communication sur le réseau. Ainsi, en cas de défaillance du pfSense primaire (pfSenseA), le pfSense secondaire (pfSenseB) prendra le relais de manière transparente au niveau réseau (reprise de l'adresse IP virtuelle).
pfsync
pfsync est un protocole permettant de synchroniser entre deux serveurs pfSense l'état des connexions en cours (et de manière plus large entre deux serveurs exécutant le firewall Packet Filter). Ainsi, en cas de défaillance du serveur primaire, l'état des connexions en cours est maintenu sur le serveur secondaire. Il n'y a donc pas de coupure liée à la bascule des services du pfSenseA vers le pfSenseB.
Il est recommandé d'effectuer cette synchronisation sur un lien dédié entre les deux serveurs pfSense. À défaut, le lien LAN peut être utilisé.
La réplication peut se faire d'un serveur primaire vers un ou plusieurs autres serveur(s).
XML-RPC
XML-RPC est un protocole permettant la réplication de données d'un serveur vers un autre. Il est utilisé dans pfSense afin de répliquer la configuration du serveur primaire vers le serveur secondaire.
Pour garantir son bon fonctionnement, il est important qu'il utilise la même interface que celle utilisée par le protocole pfsync.
1. Configurer les adresses IP virtuelles
Afin de fonctionner, chaque serveur pfSense doit disposer d'une adresse IP sur son interface, ainsi qu'une adresse IP virtuelle qui sera partagée entre les deux serveurs pfSense. De ce fait, nous utilisons 3 adresses IP par réseau.
Pour configurer l'adresse IP virtuelle, se rendre dans "Firewall" > "Virtual IPs" :
Cliquer sur l'icône "+ Add" pour ajouter une adresse IP virtuelle.
Les éléments à configurer sont les suivants :
- Type : ici, nous avons quatre possibilités :
- IP Alias
- CARP
- Proxy ARP
- Other
Nous choisissons "CARP". Nous ne rentrons pas ici dans le détail de l'usage de chaque option. Pour plus d'informations, nous vous invitons à lire l'article What are Virtual IP Addresses - EN.
- Interface : l'interface sur laquelle la VIP doit être configurée. Nous configurons la première sur l'interface WAN, puis la seconde sur l'interface LAN.
- Address(es) : l'adresse VIP et le masque du subnet de l'interface. Dans notre exemple : 172.25.46.100 et /24
- Virtual IP Password : mot de passe permettant de sécuriser les échanges au sein du groupe d'hôtes se partageant la VIP. Ce mot de passe devra être re-saisi sur le pfSense secondaire.
- VHID Group : Virtual Host Identifier. Un serveur peut faire parti de plusieurs groupes de VIP. Afin d'identifier chaque groupe, un ID unique lui est assigné. Nous laissons la valeur par défaut.
- Advertising Frequency : la valeur du champ "Skew" à 0 désigne le master (pfSense primaire). Une valeur plus élevée désignera l'esclave (pfSense de secours). La valeur de "Base" correspond au timeout en seconde au bout duquel l'hôte sera considéré comme inaccessible. Nous recommandons de laisser la valeur par défaut : 1.
Exemple de résultat obtenu :
Nous procédons à la même configuration sur l'interface LAN.
Enfin, nous réalisons les mêmes configurations sur les interfaces WAN et LAN du serveur de secours (pfSenseB), en pensant bien à passer la valeur du champ "Skew" à 1.
Nous pouvons vérifier l'état de nos adresses IP virtuelles depuis le menu "Status"> "CARP (failover)" :
Dans le cas présent, les deux adresses VIP créées ont bien le statut "master" sur le pfSenseA :
2. Forcer l'utilisation des adresses IP virtuelles
Les adresses VIP sont déclarées, mais non-utilisées. Il reste à configurer pfSense pour qu'il utilise les adresses VIP plutôt que les adresses IP attribuées à ses interfaces logiques.
Pour cela, nous devons configurer pfSense pour qu'il utilise l'adresse VIP WAN sur le trafic sortant, l'adresse VIP LAN pour le trafic entrant et configurer les différents services pour qu'ils travaillent avec l'adresse VIP LAN comme adresse par défaut (pour les configuration OpenVPN ou DHCP, par exemple).
Configuration du NAT
Nous allons dans le menu Firewall > NAT. Dans l'onglet Outbound, nous cochons la case "Hybrid Outbound NAT rule generation. (Automatic Outbound NAT + rules below)".
Nous modifions les règles ou en ajoutons une afin que le trafic sortant utilise l'adresse VIP. Les champs à configurer sont les suivants :
- Disabled : cocher cette case pour désactiver la règle sans devoir la supprimer.
- Do not NAT : cocher cette case permet de désactiver le NAT pour le trafic correspondant à cette règle. Il est très rare de devoir cocher cette case.
- Interface : l'interface logique sur laquelle nous souhaitons définir notre règle de NAT. Dans notre cas, nous choisissons "WAN".
- Protocol : les protocoles concernés par cette règle de NAT. Nous choisissons "any"
- Source : le réseau source. Dans notre cas, il s'agit du réseau local, nous saisissons donc "192.168.0.0" et "/24" pour le masque.
- Destination : le réseau de destination. Dans notre cas, nous choisissons "any".
- Address : l'adresse à utiliser lors du NAT. Nous choisissons l'adresse VIP créée précédemment, soit "172.25.46.100 (VIP WAN)".
- Port : nous laissons ce champ vide.
- No XMLRPC Sync : cocher cette case pour ne pas copier la règle sur le pfSense secondaire. Nous laissons cette case non-cochée.
- Description : un champ informatif
Exemple de résultat obtenu :
Cette configuration n'est à faire que sur le pfSense primaire. La configuration sera dupliquée automatiquement sur le pfSense secondaire.
Configuration du service DHCP
Si pfSense fait office de serveur DHCP, nous allons dans le menu "Services" > "DHCP Server". Nous modifions le champ "Gateway" pour y préciser l'adresse VIP (192.168.0.10). Autrement, le serveur DHCP de pfSense va continuer à indiquer aux clients du service DHCP l'adresse IP de l'interface LAN du pfSense.
Nous pouvons également compléter le champ "Failover peer IP" en renseignant l'adresse IP de l'interface LAN du pfSense secondaire (192.168.0.12). Cette configuration optionnelle permet de partager les leases DHCP entre le pfSense primaire et le pfSense secondaire.
Attention, si ce champ est renseigner, il est nécessaire de modifier la valeur du "skew" du pfSense secondaire pour le passer à un nombre supérieur à 20.
Davantage d'informations sur la configuration du service DHCP : [pfSense] Configurer son serveur DHCP.
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 l'adresse VIP (172.25.46.100).
Cette modification s'opère dans "VPN" > "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 l'adresse VIP (172.25.46.100).
Cette modification s'opère dans "VPN" > "IPsec". La modification s'effectue sur la phase 1.
Davantage d'informations sur la configuration du service VPN IPsec : [pfSense] Configurer un VPN IPsec site à site.
3. Configurer la haute-disponibilité
Il nous reste à configurer la haute-disponibilité. Pour cela, se rendre dans "System" > "High Avail. Sync" :
Depuis cette page, il y a 2 éléments à configurer : la partie pfsync (pour la synchronisation d'état) et XMLRPC Sync (pour la synchronisation de la configuration).
State Synchronization Settings (pfsync)
Les éléments à configurer sont les suivants :
- Synchronize States : cocher cette case pour activer pfsync (cette configuration est à faire sur le pfSense primaire et sur le pfSense secondaire)
- Synchronize Interface : l'interface de synchronisation. Si nous disposons d'une interface dédiée à la synchronisation, nous la choisissons ; autrement, nous choisissons "LAN".
- pfsync Synchronize Peer IP : sur le pfSense primaire, saisir l'adresse IP du serveur pfSense de secours (192.168.0.12). Si pour le choix de l'interface (ci-dessus) nous avons choisi "LAN", nous indiquons l'adresse IP de l'interface LAN du pfSense secondaire (192.168.0.12) ; si nous avons choisi une interface dédiée alors nous indiquons l'adresse IP de l'interface dédiée du pfSense secondaire. Par défaut, si aucune adresse IP n'est saisie, pfSense diffusera en multicast sur l'interface choisie préalablement. Sur le pfSense secondaire, on indique l'adresse IP du pfSense primaire (192.168.0.11)
Configuration Synchronization Settings (XMLRPC Sync)
- Synchronize Config to IP : sur le serveur pfSense primaire, saisir l'adresse IP du serveur pfSense secondaire (comme précédemment, il faut saisir l'adresse IP de l'interface choisie). Ce doit être la même adresse IP que celle renseignée dans le champ "pfsync Synchronize Peer IP". Ce champ doit être laissé vide sur le serveur pfSense secondaire.
- Remote System Username : sur le serveur pfSense primaire, saisir le nom d'utilisateur utilisé pour se connecter sur le WebGUI du pfSense de secours ("admin" par défaut). Ce champ doit être laissé vide sur le serveur pfSense de secours.
- Remote System Password : sur le serveur pfSense primaire, saisir le mot de passe du compte utilisateur saisi ci-dessus. Ce champ doit être laissé vide sur le serveur pfSense de secours.
Puis, nous choisissons les services que nous souhaitons synchroniser en cochant les cases appropriées. Par défaut, nous recommandons de tout cocher (Toggle All).
Exemple de résultat obtenu :
Autoriser les flux de réplication au niveau des règles du firewall
Il nous reste à autoriser les flux de réplications sur les firewall. La configuration se passe dans "Firewall" > "Rules".
Si la réplication se fait via l'interface LAN, les règles de firewall sont à appliquer sur cette interface ; si nous utilisons une interface dédiée, les règles seront à appliquer sur celle-ci.
Il y a deux flux réseau à autoriser :
- le flux pour la synchronisation XML-RPC qui s'effectue via le port 443
- le flux pour la synchronisation du protocole pfsync
Sur le firewall primaire, nous créons donc une première règle de firewall (en cliquant sur le bouton "Add") avec les paramètres suivants :
- Action : nous choisissons "Pass"
- Interface : nous choisissons l'interface dédiée à la réplication si le pfSense en possède une. Autrement, nous choisissons "LAN"
- Address Family : nous laissons "IPv4"
- Protocol : nous choisissons "TCP"
- Source : nous indiquons un alias qui contiendra les adresses IP des interfaces de synchronisation de chaque pfSense (dans notre cas, cet alias contiendra les adresses IP "192.168.0.11" et "192.168.0.12"). Si cette notion d'alias n'est pas claire pour vous, vous pouvez consulter notre article dédié [pfSense] Tout comprendre aux alias, ou vous pouvez choisir l'ensemble du réseau rattaché à l'interface de synchronisation (dans notre cas, ce serait "LAN net")
- Destination : nous choisissons "This firewall (self)"
- Destination port range : choisir "HTTPS (443)"
Exemple de résultat obtenu :
Sur le firewall primaire toujours, nous créons une seconde règle de firewall avec les paramètres suivants :
- Action : nous choisissons "Pass"
- Interface : nous choisissons l'interface dédiée à la réplication si le pfSense en possède une. Autrement, nous choisissons "LAN"
- Address Family : nous laissons "IPv4"
- Protocol : nous choisissons "PFSYNC"
- Source : nous indiquons un alias qui contiendra les adresses IP des interfaces de synchronisation de chaque pfSense (dans notre cas, cet alias contiendra les adresses IP "192.168.0.11" et "192.168.0.12"). Si cette notion d'alias n'est pas claire pour vous, vous pouvez choisir l'ensemble du réseau rattaché à l'interface de synchronisation (dans notre cas, ce serait "LAN net")
- Destination : nous choisissons "This firewall (self)"
Exemple de résultat obtenu :
Ces deux règles de firewall ont été répliquées automatiquement sur le pfSense secondaire.
4. Vérifier le bon fonctionnement de la haute-disponibilité
L'ensemble doit, à ce stade, être opérationnel. Vérifions !
Vérifier le statut du CARP (adresse VIP)
Nous pouvons vérifier l'état de nos adresses IP virtuelles depuis le menu "Status"> "CARP (failover)" :
Les adresses VIP doivent avoir le statut "MASTER" sur le pfSense primaire et "BACKUP" sur le pfSense secondaire.
Vérifier la réplication
Nous pouvons naviguer dans le menu "Firewall" > "Rules" et "Firewall" > "NAT" et vérifier que les règles créées sur le pfSense primaire sont bien présentes également sur le pfSense secondaire.
Faire des tests !
Avant toute chose, à ce stade, il est important de faire une sauvegarde de vos serveurs pfSense ("Diagnostics" > "Backup & Restore").
Ensuite, pour tester le bon fonctionnement de la haute-disponibilité, plusieurs tests peuvent être réalisés. En voici quelques exemples :
- arrêter le pfSense primaire
- débrancher le câble réseau de l'interface LAN ou WAN du pfSense primaire
- désactiver le service CARP sur le pfSense primaire ("Status" > "CARP (failover)")
- télécharger un fichier ou lancer des requêtes ping lors de la bascule du primaire vers le secondaire
Pour aller plus loin
[pfSense] Comprendre la gestion des interfaces réseaux
[pfSense] Configurer son serveur DHCP
[pfSense] Tout comprendre aux alias
[pfSense] Mettre à jour son serveur pfSense
[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Configurer un dual-WAN (plusieurs connexions Internet)
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 : failoverpfSense
28/01/2020 - Aucun commentaire
