Provya

Sécurité et téléphonie

Articles & Tutoriaux  -  Liens & Actualités

[pfSense] Implémenter DNS sur TLS (chiffrement des requêtes DNS)

icon 08/04/2018 - Aucun commentaire

Le nouveau service DNS de Cloudfare a suscité beaucoup d'attention et de commentaires.

En nous inspirant de l'article DNS over TLS with pfSense, nous proposons ici un guide rapide et en français sur la configuration de vos serveurs DNS sur pfSense et plus particulièrement sur la configuration du DNS sur TLS.

Dans ce mini-guide, nous utiliserons les serveurs DNS de Cloudfare, mais ce guide est également applicable avec les serveurs DNS Quad9.

À noter : dans ce guide nous travaillerons avec le mode "DNS resolver" actif et le mode transfert (DNS Query Forwarding) doit être désactivé puisque notre configuration va créer sa propre zone de transfert. Il s'agit de la configuration par défaut de pfSense.



1. Utiliser les serveurs DNS Cloudfare (ou Quad9)

La première étape consiste à configurer pfSense pour qu'il utilise les serveurs DNS de Cloudfare. Pour cela, se rendre dans le menu System > General Setup (ou Système > Configuration générale si votre interface est en français) :

pfSense menu System - General Setup


Les serveurs DNS à configurer sont :

  • 1.1.1.1
  • 1.0.0.1

Exemple de résultat obtenu :

pfSense - configuration DNS


Cliquer sur le bouton Save (ou Sauvegarder) en bas de page pour enregistrer les modifications.

Si nous avions souhaité utiliser les serveurs DNS de Quad9, les serveurs DNS à configurer auraient été les suivants :

  • 9.9.9.9
  • 149.112.112.112



2. Activer DNS sur TLS

Il nous reste à configurer pfSense pour lui dire de contacter ces serveurs DNS sur TLS.
Pour cela, se rendre dans le menu Services > DNS Resolver (ou Services > Résolveur DNS) :

pfSense - Services - DNS Resolver


Dans l'onglet General Settings (Paramètres généraux), descendre jusqu'à la zone "Custom options" (il faut cliquer sur le bouton "Display Custom Options" pour l'afficher).

Dans cette zone de texte, copier-coller la configuration suivante :

server:
forward-zone:
name: "."
forward-ssl-upstream: yes
forward-addr: 1.1.1.1@853
forward-addr: 1.0.0.1@853

Pour utiliser les serveurs DNS de Quad9 à la place de ceux de Cloudfare, il suffit d'adapter la valeur des lignes forward-addr. La configuration serait alors :

server:
forward-zone:
name: "."
forward-ssl-upstream: yes
forward-addr: 9.9.9.9@853
forward-addr: 149.112.112.112@853

Exemple de résultat obtenu :

pfSense - DNS custom options


Cliquer sur Save (Enregistrer) pour sauvegarder les modifications. Puis appliquer les changements en cliquant sur "Apply Changes" (Appliquer les modifications).

La configuration est terminée !



Pour aller plus loin

[pfSense] Configurer un dual-WAN (plusieurs connexions Internet)
[pfSense] Configurer un cluster de 2 pfSense redondants (failover)
[pfSense] Monter un accès OpenVPN site-à-site


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

icon Tags de l'article :

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

icon 27/11/2017 - Aucun commentaire

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 :

schéma réseau pfSense LAN et WAN


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 :

menu pfSense 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 :
  1. 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).
  2. 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.
  3. 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 :

Configuration limiter root pfSense


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 :

Limiter queue configuration pfSense


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 :

Limiter root download configuration pfSense


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 :

Limiter queue configuration download pfSense


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 :

liste limiters pfSense


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.

Firewall > Rules pfSense


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

Display Advanced pfSense


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 :

Configuration limiters firewall pfSense


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


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

icon Tags de l'article :

[pfSense] Configurer un dual-WAN (plusieurs connexions Internet)

icon 24/11/2017 - 27 commentaires

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 :

schéma réseau dual-wan


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 :
  1. 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.
  2. 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.
  3. 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 :

Interfaces WAN et WAN2 pfSense


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.

pfSense > System > General Setup


La configuration se fait dans la partie "DNS Server Settings". Par exemple, en utilisant les DNS de Google :

configuration DNS servers pfSense


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.

création d'un groupe de gateway


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 :
  1. 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)
  2. Packet Loss : lorsque le taux de perte de paquets maximum configuré pour cette passerelle est atteint
  3. High Latency : lorsque la latence maximale définie pour cette passerelle est atteinte
  4. 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 :

exemple configuration multi-WAN Provya


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.
Firewall > Rules pfSense


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

Display Advanced pfSense


En bas de page, préciser le groupe de passerelles dans le champ Gateway :

préciser gateway règles pfSense


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 :

configuration gateway firewall pfSense


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


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

icon Tags de l'article :

[pfSense] Configurer un cluster de 2 pfSense redondants (failover)

