Provya

Sécurité et téléphonie

Articles & Tutoriaux  -  Liens & Actualités

[pfSense] Votre interface est parfois lente ? C'est peut-être lié à ce bug non-corrigé

icon 26/11/2019 - 2 commentaires

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.

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.

Dashboard vide de pfSense - Provya

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.

Menu System > General Setup - gestion des DNS - pfSense - Provya

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".

Désactiver l'interface WAN sous pfSense - Provya



=> 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.

Extrait capture tcpdump depuis wireshark - bug pfSense - Provya

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 :

Recherche bug pfSense sous GitHub - Provya


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

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 :

Menu Services > DNS Resolver sous pfSense - Provya


Nous ajoutons une entrée de type Host overrides (en bas de page) en cliquant sur le bouton "+Add" :

Ajouter une entrée DNS (host overrides) sous pfSense - Provya


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 :

Exemple de l'ajout d'une entrée DNS (host overrides) sous pfSense - Provya


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


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

Découvrez nos firewall SSD pour pfSense, assemblés en France, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :

[pfsense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense

icon 19/11/2019 - 2 commentaires

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 :

Schéma de traitement NAT et filtrage par pfSense - Provya


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 :

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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).
  6. 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 :

Schéma réseau de redirection d'un port entrant sous pfSense - Provya


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) :

Menu Firewall > NAT - Port Forward - pfSense - Provya


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 :

Exemple de configuration d'une redirection de port sous pfSense - Provya


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) :

Exemple d'une règle de filtrage pour une redirection de port sous pfSense - Provya


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


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

Découvrez nos firewall SSD pour pfSense, assemblés en France, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :

[pfSense] Tout comprendre aux alias

icon 05/11/2019 - Aucun commentaire

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 :

Menu Firewall > Aliases - pfSense - Provya


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".

Exemple d'un alias de type host ou IP - pfSense - Provya


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" :

Personnaliser la fréquence de rafraîchissement d'un alias - pfSense - Provya




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 :

Exemple intervalle adresses IP alias - pfSense - Provya


Une fois sauvegardé, il sera traduit par pfSense en autant de sous-réseaux :

Exemple intervalle adresses IP alias - pfSense - Provya




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).

Exemple alias d'URL d'adresses IP - pfSense - Provya


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.

Exemple alias d'URL d'adresses IP table - pfSense - Provya


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 :

Imbrication d'alias sous pfSense - Provya


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 :

Utilisation des alias dans les règles de filtrage sous pfSense - Provya


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 :

Visualisation des alias dans les règles de filtrage sous pfSense - Provya



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


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

Découvrez nos firewall SSD pour pfSense, assemblés en France, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :

[pfSense] Gardez son firewall toujours à l'heure avec une puce GPS

icon 15/10/2019 - Aucun commentaire

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 :

Service > NTP - pfSense - Provya


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 :

Configuration service NTP pfSense - Provya


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 :

Configuration GPS service NTP pfSense - Provya




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 :

Status GPS service NTP pfSense - Provya


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 :

Status GPS - False Ticker service NTP pfSense - Provya


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


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

Découvrez nos firewall SSD pour pfSense, assemblés en France, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :

[pfSense] Faire un pont réseau (bridging) entre deux interfaces

icon 01/10/2019 - Aucun commentaire

Dans son mode de fonctionnement par défaut, chaque interface de pfSense dispose de son propre plan d'adressage qui doit être unique.

