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 :
- realtime : bande-passante minimale garantie à une queue
- linkshare : bande-passante globale attribuée à la queue (utilisée une fois que realtime est plein)
- upperlimit : bande-passante maximale que la queue ne pourra jamais dépassée
- 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 :
- m1 : bande passante initiale attribuée à la queue
- m2 : bande passante définitive attribuée à la queue
- 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 :
- 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.
- 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.
- Random Early Detection (RED) : utilisé avec ECN, offre un mécanisme de détection de congestion (avant qu'elle n'ait lieu).
- 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
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : CBQHFSCpfSensepriorisation de traficPRIQQoS
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 :
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 :
- Parent interface : l'interface physique à laquelle sera rattachée le VLAN
- VLAN tag : l'ID du VLAN (la valeur doit être comprise entre 1 et 4094)
- VLAN Priority : la priorité à appliquer au VLAN (la valeur doit être comprise entre 0 et 7)
- Description : champ optionnel de description du VLAN
Exemple de résultat obtenu :
Et une fois nos deux VLANs créés, nous disposons de deux interfaces virtuelles :
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 :
Pour modifier l'interface logique créée (et la renommer), nous cliquons sur son nom. Les éléments de configuration sont les suivants :
- Enable Interface : cocher cette case pour activer l'interface
- Description : nom de l'interface
- IPv4 Configuration Type : la configuration IPv4 de cette interface. Dans notre cas, nous choisissons "Static IPv4"
- IPv6 Configuration Type : la configuration IPv6 de cette interface. Dans notre cas, nous choisissons "None"
- MAC controls : par défaut, c'est l'adresse MAC de l'interface physique qui est utilisée. Elle peut être personnalisée ici
- MTU : la MTU pour cette interface. 1500 octets par défaut
- MSS : "Maximum Segment Size", devrait être inférieur au MTU. Nous laissons vide
- 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 :
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 :
- 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)
- Configuration du port du switch sur lequel est branché le pfSense en mode trunk (ou tagged) sur les VLAN 10 et 20
- Configurer les ports du switch sur lesquels seront branchés les PC en mode access (ou untagged) - dans notre cas sur le VLAN 10
- 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.
Peut-on configurer un VLAN sur le port LAN ?
Réponse succincte : oui.
Sur les anciennes versions de pfSense (antérieures à la version 2.4.5), il était très fortement recommandé par l'éditeur de ne pas configurer un VLAN sur un port réseau qui était déjà associé à une interface logique.
Si les notions de port réseau, interface physique, interface virtuelle et interface logique ne vous sont pas familières, nous vous invitons à consulter notre article [pfSense] Comprendre la gestion des interfaces réseaux.
Cette configuration entraînait des anomalies de fonctionnement pour un certain nombre de services (dont le portail captif).
Ce n'est plus du tout le cas aujourd'hui. On peut donc tout à fait configurer ses VLAN sur un port réseau déjà associé à une interface logique !
Pour aller plus loin
[pfSense] Comprendre la gestion des interfaces réseaux
[pfSense] Configurer son serveur DHCP
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : pfSensesécuritéVLAN
English version: [pfSense] Secure remote access for your home-office workers with OpenVPN.
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) :
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
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 :
- une autorité de certification, sauf si nous en disposons déjà d'une
- un certificat serveur
- un certificat client
- les accès utilisateurs (login et mot de passe)
- le serveur OpenVPN en tant que tel
- les règles de firewall et de NAT idoines
- 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 :
- Import an existing Certificate Authority : permet d'importer le certificat (clé publique + clé privée) d'une autorité de certification existante
- Create an internal Certificate Authority : permet de créer une nouvelle autorité de certification
- 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 :
- Import an existing Certificate : permet d'importer la clé publique et la clé privée d'un certificat existant
- Create an internal Certificate : permet de créer une nouveau certificat
- 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 :
- User Certificate : pour définir un certificat pour un client
- 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 :
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 :
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 :
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
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : openVPNpfSenseutilisateurs nomadesVPN nomade
06/08/2019 - 5 commentaires
ou 
) tout à gauche de la ligne, cela affichera un popup vous indiquant quelle règle a autorisé ou interdit ce paquet.