icon 02/10/2016 - 37 commentaires

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 :
  1. IP Alias
  2. CARP
  3. Proxy ARP
  4. 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 :
  1. Disabled : cocher cette case pour désactiver la règle sans devoir la supprimer.
  2. 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.
  3. Interface : l'interface logique sur laquelle nous souhaitons définir notre règle de NAT. Dans notre cas, nous choisissons "WAN".
  4. Protocol : les protocoles concernés par cette règle de NAT. Nous choisissons "any"
  5. 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.
  6. Destination : le réseau de destination. Dans notre cas, nous choisissons "any".
  7. Address : l'adresse à utiliser lors du NAT. Nous choisissons l'adresse VIP créée précédemment, soit "172.25.46.100 (VIP WAN)".
  8. Port : nous laissons ce champ vide.
  9. No XMLRPC Sync : cocher cette case pour ne pas copier la règle sur le pfSense secondaire. Nous laissons cette case non-cochée.
  10. 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.



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
  • 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 : saisir l'adresse IP du serveur pfSense de secours. 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 ; 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.


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 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] Mettre à jour son serveur pfSense
[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Configurer un dual-WAN (plusieurs connexions Internet)


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

icon Tags de l'article :

[pfSense] Configurer ses VLAN

icon 18/05/2016 - 16 commentaires

Dans cet article, nous allons voir comment configurer ses VLAN avec pfSense. Nous aborderons la terminologie associée (trunk port, tagged / untagged port, etc.), puis nous prendrons un exemple concret de configuration de VLAN.



Intérêt des VLAN

L'utilisation de VLAN apporte un certain nombre d'avantages que nous ne détaillerons pas ici. Pour une bonne compréhension des VLAN, nous proposons la lecture de l'article VLAN - Réseaux virtuels sur commentcamarche.net

Les utilisations principales de VLAN sont :
  • séparation logique des réseaux Voix & Data
  • séparation logique des services d'une entreprise
  • mise en place d'un réseau invité différent du réseau local



Mode de fonctionnement des VLAN

Lorsque nous créons un VLAN, nous définissons deux éléments :
  • le subnet associé (ex : 192.168.1.0/24)
  • l'ID du VLAN (allant de 1 à 4094)

Les terminaux se trouvant sur un VLAN ne pourront communiquer qu'avec les autres terminaux se trouvant sur le même VLAN. S'ils souhaitent communiquer avec les terminaux d'un autre VLAN, les paquets passeront par pfSense. Cela nous permet de configurer au niveau de pfSense des règles fines de filtrage d'un VLAN à un autre.
Il est à noter que le routage d'un VLAN à l'autre peut également se faire au niveau du switch via la mise en place d'ACL (cas que nous n'aborderons pas dans le présent article).

Les VLANs doivent être déclarés et configurés côté pfSense d'une part, et sur les switches d'autre part (qui doivent bien-sûr être des switches supportant les VLAN).
La configuration des switches est le point le plus délicat. La terminologie employée n'étant pas toujours la même chez les constructeurs.



Terminologie

Lorsque nous souhaitons configurer les VLAN sur notre switch, nous avons deux possibilités de configuration :

  • tagged port (= trunk port chez Cisco)
  • untagged port (= access port chez Cisco)

Tagged port
Un port de switch configuré en "tagged" signifie que l'équipement branché derrière est capable de traiter les tags 802.1q et qu'il est configuré pour les traiter. C'est-à-dire qu'il faudra indiquer dans la configuration de l'équipement qu'il doit marquer ses paquets réseau avec son VLAN d'appartenance.


Untagged port
Un port de switch configuré en "untagged" signifie que la notion de VLAN est totalement transparente pour l'équipement branché derrière. C'est-à-dire qu'il ignore son VLAN de rattachement. C'est le switch qui utilise l'id VLAN associé pour son traitement interne pour la distribution des paquets sur ses ports. Les paquets ne sont pas taggués 802.1q en entrée et sortie des ports du switch configurés en "untagged".

Un switch ne peut avoir sur un port donné qu'un seul VLAN configuré en "untagged" (access). Il peut y avoir, sur ce même port, plusieurs VLANs configurés en "tagged" (trunk).



Cas concret : séparation VLAN voix / VLAN data

Un cas concret et classique d'utilisation des VLAN va être de séparer le réseau VoIP du réseau Data.

Nous prendrons l'exemple du réseau local suivant :

  • pfSense fait office de routeur/firewall et de serveur DHCP pour l'ensemble des VLAN
  • Les ordinateurs (et tous les autres équipements sauf téléphones) disposent d'une adresse IP sur la plage 192.168.1.0/24 - VLAN 10 (ce sera notre VLAN par défaut - configuré en untagged)
  • Les postes téléphoniques disposent d'une adresse IP sur la plage 192.18.2.0/24 - VLAN 20 (VLAN dédié à la téléphonie - configuré en tagged)
  • Le switch de cœur de réseau est un switch supportant les VLAN
  • Tous les ordinateurs sont branchés derrière un téléphone. C'est-à-dire que sur chaque port du switch il y aura généralement deux équipements branchés : un téléphone (dans le VLAN 20) et un ordinateur (VLAN 10) branché derrière

Le schéma réseau est le suivant :

Schéma réseau




Configuration du pfSense

Sur le pfSense, nous configurerons donc deux VLANs :
  • VLAN "LAN Data"
  • VLAN "LAN VoIP"

Pour commencer, nous allons dans le menu "Interface" > "(assign)" :



Puis, nous nous rendons dans l'onglet "VLANs" et cliquons sur l'icône en forme de "+" se trouvant en bas à droite.

Les éléments de configurations sont les suivants :

  1. Parent interface : l'interface physique à laquelle sera rattachée le VLAN
Attention : cette interface physique ne doit pas avoir d'interface logique d'associée, autrement les VLAN ne fonctionneront pas correctement. Nous vous invitons à (re)lire l'article [pfSense] Comprendre la gestion des interfaces réseaux pour bien comprendre ce qu'est une interface physique, une interface virtuelle ou une interface logique.

Cela signifie que soit ce VLAN doit être associé à une interface physique différente de l'interface physique déjà associée à l'interface logique "LAN", soit qu'il faut supprimer l'interface logique "LAN" pour ne créer que des VLANs pour le réseau local.
Nous insistons sur le fait que pour un bon fonctionnement, il est indispensable que le VLAN soit associé à une interface physique qui ne soit pas déjà associée à une interface logique.
  1. VLAN tag : l'ID du VLAN (la valeur doit être comprise entre 1 et 4094)
  2. VLAN Priority : la priorité à appliquer au VLAN (la valeur doit être comprise entre 0 et 7)
  3. Description : champ optionnel de description du VLAN

Exemple de résultat obtenu :

Configuration VLAN pfSense


Et une fois nos deux VLANs créés, nous disposons de deux interfaces virtuelles :

Exemples VLAN pfSense