Il est parfois nécessaire de disposer du même plan d'adressage sur plusieurs interfaces. C'est pratique pour disposer d'un seul sous-réseau pour son LAN et son Wi-fi, pour disposer du même réseau multicast ou encore pour mettre en place un firewall transparent sur un réseau sans avoir à modifier le plan d'adressage existant (en faisant un pont entre l'interface LAN et WAN, par exemple).

Il est très facile de mettre en œuvre un pont réseau entre plusieurs interfaces sur pfSense et de continuer à disposer, si on le souhaite, de règles de filtrage entre ces interfaces.

Dans cet article nous configurerons un pont réseau entre notre interface LAN et notre interface Wi-fi. Ainsi, ces deux interfaces disposeront du même plan d'adressage IP et du même domaine de broadcast.



1. Préparation des interfaces membres du pont-réseau

Chaque interface que nous souhaitons ajouter à notre pont réseau doit être créée et ne pas avoir d'adresse IP. Ce point est important. Ainsi, si nous souhaitons ajouter notre interface LAN à un pont réseau, il est indispensable de faire les configurations depuis une autre interface (depuis l'interface WAN, par exemple, sur laquelle nous aurons temporairement autorisé l'accès à l'interface d'administration du pfSense).

Exemple de configuration pour les interfaces LAN et WIFI :

Configuration des interfaces LAN et WIFI pour un bridge - pfSense - Provya


Pour rappel : [pfSense] Configurer son point d'accès Wi-Fi



2. Configuration du pont-réseau

Une fois ces deux éléments de configuration réalisés, nous nous rendons dans le menu Interfaces > Assignments, puis onglet Bridges :


Menu Interfaces > Assignments > Bridges - pfSense - Provya


Nous cliquons sur le bouton "+Add". La configuration est la suivante :

  • Member Interfaces : les interfaces membres du pont-réseau. Dans notre cas, LAN et WIFI
  • Description : une description facultative
  • Advanced Options : suivant votre configuration, il peut être pertinent d'activer le protocole Spanning Tree (RSTP/STP). Pour un pont entre un réseau filaire et sans-fil, cela n'est pas forcément nécessaire. Dans notre cas, nous ne modifions pas les options avancées.

Exemple de résultat obtenu :

Création d'une interface bridge - pfSense - Provya


Nous cliquons sur le bouton "Save" pour valider notre configuration. Et notre port réseau BRIDGE0 est créé. Il nous reste à lui associer une interface logique afin de pouvoir le configurer (pour rappel, pour bien comprendre la différence entre ports réseaux, interfaces logiques, interfaces virtuelles, etc. vous pouvez consulter notre article dédié : [pfSense] Comprendre la gestion des interfaces réseaux.

Nous retournons dans l'onglet Interface Assignments, puis nous cliquons sur le bouton "+Add" après avoir pris soin de sélectionner notre interface BRIDGE0 :

Associer une interface à un pont réseau sous pfSense - Provya


Il nous reste à configurer cette interface en lui précisant son adresse IP et en lui donnant un nom.
Exemple de résultat obtenu :

Configurer son interface sous pfSense - Provya


Point d'attention : vous pouvez remarquer que sur la capture d'écran, nous avons configuré le champ "MAC Address". La raison est que si ce champ est laissé vide, l'adresse MAC d'une interface "pont-réseau" est générée aléatoirement à la création de l'interface et lors du redémarrage du firewall. Le problème est que les ordinateurs qui tournent sous un Windows récent (Vista et suivants) utilisent l'adresse MAC de la gateway comme identifiant du réseau. Ainsi, si l'adresse MAC change, les ordinateurs Windows estimeront qu'il s'agit d'un nouveau réseau et demanderont à leurs utilisateurs de le paramétrer en précisant s'il s'agit d'un réseau privé/public/etc. En forçant l'adresse MAC, nous évitons ce problème.

Notre pont-réseau est créé. La configuration des services devra être effectuée pour cette interface (dans notre cas "LANFI") : DHCP, firewall, DNS, NTP, etc.

Il reste une dernière subtilité importante : le filtrage.



3. Configuration du filtrage (subtilité à connaître)

Par défaut, pfSense applique les règles de filtrage uniquement sur les interfaces des membres du pont-réseau et non pas sur l'interface du pont-réseau elle-même.

Cela signifie que, dans notre cas, par défaut, uniquement les règles de filtrage définies sur les interfaces LAN et WIFI sont prises en compte par pfSense. Les règles que nous pourrions créer sur l'interface LANFI seront ignorées !

Ce comportement par défaut permet d'avoir des règles de filtrages différentes pour chaque interface membre du pont.
Il est possible de modifier ce comportement afin que les règles de filtrage définies sur l'interface du pont-réseau soient prises en compte.
Cette modification s'opère depuis le menu System > Advanced, onglet System Tunables :

Menu System > Advanced - onglet System Tunables - pfSense - Provya


  • le paramètre net.link.bridge.pfil_member : active le filtrage sur l'interface de chaque membre du pont-réseau lorsqu'il est positionné à 1
  • le paramètre net.link.bridge.pfil_bridge : active le filtrage sur l'interface du pont-réseau lui-même lorsqu'il est positionné à 1

règles de filtrage pour bridge - pfSense - Provya


Il faut donc positionner la valeur du paramètre net.link.bridge.pfil_bridge à 1 si nous souhaitons appliquer nos règles de filtrage sur l'interface du pont-réseau.

Enfin, il faut garder en tête que seul le pont-réseau dispose d'une adresse IP sur son interface. Ainsi si nous souhaitons appliquer des règles de filtrages directement sur chaque interface membre du pont, nous pouvons travailler avec les valeurs LANFI_net et LANFI_address, mais pas LAN_net, WIFI_net, LAN_address et WIFI_address (car celle-ci ne sont pas définies).



4. Les limites

Il existe quelques limites à l'utilisation d'un pont-réseau sous pfSense. Les principales limites ou contraintes sont les suivantes :

Portail captif

Pour que le portail captif fonctionne correctement, il est important que la passerelle par défaut des clients soit l'adresse IP de l'interface du pont-réseau. Ainsi, il n'est pas possible de mettre en œuvre un portail captif sur un pfSense où le LAN et le WAN seraient liés en un pont-réseau.


Haute-disponibilité

Il est plutôt déconseillé d'utiliser des pont-réseaux dans un environnement en haute-disponibilité. Cela peut créer des dysfonctionnements ou des boucles réseaux. Si vous souhaitez absolument utiliser un environnement pfSense en haute-disponibilité avec des pont-réseaux, il est indispensable que le protocole Spanning Tree soit activé sur vos switch et sur le pont-réseau.


Multi-WAN

Comme pour le portail captif, il faut s'assurer que la passerelle par défaut des clients soit l'adresse IP de l'interface du pont-réseau. Autrement, vous risquez de rencontrer un problème de routage asymétrique.


Proxy transparent

Idem. Il faut s'assurer que la passerelle par défaut des clients soit l'adresse IP de l'interface du pont-réseau. De plus, un package comme Squid ne peut pas fonctionner dans un scénario de firewall transparent où les interfaces LAN et WAN sont liées sur un même pont-réseau.


Voilà ! Notre pont réseau est fonctionnel et vous connaissez les subtilités à connaître pour sa configuration.



Pour aller plus loin

[pfSense] Configurer son point d'accès Wi-Fi
[pfSense] Comprendre la gestion des interfaces réseaux


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

Découvrez nos firewall SSD pour pfSense, assemblés en France, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :

[pfSense] La gestion des certificats pour les connexions OpenVPN

icon 17/09/2019 - 2 commentaires

Il existe plusieurs méthodes pour monter un tunnel VPN site-à-site avec OpenVPN. Les deux principales consistent en l'utilisation de clés partagées ou en l'utilisation de certificats (X.509).

Après notre premier article sur la configuration d'OpenVPN avec clé partagée, nous abordons ici sa configuration avec la gestion des certificats.

Article mis à jour le  : 17/09/2019

À noter : nous ne détaillons pas dans cet article tous les détails de configuration d'OpenVPN. Nous nous concentrons sur la création, l'utilisation et la révocation des certificats. Il existe déjà un article dédié à la configuration d'OpenVPN : [pfSense] Monter un accès OpenVPN site-à-site.



Principe de fonctionnement

Le client et le serveur OpenVPN sont authentifiés à l'aide de certificats. Pour cela, ces certificats doivent être émis par une autorité de certification reconnue comme sûre aussi bien par le serveur que par le client.

Dans notre cas, nous créerons une autorité de certification (appelée "CA" pour Certificate Authority) sur le pfSense faisant office de serveur. Puis nous créerons deux certificats : un certificat client (qui sera utilisé côté Client) et un certificat serveur (qui sera utilisé côté Serveur). Ces deux certificats seront signés par l'autorité de certification que nous aurons créé précédemment.

Pour signer un certificat, il est nécessaire de disposer de la clé privée de l'autorité de certification.
Pour valider la signature d'un certificat, il est nécessaire de disposer de la clé publique de l'autorité de certification.



Création d'une autorité de certification - CA

Actions à effectuer coté serveur OpenVPN

Pour commencer, nous nous rendons dans le menu System > Cert Manager :

menu Cert. Manager - pfSense - Provya


Dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur le bouton "+ Add" se trouvant en bas à droite de la liste des CAs existants.

Les champs à renseigner sont les suivants :
  • Descriptive name : le nom que l'on souhaite donner à notre autorité de certification
  • Method : 3 méthodes sont possibles :
  1. Create an internal Certificate Authority : permet de créer une nouvelle autorité de certification
  2. Import an existing Certificate Authority : permet d'importer le certificat (clé publique + clé privée) d'une autorité de certification existante
  3. Create an intermediate Certificate Authority : permet de créer une autorité de certification intermédiaire. Cette autorité de certification intermédiaire doit être rattachée à une autorité de certification existante
Dans notre cas, côté serveur, nous créerons une nouvelle autorité de certification (Create an internal Certificate Authority). Côté client, nous importerons la clé publique de l'autorité de certification créée côté serveur (Import an existing Certificate Authority).
  • Key length : la longueur de la clé de chiffrement du certificat. Nous gardons la valeur par défaut : 2048
  • Digest Algorithm : la fonction de hachage qui sera utilisée. Nous gardons la valeur par défaut : SHA256
  • Common Name : le nom du certificat sans espaces, ni caractères spéciaux ou accentués. Ce nom doit être unique.
  • Lifetime : la durée de vie de l'autorité de certification. Si nous n'avons pas de raison de réduire sa durée de vie, nous laissons la valeur par défaut (10 ans)
  • Autres champs : l'ensemble des champs suivants sont principalement cosmétiques et doivent permettre d'identifier l'organisation. Ils peuvent être laissés vides ou complétés.

Exemple de résultat obtenu :

exemple création autorité de certification (CA) pfSense - Provya


Nous validons notre configuration en cliquant sur le bouton "Save".

Notre autorité de certification est créée.



Création d'un certificat serveur

Nous restons dans le menu System > Cert Manager et basculons sur l'onglet "Certificates" (deuxième onglet).
Pour créer un nouveau certificat (client ou serveur), nous cliquons sur le bouton "+ Add/Sign" se trouvant en bas à droite de la liste des certificats existants.

Les champs à renseigner sont les suivants :
  • Method : 4 méthodes sont possibles :
  1. Create an internal Certificate : permet de créer une nouveau certificat
  2. Import an existing Certificate : permet d'importer la clé publique et la clé privée d'un certificat existant
  3. Create a certificate Signing Request : permet de créer un fichier de requête qui pourra être envoyé à un CA tiers pour être signé. Cela peut être utile pour obtenir un certificat d'un CA root de confiance.
  4. Sign a Certificate Signing Request : permet de signer un fichier de requête
Dans notre cas, nous créons un nouveau certificat (Create an internal Certificate).
  • Descriptive name : le nom que l'on souhaite donner à notre certificat serveur
  • Certificate authority : l'autorité de certification qui signera le certificat que nous sommes en train de créer. Dans notre cas, nous choisissons le CA que nous venons de créer, soit "CA Provya"
  • Key length : la longueur de la clé de chiffrement du certificat. Nous gardons la valeur par défaut : 2048
  • Digest Algorithm : la fonction de hachage qui sera utilisée. Nous gardons la valeur par défaut : SHA256
  • Lifetime : la durée de vie du certificat. Si nous n'avons pas de raison de réduire sa durée de vie, nous laissons la valeur par défaut (10 ans)
  • Common Name : le nom du certificat sans espaces, ni caractères spéciaux ou accentués. Ce nom doit être unique.
  • Autres champs : l'ensemble de ces champs sont principalement cosmétiques et doivent permettre d'identifier l'organisation émettrice du certificat. Ils peuvent être laissés vides ou complétés.
  • Certificate Type : le type de certificat. Il existe 2 valeurs possibles :
  1. User Certificate : pour définir un certificat pour un client
  2. Server Certificate : pour définir un certificat pour un serveur
Dans notre cas, nous choisissons "Server Certificate".

Exemple de résultat obtenu :

Exemple de configuration certificat serveur OpenVPN - pfSense - Provya


Nous validons notre configuration en cliquant sur le bouton "Save".

Notre certificat pour le serveur OpenVPN est créé.



Création d'un certificat client

Nous procédons exactement de la même manière que pour la création d'un certificat serveur. Le seul élément distinctif est le champ Certificate Type pour lequel nous choisissons "User Certificate".

Exemple de résultat obtenu :

Exemple de configuration certificat client OpenVPN - pfSense - Provya


Nous validons notre configuration en cliquant sur le bouton "Save".

Notre certificat pour le client OpenVPN est créé.



Configuration du serveur OpenVPN

Le détail de la configuration du serveur OpenVPN se trouve dans l'article dédié [pfSense] Monter un accès OpenVPN site-à-site.

Les différences au moment de la configuration sont les suivantes :
  • Server Mode : choisir "Peer to Peer (SSL/TLS)"
  • TLS Configuration : cocher la case "Use a TLS Key" pour davantage de sécurité. Nous conseillons de la cocher. La clé TLS sera générée automatiquement. Il restera à la copier côté client.
  • Peer Certificate Authority : choisir l'autorité de certification créée précédemment ("CA Provya")
  • Server Certificate : choisir le certificat serveur créé précédemment ("Certificat serveur OpenVPN Provya (Server: Yes, CA: CA Provya)")
  • DH Parameters Length : Nous laissons la valeur par défaut (1024 bits)

Exemple de résultat obtenu :

Exemple de configuration serveur OpenVPN avec certificat sur pfSense - Provya


La configuration coté serveur OpenVPN est terminée. Il reste à faire la configuration côté client.



Export des certificats

Nous devons exporter le certificat de l'autorité de certification (c'est-à-dire sa clé publique), ainsi que le certificat et la clé privée du client OpenVPN.

Pour cela, nous retournons dans le menu System > Cert Manager :

menu Cert. Manager - pfSense - Provya


Dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur l'icône "Export CA" de l'autorité de certification que nous avons créée précédemment :

Export du certificat d'une autorité de certificat sous pfSense - Provya



Puis, dans l'onglet "Certificates", nous cliquons successivement sur les icônes "Export Certificate" et "Export Key" du certificat client que nous avons créé précédemment :

Export clé et certificat client pour OpenVPN - pfSense - Provya


La configuration côté serveur OpenVPN est terminée.

Maintenant, nous procédons à l'import des clés publiques/privées et à la configuration côté client OpenVPN.



Import de la clé publique du CA sur le pfSense client OpenVPN

Actions à effectuer coté client OpenVPN

Nous nous rendons dans le menu System > Cert Manager :

menu Cert. Manager - pfSense - Provya


Dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur le bouton "+ Add" se trouvant en bas à droite de la liste des CAs existants.

Nous allons importer la clé publique du CA que nous avons créé sur le serveur OpenVPN.
Les champs à remplir sont les suivants :
  • Descriptive name : le nom que l'on souhaite donner à notre autorité de certification. Nous gardons le même que celui qui a été donné sur le serveur OpenVPN ("CA Provya")
  • Method : nous choisissons "Import an existing Certificate Authority"
  • Certificate data : on copie dans ce champ le contenu de la clé publique (.crt)
  • Certificate Private Key (optional) : si l'on souhaite importer la clé privée (.key), elle est à copier dans ce champ. Dans notre cas, nous le laissons vide. En effet, nous ne souhaitons pas signer de nouveaux certificats (nécessite la clé privée de l'autorité de certification), nous souhaitons seulement valider la signature du certificat qu'utilise le serveur OpenVPN (nécessite la clé publique de l'autorité de certification)
  • Serial for next certificate : ce champ est à remplir uniquement si l'on importe une clé privée. Dans ce cas, il est important que chaque certificat créé par un CA dispose d'un numéro de série unique (autrement, nous risquons de rencontrer des problèmes en cas de révocation de certificat). Il faut donc choisir une valeur suffisamment grande (supérieure au nombre de certificat déjà créé par ce CA) afin d'éviter toute collision.