Afin de configurer nos VLANs, nous devons maintenant associer ces interfaces virtuelles à des interfaces logiques.
Pour cela, nous retournons dans l'onglet "Interface assignments", puis nous cliquons sur l'icône en forme de "+" se trouvant un bas à droite afin d'ajouter une nouvelle interface logique.

Par défaut, l'interface logique créée porte le nom "OPT1" (ou OPT2, OPT3, etc.). Nous associons cette interface logique à l'interface virtuelle du VLAN que nous avons créée précédemment :

Création interface logique pfSense


Pour modifier l'interface logique créée (et la renommer), nous cliquons sur son nom. Les éléments de configuration sont les suivants :

  1. Enable Interface : cocher cette case pour activer l'interface
  2. Description : nom de l'interface
  3. IPv4 Configuration Type : la configuration IPv4 de cette interface. Dans notre cas, nous choisissons "Static IPv4"
  4. IPv6 Configuration Type : la configuration IPv6 de cette interface. Dans notre cas, nous choisissons "None"
  5. MAC controls : par défaut, c'est l'adresse MAC de l'interface physique qui est utilisée. Elle peut être personnalisée ici
  6. MTU : la MTU pour cette interface. 1500 octets par défaut
  7. MSS : "Maximum Segment Size", devrait être inférieur au MTU. Nous laissons vide
  8. Speed and duplex : nous laissons le choix par défaut

Enfin, nous appliquons les paramètre de configuration IP (adresse IP de l'interface et masque réseau associé).
Exemple de résultat obtenu :

Configuration interface logique pfSense


Sur cette interface, nous activons le service DHCP. Pour davantage de détails sur la manière de procéder pour l'activation du service DHCP, se référer à notre article dédié : [pfSense] Configurer son serveur DHCP.

Enfin, nous créons une règle de firewall sur notre nouvelle interface logique ("VLAN_voix") afin d'autoriser le trafic.

La configuration côté pfSense est terminée. Il reste à procéder à la configuration côté Switch.



Configuration du Switch

La configuration des VLAN sur le switch dépend du constructeur. Cependant, les étapes à suivre seront toujours les mêmes :

  1. Déclaration des VLAN sur le switch - sur la plupart des switches, il faut déclarer les VLANs avant de pouvoir les configurer sur n'importe quel port (dans notre cas, nous déclarons 2 VLAN : vlan_data avec l'ID 10 et vlan_voix avec l'ID 20)
  2. Configuration du port du switch sur lequel est branché le pfSense en mode trunk (ou tagged) sur les VLAN 10 et 20
  3. Configurer les ports du switch sur lesquels seront branchés les PC en mode access (ou untagged) - dans notre cas sur le VLAN 10
  4. Configurer les ports du switch sur lesquels seront branchés les téléphones en mode trunk (ou tagged) - dans notre cas sur le VLAN 20

Exemple sur un switch Cisco :

Déclaration des VLANs :
sw# vlan database
sw(vlan)# vlan 10 name "vlan_data"
sw(vlan)# vlan 20 name "vlan_voix"
sw(vlan)# exit

Configuration du port trunk :
sw# configure terminal
sw(config)# interface FastEthernet0/24
sw(config-if)# switchport mode trunk

Ajouter les ports au VLAN :
sw# configure terminal
sw(config)# interface FastEthernet0/12
sw(config-if)# switchport mode access
sw(config-if)# switchport access vlan 20


Nos VLANs sont configurés et prêts à fonctionner.
La principale subtilité à connaître est de ne pas configurer les VLAN sur la même interface physique que le LAN.



Pour aller plus loin

[pfSense] Comprendre la gestion des interfaces réseaux
[pfSense] Configurer son serveur DHCP


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

icon Tags de l'article :

[pfSense] Sécurisez l'accès distant de vos collaborateurs nomades avec OpenVPN

icon 18/04/2016 - 2 commentaires

Il est de plus en plus souvent nécessaire de pouvoir offrir des solutions d'accès distants à ses utilisateurs nomades.
Ces accès se doivent d'être sécurisés et fiables.

Bonne nouvelle, pfSense et OpenVPN forment la solution idéale pour ce besoin ! :-)



OpenVPN = la solution idéale pour les utilisateurs nomades

OpenVPN est une solution facile à mettre en œuvre et efficace pour les utilisateurs nomades.

OpenVPN propose des clients pour tout type de plate-forme (Windows, MAC, Android, iOS) :

Plateformes supportées par OpenVPN


De plus, pfSense propose un mode d'export des configurations des clients pour encore plus de facilité.


À noter :
Cet article ne traite pas de la configuration d'OpenVPN serveur en mode site-à-site (clé partagée ou X.509).
Cet article traite uniquement de l'accès nomade. Nous ne rentrerons pas dans les détails de configuration d'OpenVPN côté serveur pfSense. Nous nous concentrons sur les spécificités de l'accès nomade.

Il existe plusieurs articles dédiés à la configuration d'OpenVPN en environnement pfSense : [pfSense] Monter un accès OpenVPN site-à-site.



Principe de fonctionnement

Le but est d'offrir une solution de VPN pour les utilisateurs nomades leur permettant de disposer d'un accès sécurisé au réseau local de l'entreprise.
Ces utilisateurs peuvent utiliser un ordinateur ou un smartphone pour se connecter.
Dans tous les cas, ils utiliseront un client OpenVPN.

Dans notre exemple de mise en application, nous partirons sur l'infrastructure suivante :

- le sous-réseau LAN est 172.31.54.0/24
- le sous-réseau OpenVPN est 172.31.55.0/24

accès nomade OpenVPN avec pfSense


Pour l'identification et l'authentification des utilisateurs, nous utiliserons un certificat couplé à un login et un mot de passe.
Le certificat sera commun pour tous les utilisateurs. Le login et le mot de passe seront privatifs.


Passons maintenant à la configuration !



Configuration du serveur OpenVPN

Côté serveur OpenVPN, nous devons créer les éléments suivants :
  1. une autorité de certification, sauf si nous en disposons déjà d'une
  2. un certificat serveur
  3. un certificat client
  4. les accès utilisateurs (login et mot de passe)
  5. le serveur OpenVPN en tant que tel
  6. les règles de firewall et de NAT idoines
  7. la configuration des clients nomades



1. Création d'une autorité de certification

Cette étape n'est nécessaire que si nous ne disposons pas déjà d'une autorité de certification existante.
Si nous en avons déjà créé une lors de la mise en place d'une connexion VPN site-à-site ([pfSense] La gestion des certificats pour les connexions OpenVPN), nous pouvons réutiliser celle-ci plutôt que d'en recréer une nouvelle.

Autrement, nous nous rendons dans le menu System > Cert Manager :



Dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur l'icône "+ 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. Import an existing Certificate Authority : permet d'importer le certificat (clé publique + clé privée) d'une autorité de certification existante
  2. Create an internal Certificate Authority : permet de créer une nouvelle autorité de certification
  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, nous créons une nouvelle autorité de certification (Create an internal Certificate Authority).
  • Key length : la longueur de la clé de chiffrement du certificat. Plus elle est longue, plus elle sera sécurisée (mais plus la charge CPU sera grande également...). 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 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 (3650 jours, soit 10 ans)
  • Country Code : le code ISO du pays. Dans notre cas : FR
Les autres champs sont principalement cosmétiques et doivent permettre d'identifier l'organisation. Le seul élément important est le "Common name" dans lequel il ne doit pas y avoir d'espace et qui doit être unique.

Exemple de résultat obtenu :



Notre autorité de certification est créée.

Nous devons exporter la clé publique du certificat. Pour cela, 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 :





2. 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 l'icône "+ Add" se trouvant en bas à droite de la liste des certificats existants.

Les champs à renseigner sont les suivants :
  • Method : 3 méthodes sont possibles :
  1. Import an existing Certificate : permet d'importer la clé publique et la clé privée d'un certificat existant
  2. Create an internal Certificate : permet de créer une nouveau certificat
  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.
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. Plus elle est longue, plus elle sera sécurisée (mais plus la charge CPU sera grande également...). 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
  • 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".
  • 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 (3650 jours, soit 10 ans)
Les autres champs sont principalement cosmétiques et doivent permettre d'identifier l'organisation émettrice du certificat. Par défaut, l'ensemble des champs sont pré-complétés avec les informations issues du CA. Le seul élément important est le "Common name" dans lequel il ne doit pas y avoir d'espace et qui doit rester unique

Exemple de résultat obtenu :



Notre certificat pour le serveur OpenVPN est créé.



3. Création d'un certificat client

Il nous reste à créer un certificat pour nos clients nomades.
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 :



Notre certificat pour les clients OpenVPN est créé.

Nous exportons la clé privée et la clé publique (qui nous sera nécessaire pour les clients nomades).
Pour cela, nous cliquons successivement sur les icônes "Export certificat" et "Export key" du certificat client que nous avons créé précédemment :





4. Création des utilisateurs

La création et la gestion des utilisateurs se passent dans le menu System > User Manager :

alt


Nous commençons par créer un groupe : se rendre sur l'onglet "Groups", puis cliquer sur l'icône "+ Add" se trouvant en bas à droite de la liste des groupes.

Nous renseignons les champs comme suit :
  • Group name : le nom du nouveau groupe. Ce nom ne doit pas contenir d'espace. Dans notre cas, nous indiquons "OpenVPN-user"
  • Scope : la portée du groupe. Nous laissons la valeur par défaut "Local"
  • Description : une description facultative
  • Group Memberships la liste des membres du groupe. Dans notre cas, nous la laissons vide pour le moment

Exemple de résultat obtenu :

alt


Si nous souhaitons assigner des privilèges aux membres du groupe, il faut l'éditer en cliquant sur l'icône en forme de crayon se trouvant à sa droite.
Dans notre cas, les utilisateurs n'ayant pas besoin de se connecter à pfSense, nous ne leur attribuons aucun droit particulier.


Nous nous rendons ensuite dans l'onglet "Users" pour créer notre premier utilisateur en remplissant les champs comme suit :
  • Disabled : permet de désactiver un utilisateur sans le supprimer
  • Username : le nom d'utilisateur (sans espace ni caractères spéciaux)
  • Password : le mot de passe
  • Full name : Le nom de l'utilisateur associé à ce compte
  • Expiration date : La date d'expiration du compte. Elle doit être saisie au format américain, c'est-à-dire mm/jj/aaaa (mois/jour/année). Si ce champ est laissé vide, le compte n'expirera jamais.
  • Group Memberships : c'est ici que nous définissons le groupe auquel nous rattachons l'utilisateur. Dans notre cas, nous choisirons "OpenVPN-user"
  • Certificate : si l'on souhaite créer par la même occasion un certificat pour l'utilisateur (ce que nous ne ferons pas)
  • Authorized keys : si l'on souhaite définir la clé autorisée pour la connexion de l'utilisateur (nous ne cochons pas cette case)
  • IPsec Pre-Shared Key : utiliser pour les connexions en VPN IPsec ; ce qui n'est pas notre cas (nous laissons donc ce champ vide)

Exemple de résultat obtenu :

alt




5. Création 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 "Remote Access (SSL/TLS + User Auth)"
  • TLS Authentication : cocher la case "Enable authentication of TLS packets" pour davantage de sécurité. Nous ne conseillons pas de la cocher
  • Peer Certificate Authority : choisir l'autorité de certification créée précédemment ("CA Provya (ca-provya)")
  • Server Certificate : choisir le certificat serveur créé précédemment ("Certificat Serveur (certif-serveur-provya)")
  • DH Parameters Length : nous laissons la valeur par défaut (1024 bits)

Exemple de résultat obtenu :





6. Configuration du firewall et du NAT