Exemple de résultat obtenu :

Import du certificat d'une autorité de certification sous pfSense - Provya


Nous validons en cliquant sur le bouton "Save".



Import de la clé publique et de la clé privée du certificat client OpenVPN

Nous restons dans le menu System > Cert Manager et basculons sur l'onglet "Certificates" (deuxième onglet).
Nous cliquons sur le bouton "+ Add/Sign" se trouvant en bas à droite de la liste des certificats existants.

Nous allons importer la clé publique et la clé privée du certificat client que nous avons créé sur le pfSense serveur OpenVPN.
Les champs à remplir sont les suivants :
  • Method : on choisit "Import an existing Certificate"
  • Descriptive name : le nom que l'on souhaite donner à notre certificat. Nous gardons le même que celui qui a été donné sur le serveur OpenVPN ("Certificat client OpenVPN Provya")
  • Certificate data : on copie dans ce champ le contenu de la clé publique (.crt)
  • Private key data : on copie dans ce champ le contenu de la clé privée (.key)

Exemple de résultat obtenu :

Import d'un certificat client OpenVPN sous pfSense - Provya


Nous validons en cliquant sur le bouton "Save".



Configuration du client OpenVPN

Le détail de la configuration du client OpenVPN se trouve dans l'article [pfSense] Monter un accès OpenVPN site-à-site.