Se rendre dans Firewall > Rules :



Sur l'interface sur laquelle le serveur OpenVPN est en écoute ("WAN", très sûrement), créer une règle autorisant le trafic à atteindre l'adresse IP et le port du serveur OpenVPN.

  • Interface : WAN
  • Protocol : UDP
  • Source : choisir "any"
  • Destination : WAN address
  • Destination port range : port choisi lors de la configuration du serveur OpenVPN (1194 dans notre exemple)

Exemple de résultat obtenu :



Si nous avons besoin de faire une redirection d'adresse (cas où le port public utilisé serait différent du port configuré pour le serveur OpenVPN), nous créons une règle de NAT dans Firewall > NAT.
Les éléments à renseigner sont :

  • Interface : WAN
  • Protocol : UDP
  • Src. addr & Src. port : choisir "any"
  • Dest. addr : l'adresse IP WAN
  • Dest. ports : le port d'écoute du serveur OpenVPN
  • NAT IP : l'adresse IP du pfSense sur l'interface WAN
  • NAT Ports : le porte d'écoute du serveur OpenVPN (1194, dans notre exemple)



7. Configuration des clients nomades

Il ne reste plus qu'à mettre en route OpenVPN client sur les postes nomades.

Les clients Windows, Mac, Android ou iOS sont téléchargeables directement sur le site d'OpenVPN ou sur les stores associés : iPhone et Android.

3 fichiers nous serons nécessaires :
  • la clé publique et la clé privée du certificat client créé précédemment
  • un fichier de configuration d'OpenVPN à créer manuellement

La documentation d'OpenVPN fournit un fichier de configuration d'exemple. Il est reproduit ci-dessous.

Les éléments à configurer sont :
  • remote my-server 1194 => à remplacer par l'adresse IP publique (ou le nom de domaine associé) et par le bon port d'écoute
  • ca ca-provya.crt => la clé publique de l'autorité de certification
  • cert provya-client.crt => la clé publique du certificat client
  • key provya-client.key => la clé privée du certificat client

##############################################
# Sample client-side OpenVPN 2.0 config file #
# for connecting to multi-client server.     #
#                                            #
# This configuration can be used by multiple #
# clients, however each client should have   #
# its own cert and key files.                #
#                                            #
# On Windows, you might want to rename this  #
# file so it has a .ovpn extension           #
##############################################

# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client

# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun

# Windows needs the TAP-Windows adapter name
# from the Network Connections panel
# if you have more than one.  On XP SP2,
# you may need to disable the firewall
# for the TAP adapter.
;dev-node MyTap

# Are we connecting to a TCP or
# UDP server?  Use the same setting as
# on the server.
;proto tcp
proto udp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote my-server 1194


# Choose a random host from the remote
# list for load-balancing.  Otherwise
# try hosts in the order specified.
;remote-random

# Keep trying indefinitely to resolve the
# host name of the OpenVPN server.  Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don't need to bind to
# a specific local port number.
nobind

# Downgrade privileges after initialization (non-Windows only)
;user nobody
;group nobody

# Try to preserve some state across restarts.
persist-key
persist-tun

# If you are connecting through an
# HTTP proxy to reach the actual OpenVPN
# server, put the proxy server/IP and
# port number here.  See the man page
# if your proxy server requires
# authentication.
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]

# Wireless networks often produce a lot
# of duplicate packets.  Set this flag
# to silence duplicate packet warnings.
;mute-replay-warnings

# SSL/TLS parms.
# See the server config file for more
# description.  It's best to use
# a separate .crt/.key file pair
# for each client.  A single ca
# file can be used for all clients.
ca ca-provya.crt
cert provya-client.crt
key provya-client.key

# Verify server certificate by checking
# that the certicate has the nsCertType
# field set to "server".  This is an
# important precaution to protect against
# a potential attack discussed here:
#  http://openvpn.net/howto.html#mitm
#
# To use this feature, you will need to generate
# your server certificates with the nsCertType
# field set to "server".  The build-key-server
# script in the easy-rsa folder will do this.
;ns-cert-type server

# If a tls-auth key is used on the server
# then every client must also have the key.
;tls-auth ta.key 1

# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
;cipher x

# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
;comp-lzo

# Set log file verbosity.
verb 3

# Silence repeating messages
;mute 20

# Autentification par login et mot de passe
auth-user-pass


Le fichier de configuration d'OpenVPN et les clés publiques & privées sont à stocker dans un même répertoire.


La configuration est terminée.

pfSense propose également un outil d'export (ce qui évite de devoir créer un fichier .ovpn manuellement). Cet outil est accessible en installant le package "OpenVPN Client Export Utility".



Analyse et Debug

Pour voir si un client est connecté, ça se passe dans le menu "Status" > "OpenVPN".

Les logs de connexion sont eux accessibles dans "Status" > "System logs", puis onglet "OpenVPN".



Pour aller plus loin

[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Monter un VPN natté (Overlap network) avec OpenVPN
[pfSense] La gestion des certificats pour les connexions OpenVPN


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

icon Tags de l'article :

[pfSense] Comprendre la priorisation de trafic

icon 05/06/2015 - 16 commentaires

Dans pfSense, il existe 3 principaux mécanismes de priorisation de flux :

- CBQ - Class Based Queueing
- PRIQ - Priority Queueing
- HFSC - Hierarchical Fair-Service Curve

PRIQ est un protocole de priorisation très simple (simpliste ?) mais nécessitant de faire très attention dans sa configuration.

CBQ est sans doute le protocole à utiliser dans la plupart des cas pour une entreprise souhaitant une gestion de la priorisation de trafic simple et efficace.

HFSC est sans conteste le protocole le plus évolué permettant un niveau de souplesse avancé, au prix d'une forte complexité...


Nous nous proposons ici de passer en revue ces différents mécanismes.
Dans un prochain article, nous verrons comment les mettre en œuvre dans pfSense.


CBQ - Class Based Queueing
CBQ est un algorithme permettant de diviser la bande passante d'une connexion en multiples queues ou classes.
Le trafic est assigné à l'une des queues, en fonction du protocole source/destination utilisé, du numéro de port, de l'adresse IP, etc.

Chaque queue se voit attribuer une bande passante et une priorité.

Les queues CBQ sont organisées de manière hiérarchique. Au sommet, nous retrouvons la queue "ROOT" (racine).
Chaque queue fille partage la bande passante de sa queue mère.

Il est également possible d'autoriser une queue à utiliser la bande passante de sa queue parente si celle-ci est sous-utilisée.


Exemple :

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
	- Queue 2 (2Mbps)
	- Queue 3 (1Mbps)

La somme de la bande passante attribuée aux queues filles ne peut pas être supérieure à la bande passante totale de la queue mère.
Ainsi, dans notre exemple, la somme des bandes passantes des queues 1, 2 et 3 ne peut être supérieure à la bande passante de la queue Root.

Chaque queue fille peut elle-même avoir des queues filles :

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
		Queue VoIP (1Mbps)
		Queue SSH (1Mbps)
	- Queue 2 (2Mbps)
		Queue HTTP (800Kbps)
		Queue VNC (200Kbps)
	- Queue 3 (1 Mbps)

Pour chacune de ces queues, on peut activer l'emprunt ("borrow") de bande passante à sa queue mère :

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
		Queue VoIP (1Mbps - borrow)
		Queue SSH (1Mbps)
	- Queue 2 (2Mbps)
		Queue HTTP (800Kbps)
		Queue VNC (200Kbps)
	- Queue 3 (1 Mbps)

Dans l'exemple ci-dessus, la queue VoIP dispose d'une bande passante de 1Mbps. Cependant, elle peut potentiellement utiliser jusqu'à 2Mbps (bande passante allouée à sa queue mère - Queue 1) si la queue SSH n'est pas pleine.

Une priorité est attachée à chaque queue. La priorité la plus forte sera préférée en cas de congestion. Si deux queues ont la même priorité, la distribution s'opère suivant un processus de type round-robin.

Root Queue (5Mbps)
	- Queue 1 (2Mbps, priorité 1)
		Queue VoIP (1Mbps - borrow, priorité 5)
		Queue SSH (1Mbps, priorité 3)
	- Queue 2 (2Mbps, priorité 1)
		Queue HTTP (800Kbps, priorité 1)
		Queue VNC (200Kbps, priorité 2)

Dans notre exemple ci-dessus, la queue 1 et la queue 2 ayant la même priorité, aucune des deux queues ne sera priorisée l'une par rapport à l'autre. Durant le temps où la queue 1 sera traitée, les queues filles seront traitées en même temps. La queue VoIP sera traitée en priorité par rapport à la queue SSH (en cas de congestion).
Il est à noter qu'uniquement les queue fille de la même queue mère sont comparées entre-elles (c'est-à-dire que la priorité de la queue VoIP sera comparée à la priorité de la queue SSH, mais ne sera pas comparée à la queue HTTP par exemple).


Davantage d'informations sur le protocole CBQ : CBQ sur openbsd.org - EN



PRIQ - Priority Queueing
PRIQ est un protocole permettant de définir plusieurs queues attachées à une interface et d'y affecter une priorité. Une queue avec une priorité supérieure sera toujours traitée avant une queue avec une priorité plus faible.
Si deux queues ont à la même priorité, la distribution se fera suivant le processus round-robin.

La construction des queues PRIQ est plate (il n'y a pas de notion de queue mère et de queue fille) - il n'est pas possible de définir une queue au sein d'une autre queue.

Une queue "ROOT" (racine) est définie, qui sera la bande passante totale de la connexion. Les autres queues sont définies sous la queue ROOT.

Exemple :

Root Queue (2Mbps)
	- Queue 1 (priorité 2)
	- Queue 2 (priorité 1)

La queue Root est définie comme disposant de 2Mbps. La queue 1 disposant de la plus forte priorité, l'ensemble de ses paquets seront traités en priorité. Tant qu'il existe des paquets dans la queue 1, la queue 2 ne sera pas traitée.
Dans chaque queue, les paquets sont traités dans l'ordre FIFO (First IN First OUT).

/!\ Attention : il est bien important de comprendre que dans le processus PRIQ, les paquets se trouvant dans les queues disposant de la priorité la plus élevée sont toujours traités avant les paquets des autres queues.
Ainsi, si une queue disposant d'une priorité élevée reçoit un flux de paquet continu, les queues disposant d'une priorité plus faible seront peu, voire pas traitées.


Davantage d'informations sur le protocole PRIQ : PRIQ sur openbsd.org - EN



H-FSC
HFSC est un algorithme évolué de traitement hiérarchique permettant de répartir la bande passante d'un lien et de contrôler l'allocation de ressources en fonction de la bande passante et de la latence.

Tout comme dans l'algorithme CBQ, les queues HFSC sont organisées de manière hiérarchique. Au sommet, nous retrouvons la queue "ROOT" (racine).
Chaque queue fille partage la bande passante de sa queue mère.

Chaque queue fille peut elle-même avoir des queues filles :

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
		Queue VoIP (1Mbps)
		Queue SSH (1Mbps)
	- Queue 2 (2Mbps)
		Queue HTTP (800Kbps)
		Queue VNC (200Kbps)
	- Queue 3 (1 Mbps)

Une priorité est donnée à chaque queue. Les priorités vont de 0 (priorité la plus faible) à 7 (priorité la plus forte). Comme pour CBQ, ces priorités ne sont appliquées qu'en cas de saturation du lien.

Root Queue (5Mbps)
	- Queue 1 (2Mbps, priorité 1)
		Queue VoIP (1Mbps, priorité 5)
		Queue SSH (1Mbps, priorité 3)
	- Queue 2 (2Mbps, priorité 1)
		Queue HTTP (800Kbps, priorité 1)
		Queue VNC (200Kbps, priorité 2)

Qlimit
Chaque queue se voit attribuée en plus un paramètre "Qlimit". Qlimit correspond à un buffer (tampon) qui va se remplir lorsque la bande passante attribuée à la queue sera saturée : plutôt que de rejeter les nouveaux paquets arrivant, ceux-ci vont être mis en file d'attente dans ce buffer.

La valeur de Qlimit (la taille du buffer donc) est exprimée en nombre de paquets. Par défaut, sa valeur est de 50.

Un fois que le buffer définit par Qlimit est saturé, les nouveaux paquets sont supprimés (drop).

Il n'est pas nécessaire, et sûrement contre-productif, de définir une valeur trop grande pour Qlimit : cela ne solvera pas un problème de saturation de bande-passante. Une trop grande valeur peut entraîner un "buffer bloat".

Pour calculer la bonne valeur de Qlimit, il faut se demander combien de temps nous souhaitons garder un paquet dans le buffer.

Si le concept de MTU ou de latence ne vous est pas familier, lisez tout d'abord les liens cités précédemment.

Si l'on souhaite qu'un paquet reste bufferisé au maximum 0,5 seconde (ce qui est déjà long), le calcul à effectuer pour connaître la valeur de Qlimit est le suivant :

(BP / 8) / MTU = nb paquets/sec.
Avec :
BP : bande passante (en bits/s)
MTU : MTU du lien (en bytes)

Par exemple, si nous disposons d'un lien offrant 10Mbps en upstream ayant une MTU de 1500 bytes :

(10.000.000 / 8) / 1500 = 833 pq/sec

Soit, si l'on souhaite une bufferisation de 0,5 sec sur notre lien : 833x0,5 = 416 paquets (=valeur de notre Qlimit)

Si vous ne souhaitez pas vous lancer dans de tels calculs, laissez la valeur par défaut de Qlimit (50 paquets).


realtime
Ce paramètre permet de définir la bande-passante minimale garantit en permanence à la queue.


upperlimit
Le paramètre upperlimit permet de définir une limite haute de bande passante que la queue ne pourra jamais dépasser.
Cela permet, par exemple, de limiter l'usage fait de la bande passante pour un type de service ou d'utilisateurs.


linkshare
Ce paramètre remplit la même fonctionnalité que le paramètre "bandwith" définit plus haut. C'est-à-dire qu'il permet de définir la bande-passante disponible pour une queue ; cette bande-passante pouvant être empruntée à d'autres queues.

Aussi, si nous définissons le paramètre "bandwith" ET le paramètre "link share (m2)", c'est le paramètre "linkshare m2" qui sera pris en compte.


Ainsi, nous avons les paramètres suivants :
  1. realtime : bande-passante minimale garantie à une queue
  2. linkshare : bande-passante globale attribuée à la queue (utilisée une fois que realtime est plein)
  3. upperlimit : bande-passante maximale que la queue ne pourra jamais dépassée
  4. bandwith : redondant avec linkshare. Peut être utilisé si l'on ne souhaite pas utiliser le mécanisme NLSC.

Il est important de comprendre que le paramètre "linkshare" n'est utile que si l'on souhaite activer le mode NLSC (non linear service curve). Autrement, seul le paramètre "bandwith" peut être utilisé dans le paramétrage des queues.


NLSC
NLSC est un mécanisme permettant de définir une bande-passante initiale, puis après un certain temps, une bande-passante définitive.
Ainsi, on va pouvoir définir une bande-passante qui va évoluer dans le temps.

Il existe 3 paramètres pour la configuration de NLSC :
  1. m1 : bande passante initiale attribuée à la queue
  2. m2 : bande passante définitive attribuée à la queue
  3. d : durée (en ms) durant laquelle la bande passante attribuée à la queue est la bande passante initiale (m1), avant de devenir la bande passante définitive (m2)

NLSC est principalement utilisé dans le but d'offrir un maximum de bande-passante sur un certain laps de temps, puis de brider cette bande-passante. Ainsi, ce "bridage" n'impacte que les gros fichiers transitant dans la queue concernée.

NLSC est activable aussi bien sur les directives realtime, upperlimit et linkshare.
Si l'on ne souhaite pas faire évoluer la bande-passante dans le temps, seul le paramètre m2 doit être défini.


Options
Il existe plusieurs options que l'on peut définir sur nos queues. Actuellement, elles sont au nombre de quatre :
  1. Default queue : permet de définir la queue par défaut. Il ne peut y avoir qu'une seule queue par défaut par interface.
  2. Explicit Congestion Notification (ECN) : ECN permet d'envoyer une notification de congestion sur le réseau afin de limiter le "drop" de paquets. N'est utilisable qu'entre deux équipements le supportant.
  3. Random Early Detection (RED) : utilisé avec ECN, offre un mécanisme de détection de congestion (avant qu'elle n'ait lieu).
  4. Random Early Detection In and Out (RIO) : idem RED.

Nous ne recommandons pas l'usage des paramètres RED, RIO et ECN.

Une fois tous ces paramètres appliqués, si nous reprenons notre exemple de queues définit précédemment :

Root Queue (5Mbps)
	- Queue 1 (2Mbps, upperlimit: 3Mbps, realtime: 1Mbps)
		Queue VoIP (1Mbps, realtime: 1Mbps, qlimit: 500)
		Queue SSH (1Mbps, qlimit 500)
	- Queue 2 (2Mbps, upperlimit: 3Mbps, default)
		Queue HTTP (800Kbps, realtime: 500Kbps)
		Queue VNC (200Kbps, qlimit: 500)


Nous venons de passer en revu les 3 principaux mécanismes de priorisation de trafic proposés dans pfSense.

Dans un prochain article, nous verrons comment les configurer et les activer dans pfSense.



Pour aller plus loin

[pfSense] Configurer la priorisation de trafic avec CBQ
[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

icon Tags de l'article :

[pfSense] Configurer la priorisation de trafic avec CBQ

icon 04/02/2015 - 8 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.

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



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



Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la priorisation de trafic sur l'interface WAN
  • Schedule 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 :



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



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, "1Mbps"
  • 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 :



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



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 :



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 :



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

pfSense configuration du traffic shaper


Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la priorisation de trafic sur l'interface WAN
  • Schedule 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 :

pfSense configuration traffic shaping LAN


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



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



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

Nos queues sont toutes créées :



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





Configuration des rules

Nous allons maintenant créer les règles d'affectation 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 des paquets IP 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 pfSense


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 features" (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 l'icône en forme de "+" 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 :

config floating traffic shaping pfSense


Puis, dans la section "Advanced features", nous cliquons sur le bouton "Advanced" se trouvant sur 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.

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 :

config floating QoS queue pfSense


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

floating rules QoS pfSense


Nous créons une nouvelle règle en cliquant sur l'icône en forme de "+".

Renseigner 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 features", nous cliquons sur le bouton "Advanced" se trouvant sur la ligne "Ackqueue/Queue".
Nous laissons la première liste déroulante à "none", et choisissons "qVoIP" pour la seconde.

Exemple de résultat obtenu :

pfSense floating rules QoS


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

Nous créons la dernière règle en cliquant sur l'icône en forme de "+".

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

pfSense floating rules QoS ACK


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

pfSense floating rules exemple




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

pfSense reset firewall states


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

Status queues pfSense


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.

icon Tags de l'article :

[pfSense] Comprendre la gestion des interfaces réseaux

icon 13/01/2015 - 4 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.

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, 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 généralement nommées re0, re1, re2, 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 aurait eu l'association suivante :

WAN [interface logique] = re0 [port réseau]
LAN [interface logique] = re1 [port réseau]





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 (elle 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.

Exemple de résultat obtenu :



Dans la capture d'écran ci-dessus, on voit que l'interface logique "monVPN" est associée à l'interface virtuelle "ovpns1" qui a été créée lors de la configuration du serveur OpenVPN "serveur 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 l'on va 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 on souhaite 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 > (assign) :



Puis onglet "Interface Groups".
L'ajout se fait en cliquant sur l'icône en forme de "+".
On renseigne le nom du groupe d'interfaces, une description (facultative) et la liste des interfaces faisant partie du groupe :



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



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.



Cas particuliers : 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 l'on souhaite une granularité de configuration par instance OpenVPN, alors on doit 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 !


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

icon Tags de l'article :

[pfSense] La gestion des certificats pour les connexions OpenVPN

icon 30/12/2014 - 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.

À 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 de certificat. 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 :



Dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur l'icône en forme de "+" 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. Import an existing Certificate Authority : permet d'importer le certificat (clé publique + clé privée) d'une autorité de certification existante
  2. Create an internal Certificate Authority : permet de créer une nouvelle autorité de certification
  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. Plus elle est longue, plus elle sera sécurisée (mais plus la charge CPU sera grande également...). 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 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)
  • Distinguished name : l'ensemble de ces champs sont principalement cosmétiques et doivent permettre d'identifier l'organisation. Le seul élément important est le "Common name" dans lequel il ne doit pas y avoir d'espace (il est possible d'en mettre, mais cela peut poser des problèmes...)

Exemple de résultat obtenu :



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 l'icône en forme de "+" se trouvant en bas à droite de la liste des certificats existants.

Les champs à renseigner sont les suivants :
  • Method : 3 méthodes sont possibles :
  1. Import an existing Certificate : permet d'importer la clé publique et la clé privée d'un certificat existant
  2. Create an internal Certificate : permet de créer une nouveau certificat
  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.
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. Plus elle est longue, plus elle sera sécurisée (mais plus la charge CPU sera grande également...). 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
  • Certificate Type : le type de certificat. Il existe 3 valeurs possibles :
  1. User Certificate : pour définir un certificat pour un client
  2. Server Certificate : pour définir un certificat pour un serveur
  3. Authority Certificate : pour créer un CA intermédiaire
Dans notre cas, nous choisissons "Server Certificate".
  • 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)
  • Distinguished name : l'ensemble de ces champs sont principalement cosmétiques et doivent permettre d'identifier l'organisation émettrice du certificat. Par défaut, l'ensemble des champs sont pré-complétés avec les informations issues du CA. Le seul élément important est le "Common name" dans lequel il ne doit pas y avoir d'espace (il est possible d'en mettre, mais cela peut poser des problèmes...) et qui doit, autant que possible, rester unique

Exemple de résultat obtenu :



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 :



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 Authentication : cocher la case "Enable authentication of TLS packets" pour davantage de sécurité. Nous ne conseillons pas de la cocher
  • Peer Certificate Authority : choisir l'autorité de certification créée précédemment ("CA Provya (ca-provya)")
  • Server Certificate : choisir le certificat serveur créé précédemment ("Certificat Serveur (certif-serveur-provya)")
  • DH Parameters Length : . Nous laissons la valeur par défaut (1024 bits)

Exemple de résultat obtenu :





Export des certificats

La configuration coté serveur OpenVPN est terminée. Il reste à faire la configuration côté client.
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 :



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




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



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 :



Dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur l'icône en forme de "+" 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 : on choisit "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 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 l'icône en forme de "+" 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")
  • 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 :





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 Authentication : cocher la case "Enable authentication of TLS packets" pour davantage de sécurité. Nous ne conseillons pas de la cocher
  • 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")
  • DH Parameters Length : . Nous laissons la valeur par défaut (1024 bits)

Exemple de résultat obtenu :





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 l'icône en forme de "+" correspondant au CA qui signera cette CRL ("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 ou va signé cette CRL
  • Lifetime : la durée de vie de la CRL (9999 jours par défaut)
  • Serial : le numéro de série de la CRL (0 par défaut)

Exemple de résultat obtenu :



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



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



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.

icon Tags de l'article :