Les différences au moment de la configuration sont les suivantes :
  • Server Mode : choisir "Peer to Peer (SSL/TLS)"
  • TLS Configuration : cocher la case "Use a TLS Key" pour davantage de sécurité. Décocher la case "Automatically generate a TLS Key", et copier dans le champ "TLS Key" la clé TLS qui a été généré côte serveur OpenVPN.
  • Peer Certificate Authority : choisir l'autorité de certification importée précédemment ("CA Provya")
  • Client Certificate : choisir le certificat client importé précédemment ("Certificat client OpenVPN Provya")
  • DH Parameters Length : Nous laissons la valeur par défaut (1024 bits)

Exemple de résultat obtenu :

Exemple de configuration client OpenVPN avec certificat sur pfSense - Provya


Nous validons en cliquant sur le bouton "Save".



Révocation de certificat

Le dernier élément, pour être complet sur la gestion des certificats, est la liste de révocation de certificats ou "Certificate Revocation Lists" (CRLs).

Cette liste de révocation contient les certificats qui ne doivent plus être considérés comme sûrs (car ils ont été compromis ou pour n'importe quelle autre raison).
Pour les connexions OpenVPN, la CRL peut être utilisée par le serveur pour vérifier les certificats utilisés par les clients OpenVPN.

Une CRL est signée par un CA. Ainsi, pour générer une CRL, il est nécessaire de disposer de la clé privée du CA.

Généralement, une seule CRL est maintenue par CA. Cependant, pfSense peut en maintenir davantage.
Néanmoins, une seule CRL pourra être sélectionnée par instance OpenVPN.
Ce fonctionnement permet, par exemple, d'empêcher un certificat de se connecter à une instance OpenVPN, mais de l'autoriser à se connecter à une autre instance.

Une CRL peut être soit créée, soit importée. La configuration se fait dans le menu System > Cert Manager depuis l'onglet "Certificate Revocation" (troisième onglet).

Pour ajouter une nouvelle CRL, nous cliquons sur le bouton "+ Add or import CRL" correspondant au CA qui signera cette CRL (dans notre cas, "CA Provya"). Les champs à renseigner sont les suivants :
  • Method : deux méthodes sont possibles :
  1. Create an internal Certificate Revocation List : permet de créer une nouvelle CRL (nécessite de disposer de la clé privée du CA)
  2. Import an existing Certificate Revocation List : permet d'importer une CRL générée depuis un serveur tiers (disposant de la clé privée du CA)
  • Descriptive name : le nom de notre CRL. On y inclut généralement une référence au nom du CA et/ou l'usage de cette CRL
  • Certificate Authority : le CA qui a signé ou va signer cette CRL
  • Lifetime : la durée de vie de la CRL (10 ans par défaut)
  • Serial : le numéro de série de la CRL (0 par défaut pour la première)

Exemple de résultat obtenu :

Création d'une CRL (Certificate Revocation Liste) sous pfSense - Provya


Notre CRL est créée. On peut maintenant lui ajouter les certificats à révoquer. Pour cela, cliquer sur l'icône "Edit CRL" :

Modifier CRL sous pfSense - Provya


Il reste à choisir le certificat à révoquer, la raison de la révocation (ce champ est purement informatif) et cliquer sur le bouton "ADD".

Enfin, dans la configuration de notre serveur OpenVPN, nous devons ajouter cette CRL (champ "Peer Certificate Revocation List").


Voilà ! Notre serveur OpenVPN est prêt à fonctionner avec des certificats.



Pour aller plus loin

[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Monter un VPN natté (Overlap network) avec OpenVPN


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

Découvrez nos firewall SSD pour pfSense, assemblés en France, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :

[pfSense] Comprendre la gestion des interfaces réseaux

icon 03/09/2019 - 6 commentaires

La gestion des interfaces réseaux sous pfSense peut être quelque peu déroutante pour un débutant. Nous présentons ici les rappels de base et les cas d'utilisation de chaque type d'interface.

Article mis à jour le  : 03/09/2019


Il existe 3 types d'interfaces sous pfSense :

  • interface physique : correspond aux interfaces physiques réelles du serveur sur lequel tourne pfSense. Ces interfaces sont généralement nommées re0, re1 (pour des interfaces Realtek), igb0, igb1 (pour des interfaces Intel Gbps), etc.
  • interface virtuelle : ces interfaces sont automatiquement créées lors de la création d'un VLAN, d'un serveur OpenVPN, etc. Elles sont donc associées à un service.
  • interface logique : ce sont les interfaces que nous pouvons configurer (attribution d'adresse IP, règle de filtrage du firewall, etc.). Ces interfaces sont associées à une interface physique ou virtuelle.

Les deux premiers types d'interfaces (interface physique et interface virtuelle) sont appelés "ports réseaux".

Une interface logique doit être associée à un port réseau.

Un port réseau (c'est-à-dire une interface physique ou virtuelle) ne peut être associé qu'à une seule interface logique (c'est-à-dire configurable).



Interfaces physiques

Une interface physique correspond à une carte réseau du serveur pfSense.
Ces interfaces sont nommées en fonction de leur driver. Par exemple : re0, re1, igb0, igb1, ath0, etc. Elles sont identifiées par leur adresse MAC.

Lors de l'installation de pfSense, il est proposé de configurer les interfaces. Ce sont des interfaces logiques. Elles sont créées, configurées et associées aux interfaces physiques.
Ainsi, dans le cas d'un pfSense disposant de deux interfaces (une interface LAN et une interface WAN), on pourrait avoir l'association suivante :

WAN [interface logique] = igb0 [port réseau]
LAN [interface logique] = igb1 [port réseau]

Il est également possible de retrouver cette association depuis le menu Interfaces > Assignments :

menu Interfaces > Assignement - pfSense - Provya




Interfaces virtuelles

Ces interfaces sont créées lors de l'activation de certains services (VLAN, OpenVPN).

La configuration d'un serveur OpenVPN entraîne automatiquement la création d'une interface virtuelle associée à cette instance serveur OpenVPN. L'interface virtuelle sera nommée ovpns1, ovpns2, etc...

Cette interface n'est pas configurable en l'état : ce n'est qu'un port réseau. Il est nécessaire de l'associer à une interface logique afin de pouvoir lui associer des règles de firewall ou de NAT spécifiques.

Lorsque nous procédons à cette association, nous obtenons l'exemple suivant :

association interfaces réseau - pfSense - Provya


Dans la capture d'écran ci-dessus, nous voyons que l'interface logique "OPT2" est associée à l'interface virtuelle "ovpns1" qui a été créée lors de la configuration du serveur OpenVPN "VPN Provya".

De la même façon, la création d'un VLAN entraîne la création d'une interface virtuelle (qui sera nommée VLAN1, VLAN2, etc.).
Cette interface virtuelle devra être associée à une interface logique afin de pouvoir lui associer des règles de firewall ou de NAT spécifiques.



Interfaces logiques

Les interfaces logiques sont les interfaces configurables. Ce sont ces interfaces que nous allons pouvoir configurer : associer une adresse IP ; activer un serveur DHCP ; configurer des règles de firewall ou de NAT ; etc.

Ainsi, lors de la configuration d'un service (DHCP, OpenVPN, Portail Captif, etc.) les interfaces proposées seront toujours les interfaces logiques.

Les interfaces logiques les plus connues sont LAN et WAN.

Une interface logique est obligatoirement associée à un port réseau (c'est-à-dire à une interface physique ou virtuelle).



Groupe d'interfaces

Un groupe d'interfaces rassemble plusieurs interfaces logiques.
Ce groupe est donc un groupe logique auquel on peut appliquer des règles de firewall ou de NAT.

L'utilisation d'un groupe d'interfaces est utile si l'on dispose de plusieurs interfaces logiques sur lesquelles nous souhaitons appliquer exactement les mêmes règles.
Ainsi, les règles de firewall définies pour ce groupe s'appliqueront à toutes les interfaces du groupe.

La création de groupe d'interfaces se fait dans le menu Interfaces > Assignments, puis l'onglet "Interface Groups" :

menu Interface Groups - pfSense - Provya


L'ajout se fait en cliquant sur le bouton "+ Add".

Nous renseignons le nom du groupe d'interfaces, une description (facultative) et la liste des interfaces faisant partie du groupe :

création groupe interfaces - pfSense - Provya


Ce groupe d'interfaces sera visible dans les onglets du firewall :

règles de filtrage pour groupe interfaces - pfSense - Provya


Il est à noter qu'au niveau du firewall, ce sont les règles du groupe d'interfaces qui sont vérifiées, avant les règles de l'interface logique.

D'une façon générale, les règles de vérification du firewall s'opèrent dans l'ordre suivant :
  1. Règles définies en Floating
  2. Règles définies sur les groupes d'interfaces
  3. Règles définies sur les interfaces logiques



Cas particulier : OpenVPN

Lors de la création d'une instance serveur ou client OpenVPN, hormis les interfaces virtuelles (ovpns1 ou ovpnc1), un groupe d'interfaces nommé "OpenVPN" est automatiquement créé.

Les configurations réalisées sur ce groupe "OpenVPN" s'appliquent à l'ensemble des services OpenVPN (c'est-à-dire tous les serveurs ou tous les clients OpenVPN configurés).

Si nous souhaitons une granularité de configuration par instance OpenVPN, alors nous devons créer une interface logique pour chaque interface virtuelle OpenVPN existante.



Cas d'application

Lors de la configuration d'un service (DHCP, OpenVPN, Portail Captif, etc.) les interfaces proposées seront toujours les interfaces logiques.
Pour les services dont la configuration peut se faire pour plusieurs interfaces (une règle de firewall, par exemple), il sera également proposé les groupes d'interfaces.

Il existe deux cas particuliers à noter : la configuration des clients ou serveurs OpenVPN et IPsec.
Pour ces services, le choix de l'interface sera :
  1. les interfaces logiques
  2. les groupes de gateway
  3. les adresses VIP
  4. l'interface localhost
  5. toutes les interfaces logiques existantes (choix "any")
Les groupes d'interfaces ne seront pas proposés.


Nous voila maintenant armés pour bien comprendre et configurer correctement les services sur les bonnes interfaces réseau !



Pour aller plus loin

Best practices / Recommandations pour la configuration de votre firewall
[pfSense] Bien choisir et dimensionner son firewall


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

Découvrez nos firewall SSD pour pfSense, assemblés en France, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :

[pfSense] Configurer la priorisation de trafic avec CBQ

icon 28/08/2019 - 12 commentaires

pfSense offre plusieurs mécanismes de priorisation de trafic. Après notre premier article présentant le mode de fonctionnement des trois principaux mécanismes de priorisation ([pfSense] Comprendre la priorisation de trafic), nous procédons dans cet article à sa mise en application à l'aide du protocole CBQ.

Article mis à jour le  : 28/08/2019

Si nos besoins en règles de priorisation de trafic sont des besoins traditionnels, il est conseillé de travailler avec CBQ.

Nous ne détaillerons pas ici le mode de fonctionnement de CBQ, ni ses avantages ou inconvénients. Nous traiterons d'un cas pratique de mise en application sous pfSense et des bonnes pratiques à respecter.
Le mode de fonctionnement de CBQ est présenté dans notre article dédié : [pfSense] Comprendre la priorisation de trafic



Généralités sur la priorisation de trafic

Pour la mise en place de la priorisation de trafic, nous allons configurer d'un côté des queues (file d'attente) et de l'autre des rules (règles d'affectation des paquets dans ces files d'attente) :
  • Queues : "file d'attente" à laquelle est associée une priorité de traitement et une bande passante
  • Rules : "règle d'affectation" définissant la queue par laquelle un paquet 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.

La priorité de traitement la plus forte doit toujours être donnée aux applications nécessitant un traitement temps-réel. Typiquement, la VoIP.

La priorité suivante doit toujours être donnée aux acquittements TCP (ACK). Les ACK correspondent à des sortes d'accusé de réception sur les données transmises en TCP. Il est important que ces paquets soient prioritaires car autrement l'émetteur considérera que les paquets envoyés n'ont pas été correctement reçus et procédera à leur réémissions. Ce qui, par effet boule de neige, augmentera la charge sur la ligne Internet.

On considère que la bande passante nécessaire pour les ACK est de 10 à 15% du débit maximum offert en dowload (nous verrons en fin d'article comment affiner ce réglage).

Enfin, par convention de nommage, les queues commencent toujours par la lettre "q" (ex : qVoIP, qACK, qDefault, ...).
Pour le nommage des queues, et afin de facilité la lisibilité, nous recommandons l'utilisation du lowerCamelCase.



Cas d'application

Nous partirons du cas d'application suivant : une entreprise disposant d'une connexion Internet SDSL de 3Mbps sur laquelle transite sa téléphonie (VoIP) vers son opérateur SIP et le reste de sa data (surf, messagerie, etc.).

Le besoin est de prioriser sa téléphonie afin de garantir la qualité des communications et de disposer d'une répartition dynamique de sa bande passante.

Nous respecterons le principe KISS et mettrons en place les trois queues suivantes :
  • qVoIP : ce sera la queue réservée à la téléphonie
  • qACK : ce sera la queue réservée aux paquets ACK
  • qDefaut : la queue par défaut par laquelle nous ferons passer le reste du trafic

Il est important de démarrer avec un nombre de queues réduit et sur des règles d'affectation simples. Puis, de procéder à du fine-tuning si nécessaire.

La queue qVoip disposera de la priorité la plus forte et d'une bande passante de 1Mbps (ce qui correspond environ à 10 appels simultanés avec le codec G.711)
La queue qACK disposera de la priorité suivante et d'une bande passante de 10% du débit max en download, soit 300Kbps.
Enfin, la queue qDefaut disposera d'une priorité assez faible (et du reste de la bande passante) permettant l'ajout ultérieur de queues avec des priorités intermédiaires en cas de besoin.



Configuration des queues

Nous commençons par la configuration des queues sur l'interface WAN.

Se rendre dans le menu Firewall > Traffic Shaper :

menu Firewall > Traffic Shaper pfSense - Provya


Dans l'onglet « By Interface » (celui par défaut), cliquer sur « WAN » :

création file de priorisation de trafic pfSense - Provya


Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la priorisation de trafic sur l'interface WAN
  • Scheduler Type : choisir "CBQ"
  • Bandwidth : indiquer le débit max en download diminué de 10% (soit 2700Kbps)
  • Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
  • TBR Size : laisser vide

Cliquer sur le bouton "Save" pour valider la configuration.

Exemple de résultat obtenu :

détails configuration priorisation de trafic pfSense - Provya


À noter : ne pas tenir compte pour le moment du message nous invitant à appliquer les changements. Nous le ferons lorsque nous aurons fini de configurer l'ensemble des queues.

Nous allons maintenant créer les queues. Pour cela, se repositionner sur l'interface "WAN" :

création file de priorisation de trafic pfSense - Provya


Puis cliquer sur le bouton "Add new Queue".

Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la file d'attente
  • Queue Name : le nom de la file d'attente. Ici, ce sera "qVoIP"
  • Priority : on choisit "7"
  • Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
  • Scheduler options : laisser vide
  • Description : une description optionnelle
  • Bandwidth : la bande passante allouée à la queue. Dans notre exemple, "1000 Kbps"
  • Scheduler specific options : cocher cette case afin d'activer le partage dynamique de bande-passante pour cette queue

Cliquer sur le bouton "Save" pour valider la configuration.

Exemple de résultat obtenu :

création file qVoIP QoS pfSense - Provya


Notre première queue est créée. Pour la création de la suivante, nous nous repositionnons sur l'interface WAN (l'icône a pris la forme d'un dossier) :

dossier queue wan QoS pfSense - Provya


Puis cliquer sur le bouton "Add new Queue".

Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la file d'attente
  • Queue Name : le nom de la file d'attente. Ici, ce sera "qACK"
  • Priority : on choisit "6"
  • Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
  • Scheduler options : laisser vide
  • Description : une description optionnelle
  • Bandwidth : la bande passante allouée à la queue. Dans notre exemple, "300Kbps"
  • Scheduler specific options : cocher cette case afin d'activer le partage dynamique de bande-passante pour cette queue

Cliquer sur le bouton "Save" pour valider la configuration.

Exemple de résultat obtenu :

création file qACK QoS pfSense - Provya


Notre seconde queue est créée. Pour la création de la troisième et dernière queue (la queue par défaut), nous nous repositionnons sur l'interface WAN.
Puis nous cliquons sur le bouton "Add new Queue".

Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la file d'attente
  • Queue Name : le nom de la file d'attente. Ici, ce sera "qDefaut"
  • Priority : on choisit "2"
  • Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
  • Scheduler options : cocher la case "Default Queue"
  • Description : une description optionnelle
  • Bandwidth : la bande passante allouée à la queue. Dans notre exemple, "1400Kbps"
  • Scheduler specific options : cocher cette case afin d'activer le partage dynamique de bande-passante pour cette queue

Cliquer sur le bouton "Save" pour valider la configuration.

Exemple de résultat obtenu :

création file qDefaut QoS pfSense - Provya


L'ensemble de nos queues côté WAN est créé. Nous disposons de 3 queues :
  1. qVoIP : pour le trafic à destination ou en provenance du fournisseur SIP
  2. qACK : pour le trafic ACK (acquittement TCP)
  3. qDefaut : pour le reste du trafic

Nous allons maintenant activer la priorisation de trafic sur l'interface LAN. Cliquer sur "LAN" :

création file de priorisation de trafic QoS pfSense - Provya


Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la priorisation de trafic sur l'interface LAN
  • Scheduler Type : choisir "CBQ"
  • Bandwidth : indiquer le débit max en upload diminué de 10% (soit 2700Kbps)
  • Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
  • TBR Size : laisser vide

Cliquer sur le bouton "Save" pour valider la configuration.

Exemple de résultat obtenu :

détails configuration priorisation de trafic QoS pfSense - Provya


Nous allons maintenant dupliquer les queues créées sur l'interface WAN vers l'interface LAN. Se rendre dans l'onglet "By Queue" :

menu By Queue QoS pfSense - Provya


Sélectionner la queue "qVoIP", puis, dans la section "LAN", choisir "Clone Shaper on this interface" :

cloner QoS entre interfaces pfSense - Provya


Procéder de la même manière avec les queues "qACK" et "qDefaut".

Nos queues sont toutes créées :

afficher liste des queues QoS pfSense - Provya


Nous validons l'ensemble de ces paramétrages en cliquant sur le bouton "Apply Changes" :

Bouton Apply changes pfSense - Provya




Configuration des rules

Nous allons maintenant créer les règles d'affectation du trafic dans ces queues.
La configuration s'effectue au niveau des règles du Firewall. Elle peut s'effectuer directement depuis les règles existantes, ou en créant des règles génériques sur l'interface "Floating".

Les règles de vérification du Firewall s'opèrent dans l'ordre suivant :
  1. Règles définies en Floating
  2. Règles définies sur les groupes d'interfaces
  3. Règles définies sur les interfaces logiques

Pour un rappel sur le mode de fonctionnement des interfaces réseaux ou groupe d'interfaces sous pfSense, se référer à l'article dédié [pfSense] Comprendre la gestion des interfaces réseaux.

Dans notre cas, nous ne toucherons pas aux règles de filtrage en place sur nos interfaces ou groupe d'interfaces, mais nous créerons des règles spécifiques d'affectation du trafic depuis l'interface "Floating".
C'est ce que nous recommandons de faire systématiquement. Ainsi, nous ne mélangeons pas la partie "filtrage firewall" de la partie "règles de priorisation de trafic".

Pour cela, se rendre dans le menu "Firewall" > "Rules", puis sur l'onglet "Floating" :

menu Firewall Rules Floating pfSense - Provya


La méthode de création des règles de firewall depuis l'onglet "Floating" est exactement la même que pour n'importe quelle interface. La seule différence est la présence de l'action "Match".

L'action "Match" signifie qu'aucune décision ne sera prise quant à l'acceptation (Pass) ou au refus (Block ou Reject) du paquet, mais que s'il correspond (="match") aux critères définis (adresse IP source ou destination, port source ou destination, système d'exploitation, protocole, etc.), alors il se verra appliquer les options définies dans les "Advanced Options" (comme les queues d'affectation ou la gateway, par exemple).

Si nous reprenons notre exemple, nous devons créer les règles suivantes :
  1. Une première règle pour diriger le trafic en provenance de l'opérateur de VoIP vers la queue "qVoIP"
  2. Une seconde règle pour diriger le trafic à destination de l'opérateur de VoIP vers la queue "qVoIP"
  3. Une dernière règle pour diriger tous les paquets ACK du trafic TCP vers la queue "qACK"

Nous créons notre première règle en cliquant sur le bouton "Add" et renseignons les champs comme suit :
  • Action : nous choisissons "Match"
  • Interface : nous choisissons l'interface "WAN"
  • Direction : nous choisissons "in" (c'est-à-dire arrivant sur l'interface WAN)
  • Protocol : nous choisissons "UDP" (les protocoles de VoIP SIP et RTP utilisant UDP)
  • Source : nous choisissons "Single host or alias" et renseignons l'adresse IP du serveur VoIP de l'opérateur

Exemple de résultat obtenu :

règle de floating QoS pfSense - Provya


Puis, dans la section "Advanced Options", nous cliquons sur le bouton "Display Advanced" et localisons en bas de page la ligne "Ackqueue / Queue". La première liste déroulante correspond à la queue d'acquittement (paquets ACK), la seconde liste déroulante correspond à la queue en tant que telle.

On ne peut choisir une "Ackqueue" (première liste déroulante), que si on a choisi une queue (seconde liste déroulante).

Ici, nous choisissons la queue "qVoIP" et nous laissons l'Ackqueue à "none" (les protocoles de VoIP SIP et RTP utilisant UDP).

Exemple de résultat obtenu :

advanced options pour règle de floating QoS pfSense - Provya


Enfin, nous cliquons sur "Save" pour valider la règle.
Voila notre première règle créée :

exemple règle floating qVoIP pour QoS pfSense - Provya


Nous créons une nouvelle règle en cliquant sur le bouton "Add".

Nous renseignons les champs comme suit :
  • Action : nous choisissons "Match"
  • Interface : nous choisissons l'interface "WAN"
  • Direction : nous choisissons "out" (c'est-à-dire sortant par l'interface WAN)
  • Protocol : nous choisissons "UDP"
  • Destination : nous choisissons "Single host or alias" et renseignons l'adresse IP du serveur VoIP de l'opérateur
Dans la section "Advanced Options", nous cliquons sur le bouton "Display Advanced", puis localisasons la ligne "Ackqueue / Queue".
Nous laissons la première liste déroulante à "none", et choisissons "qVoIP" pour la seconde.

Exemple de résultat obtenu :

exemple 2 règle floating qVoIP pour QoS pfSense - Provya


Nous cliquons sur "Save" pour valider la règle.

Nous créons enfin la dernière règle en cliquant sur le bouton "Add".

Nous renseignons les champs comme suit :
  • Action : nous choisissons "Match"
  • Interface : nous choisissons les interfaces "WAN" et LAN
  • Protocol : nous choisissons "TCP"
Dans la section "Advanced features", nous cliquons sur le bouton "Advanced" se trouvant sur la ligne "Ackqueue/Queue".
Nous choisissons "qACK" dans première liste déroulante à "none", et choisissons "qDefaut" dans la seconde.

On clique sur "Save" pour valider la règle.

Exemple de résultat obtenu :

exemple règle floating qACK et qDefaut pour QoS pfSense - Provya


Nos trois règles d'affectation sont créées. Nous cliquons sur "Apply changes" pour valider la configuration.

exemple complet priorisation de trafic QoS pfSense - Provya




Remise à zéro de la table d'état

Les règles de priorisation de trafic ne s'appliquent que sur les nouvelles connexions. Les connexions en cours (visibles dans la table d'état) ne sont pas impactées par les règles que nous venons de créer.
Aussi, pour que ces règles soient prises en compte totalement, il est nécessaire de vider la table d'état.

Pour cela, se rendre dans le menu "Diagnostics" > "States".
Cliquer sur l'onglet "Reset States", puis sur le bouton "Reset" :

Reset table d'états pfSense - Provya


À noter : la page va charger sans fin. Ce comportement est normal : l'état de la connexion entre notre navigateur et le pfSense vient d'être réinitialisé.
Il suffit de rafraîchir la page pour continuer.



Analyse et Debug

Les statistiques d'utilisation des queues se trouvent dans le menu "Status" > "Queues" :

menu Status Queues pfSense - Provya


Si l'on voit des "drops" de paquets (avant-dernière colonne du tableau) dans une des queues prioritaires (qVoIP ou qACK), cela signifie que la bande passante qui leur est allouée est trop faible et qu'il faut, a priori, l'augmenter.

En revanche, avoir du drops de paquets dans les queues disposant d'une priorité faible (qDefaut) est normal : en cas de saturation de la ligne Internet, ces queues ne sont pas prioritaires.


La priorisation de trafic est maintenant en place sur notre pfSense !



Pour aller plus loin

[pfSense] Comprendre la priorisation de trafic
[pfSense] Utiliser les limiters pour contrôler la bande-passante par utilisateur


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

Découvrez nos firewall SSD pour pfSense, assemblés en France, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :

[pfSense] Mettre à jour son serveur pfSense

icon 20/08/2019 - Aucun commentaire

Il est important de conserver une version de pfSense à jour sur ses firewall en production.
Nous présentons ici la procédure que nous utilisons lors de la mise à jour d'un pfSense standalone ou d'un cluster de pfSense.

Article mis à jour le  : 20/08/2019



1. Procédure de mise à niveau pour un pfSense seul

Dans le cas d'un serveur pfSense fonctionnant de manière autonome, la mise à jour va s'effectuer en 3 étapes :
  1. Sauvegarde de la configuration : permettra un retour-arrière rapide en cas de problème
  2. Mise à jour du serveur pfSense
  3. Sauvegarde de la configuration après la mise à jour : permet de bénéficier d'une sauvegarde à jour de la configuration en cas de panne ultérieure

  • Sauvegarde de la configuration
Se rendre dans le menu Diagnostics > Backup/Restore :

menu Backup Restore pfSense - Provya


Dans le champ "Backup configuration" > "Backup area" choisir "ALL", laisser coché la case "Do not backup RRD data", et décoché les deux autres cases, puis cliquer sur "Download Configuration as XML" :

Exemple configuration backup pour pfSense - Provya



  • Mise à jour du serveur pfSense
Naviguer dans le menu System > Update :

menu System Update pfSense - Provya


Puis cliquer sur "Upgrade now" pour lancer la mise à jour.

Lors de la mise à jour, une coupure de service est à prévoir (redémarrage du serveur pfSense possible).


  • Sauvegarde de la configuration après la mise à jour
Refaire une sauvegarde en suivant la procédure décrite précédemment.

La mise à jour du serveur pfSense est terminée !



2. Procédure de mise à niveau d'un cluster de pfSense

Dans le cas de serveurs pfSense fonctionnant en redondance, la mise à jour va s'effectuer de la manière suivante :
  1. Faire une sauvegarde du pfSense secondaire
  2. Lancer la mise à jour du pfSense secondaire
  3. Une fois la mise à jour du pfSense secondaire complète, faire une sauvegarde du pfSense primaire
  4. Désactiver CARP sur le pfSense primaire => les adresses VIP vont basculer sur le pfSense secondaire
  5. Lancer la mise à jour du pfSense primaire

  • Sauvegarde de la configuration du pfSense secondaire
Se rendre dans le menu Diagnostics > Backup/Restore :

menu Backup Restore pfSense - Provya



Dans le champ "Backup configuration" > "Backup area" choisir "ALL", cocher la case "Do not backup RRD data", décocher les deux autres cases, puis cliquer sur "Download Configuration" :

Exemple configuration backup pour pfSense - Provya



  • Mise à jour du serveur pfSense secondaire
Naviguer dans le menu System > Update :

menu System Update pfSense - Provya


Puis cliquer sur "Upgrade now" pour lancer la mise à jour.


  • Sauvegarde de la configuration du pfSense primaire

Une fois la mise à jour terminée sur le pfSense secondaire, effectuer une sauvegarde du pfSense primaire en suivant la procédure détaillée à l'étape précédente.


  • Désactivation CARP du pfSense primaire

Avant de mettre à jour le pfSense primaire, nous basculons les adresses VIP sur le pfSense secondaire afin de ne pas perturber le service.

Pour cela, se rendre dans dans Status > CARP (failover) :

menu Status CARP Failover pfSense - Provya


Puis cliquer sur "Enter Persistent CARP Maintenance Mode" :

désactiver or disabled carp failover on pfSense - Provya


Les adresses VIP vont basculer sur le serveur pfSense secondaire.


  • Mise à jour du serveur pfSense primaire

Nous pouvons maintenant mettre à jour tranquillement le serveur primaire. La procédure est toujours la même que celle décrite aux étapes précédentes.


Une fois la mise à jour du serveur primaire terminée, la VIP ne va pas re-basculer d'elle-même sur le serveur pfSense primaire. Il faut la réactiver. Pour cela, nous nous rendons dans le menu Status > CARP (failover) et cliquons sur "Leave Persistent CARP Maintenance Mode" :

réactiver or enabled carp failover on pfSense - Provya



Il ne reste plus qu'à faire une sauvegarde du serveur pfSense primaire afin d'avoir une sauvegarde de la dernière configuration à jour.

La mise à jour du cluster de pfSense est terminée !



3. Vérifier et corriger la mise à jour des packages

Les packages peuvent parfois être une source de problème lors d'une mise à jour. Si des packages semblent ne plus fonctionner correctement après une mise à jour, il est recommandé de désinstaller le ou les packages concernés, puis de les réinstaller.



Pour aller plus loin

Best practices / Recommandations pour la configuration de votre firewall
[pfSense] Configurer un cluster de 2 pfSense redondants (failover)


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

Découvrez nos firewall SSD pour pfSense, assemblés en France, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :

[pfSense] Monter un VPN natté (Overlap network) avec OpenVPN

icon 13/08/2019 - 11 commentaires

Un cas fréquent lorsque l'on souhaite connecter deux sites en VPN est que ces deux sites soient sur le même plan d'adressage. Dans ce cas, une bonne solution peut être de recourir au NAT pour la mise en place d'un VPN natté.

Article mis à jour le  : 13/08/2019

Par exemple, si l'on souhaite connecter deux sites utilisant le sous-réseau 192.168.1.0/24, ceux-ci ne pourront pas communiquer l'un vers l'autre à travers le VPN car le plan d'adressage du réseau distant est le même que celui du réseau local.

Afin d'y remédier, nous proposons d'utiliser le NAT pour communiquer d'un réseau à l'autre. C'est le principe du VPN natté (overlap network).

À noter : nous ne détaillons pas dans cet article comment configurer OpenVPN. Il existe déjà un article dédié sur le sujet : [pfSense] Monter un accès OpenVPN site-à-site.



Principe de fonctionnement

Pour chaque sous-réseau commun sur les sites distants, nous utiliserons un nouveau sous-réseau disponible associé à du 1:1 NAT.

Nous allons prendre l'exemple de deux sites (A et B) disposant tous deux du même plan d'adressage 192.168.1.0/24 :

Schéma réseau overlap openVPN pfSense - Provya


Afin de pouvoir relier ces deux sites en VPN, nous allons translater l'intégralité du plan d'adressage réseau du site B afin qu'il soit joignable depuis le site A à travers le VPN. Et nous ferons de même du plan d'adressage réseau du site A afin qu'il soit joignable depuis le site B à travers le VPN.

Le trafic à destination du site A sera translaté en 192.168.100.0/24.
Le trafic à destination du site B sera lui translaté en 192.168.200.0/24.

Une entrée 1:1 NAT sera ajoutée pour chaque sous-réseau afin de translater l'intégralité du /24.
Ainsi, pour joindre le site A depuis le site B, on utilisera une adresse IP du type 192.168.100.x et pour joindre le site B depuis le site A, on utilisera une adresse IP du type 192.168.200.x.

Grâce au 1:1 NAT, on conservera le dernier octet de l'adresse réseau de chaque site. C'est-à-dire que pour joindre l'adresse IP 192.168.1.10 du site A, depuis le site B on utilisera l'adresse IP 192.168.100.10. Et pour joindre l'adresse IP 192.168.1.50 du site B, depuis le site A on utilisera l'adresse IP 192.1168.200.50.



Configuration du VPN natté

Sur le serveur pfSense du site A, nous nous rendons dans menu Firewall > NAT, puis sur l'onglet 1:1 :

menu firewall NAT 1 to 1 pfSense - Provya


Nous cliquons sur le bouton "Add". Les champs à configurer sont les suivants :

  • Interface : l'interface de notre tunnel VPN OpenVPN
  • External subnet IP : le sous-réseau utilisé pour le NAT. Soit, pour le site A : 192.168.100.0
  • Internal IP : le sous-réseau local que nous souhaitons translater. Dans notre cas : LAN net
  • Destination : Any

Exemple de résultat obtenu :

Configuration 1 to 1 NAT pfSense - Provya



Nous procédons de la même manière sur le serveur pfSense du site B, en adaptant le champ "External IP" qui passe à 192.168.200.0 dans notre cas.

Exemple de résultat obtenu :

Configuration 1 to 1 NAT pfSense - Provya



Enfin, dans la configuration du client et du serveur OpenVPN, le champ "IPv4 Remote network(s)" doit correspondre aux plages d'adresses IP nattées.

C'est-à-dire que sur le pfSense du site A, le champ "IPv4 Remote network(s)" est renseigné à "192.168.200.0/24". Sur le pfSense du site B, le champ "IPv4 Remote network(s)" est quant à lui renseigné à "192.168.100.0/24".

La configuration est terminée.

Pour davantage d'information sur la configuration OpenVPN sur pfSense, voir l'article dédié sur le sujet : [pfSense] Monter un accès OpenVPN site-à-site.

Le VPN natté est en place !



Pour aller plus loin

[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] La gestion des certificats pour les connexions OpenVPN


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

Découvrez nos firewall SSD pour pfSense, assemblés en France, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :