Le choix du bon matériel pour accueillir pfSense est toujours délicat. Il n'est pas évident de dimensionner correctement son firewall par rapport à son besoin, ni de choisir les bons composants lorsque l'on souhaite assembler son matériel soi-même.
Nous présentons dans cet article les éléments à prendre en considération pour le dimensionnement de son firewall, ainsi que les points de vigilance à avoir dans le choix des composants.
[Intro] Dimensionner son firewall, qu'est-ce que cela signifie ?
Avant de rentrer dans le vif du sujet, il est important de donner la définition du terme "dimensionner". Dans le choix d'un firewall, il va être important de définir les paramètres suivants :
- Débit attendu : élément essentiel du choix du matériel. Quel débit maximal souhaitons-nous que le firewall puisse supporter ?
- Mémoire-vive : de quelle quantité de mémoire-vive le firewall a-t-il besoin et quel est l'impact des services ou packages que j'active sur la consommation de mémoire ?
- Processeur : comment choisir correctement son processeur pour être sûr qu'il ne soit pas le goulet d'étranglement de mon firewall ?
- Disque-dur : quelle taille de disque-dur prévoir ? Faut-il opter pour un disque-dur SSD ?
Ces éléments sont les principales caractéristiques de dimensionnement à prendre en compte dans le choix de son firewall.
1. Quel débit ?
Le premier élément à prendre en considération est le débit souhaité. Est-ce 100 Mbps ? 1 Gbps ? 10 Gbps ? Ou davantage ?
Il faut également se poser la question de la connectique attendue : Ethernet (RJ45), Fibre Optique, WiFi, ... ?
Le débit standard actuel des réseaux modernes pour des entreprises de type TPE/PME est de 1 Gbps.
C'est un débit suffisant pour offrir de bonnes conditions de travail tout en répondant aux besoins d'évolutivité des débits des prochaines années. C'est donc le débit qu'il conviendra de retenir dans l'immense majorité des usages.
Ainsi, il nous paraît indispensable que votre firewall soit équipé de ports RJ45 Gigabits.
De plus, si votre firewall dispose de plusieurs ports réseaux 1 Gbps, il vous sera possible de faire de l'agrégation de liens afin d'accroître le débit offert (par exemple : 2x1 Gbps, 4x1 Gbps, ...).
Il est important de préciser ici que si votre firewall dispose de ports Gigabits, mais que vos switch disposent uniquement de ports Fast Ethernet (c'est-à-dire fonctionnant au maximum à 100 Mbps), alors le débit maximum que pourra offrir votre firewall sur chacune de ses interfaces connectée au switch sera de 100 Mbps.
Pour un usage intensif, de type très grande entreprise ou Centre de données (data center), il conviendra de prévoir une connectique fibre optique offrant des débits de 10 Gbps ou davantage.
Dans tous les cas, il est parfaitement inutile de voir trop large et de choisir des débits largement surdimensionnés ; cela augmentera sensiblement vos coûts d'acquisition sans aucun bénéfice à l'appui.
Dans l'article [pfSense] Comment bien choisir sa carte Wi-Fi, nous détaillons comment choisir sa carte WiFi pour pfSense afin d'être certain de faire le bon choix.
Enfin, et pour conclure sur le débit, il est important d'avoir conscience que ce n'est pas parce que votre firewall dispose de ports Gigabits que le débit maximum délivré sera d'1 Gbps sur chaque port !
En effet, si les autres composants matériels ne sont pas correctement dimensionnés (CPU trop faible, par exemple), si vous utilisez un VPN à haut niveau de chiffrement sans disposer d'accélération cryptographique ou si vous faites de l'inspection de trafic par exemple, alors le débit risque très fortement d'être ralenti.
D'une façon générale, les modules faisant de l'inspection de trafic (comme squidGuard, Snort, Suricata, ...) vont forcément légèrement ralentir le débit.
La plupart des autres modules disponibles sur pfSense ne vont pas ralentir le débit, mais vont principalement augmenter le besoin en ressource processeur ou en mémoire-vive.
2. L'impact des fonctionnalités sur le dimensionnement
Fonctionnement de base de pfSense
Pour fonctionner correctement, pfSense nécessite dans son installation par défaut de disposer de 256 à 512 Mo de mémoire-vive.
Ensuite, dans le fonctionnement de pfSense (et dans le fonctionnement de n'importe quel autre matériel de type stateful), chaque connexion est suivie dans la table d'état.
Pour chaque connexion, il y a 2 états de stockés dans la table : une pour la connexion entrante sur le firewall, l'autre pour la connexion sortante.
Un exemple simple d'une connexion est un ordinateur connecté sur le réseau local (sur le LAN) qui consulte le site web google.fr.
Attention : si l"utilisateur consulte en parallèle le site wikipedia.fr, alors il consomme une deuxième connexion, etc. Il ne faut donc pas penser qu'un ordinateur = une connexion qui sera stockée dans la table d'état. C'est potentiellement beaucoup plus.
La table d'état est stockée en mémoire-vive. Sa taille a donc un impact sur la mémoire-vive nécessaire. Il faut considérer que la consommation en mémoire-vive est la suivante :
- 50 000 connexions = 100 000 états = ~ 100 Mo de RAM
- 500 000 connexions = 1 000 000 états = ~ 1 Go de RAM
VPN
D'une façon générale, les VPN IPsec offrent un meilleur débit que les VPN OpenVPN.
L'impact du VPN sur le débit maximal possible va dépendre du choix du chiffrement. Si le matériel ne dispose pas d'accélération cryptographique, les débits vont très rapidement s'effondrer. En revanche, si le matériel supporte le jeu d'instruction AES (également appelé AES-NI), alors l'impact sur le débit sera extrêmement minime.
Ainsi, notre recommandation est clairement d'opter pour un processeur supportant l'AES-NI que vous utilisiez ou non la fonctionnalité VPN.
Snort/Suricata
Les modules Snort et Suricata vont avoir une consommation de mémoire-vive de l'ordre de 1 à 2 Go.
Leur impact sur le débit est très dur à quantifier et va dépendre principalement du processeur et du nombre d'instructions d'inspection de trafic qui sera configuré.
Squid
Squid utilise beaucoup le disque-dur (contrairement à pfSense qui, dans son usage par défaut, est très peu consommateur d'espace disque).
La quantité d'espace disque nécessaire va dépendre de la quantité de données que l'on souhaite conserver en cache et se paramètre dans la configuration de squid.
Pour le choix du type de disque-dur, on considère que jusqu'à environ une centaine d'utilisateurs, n'importe quel disque-dur (disposant d'une vitesse de rotation de 7 200 tour/min, qui est le standard) fera l'affaire.
Au-delà, le choix d'un disque SSD est clairement à privilégier. Si vous faites le choix d'un disque-dur SSD, il est indispensable de choisir un disque-dur SSD de qualité, autrement le nombre élevé de lecture-écriture produit par le proxy va provoquer une fin de vie rapide de votre SSD...
Concernant la mémoire-vive consommée par squid, il faut compter environ 15 Mo de mémoire-vive pour 1 Go de cache sur le disque-dur.
Soit, pour un cache de 100 Go, il faut compter 1,5 Go de mémoire-vive.
3. Bien choisir son matériel
Une fois le dimensionnement de son firewall défini, il est important de bien choisir son matériel afin qu'il soit pleinement compatible avec pfSense et pleinement évolutif.
Nos principales recommandations sont :
- Architecture 64 bits : les architectures 32 bits ne sont officiellement plus supportées à la fin du mois d'octobre 2018. Il est indispensable de choisir une architecture 64 bits ;
- Support de l'AES-NI : AES-NI permet une amélioration conséquente des débits offerts sur les connexions VPN. Il est indispensable de choisir un firewall équipé d'un processeur supportant la technologie AES-NI.
Si vous achetez un firewall déjà assemblé pour pfSense :
- Acheter son matériel en France et bénéficiant d'un remplacement/échange sous 24-48h : en cas de panne de votre firewall vous vous retrouvez bloqués (plus d'accès à Internet, plus d'accès distants, plus de VPN, etc.) ; pour les installation critiques, la mise en place de pfSense en haute-disponibilité est très fortement conseillée ; pour les autres installations, il est indispensable de pouvoir obtenir un matériel de remplacement rapidement ;
- Disposer d'une garantie matérielle d'au moins 3 ans : c'est la garantie que les composants sont tous de qualité ;
- Éviter les plateformes type Ebay, alibaba, etc. : les délais de livraisons sont très longs, vous risquez d'avoir à régler des droits de douane et des frais de dédouanement et la garantie sera compliquée à mettre en œuvre si votre matériel tombe en panne après plusieurs mois de fonctionnement ;
- Choisir un revendeur de confiance : il vous proposera du matériel de qualité et un service après-vente performant en cas de besoin.
Où acheter son firewall pour pfSense ?
De notre expérience, nous estimons qu'il existe aujourd'hui 2 solutions :
1/ Acquérir du matériel officiel vendu par la société Netgate (éditeur du logiciel pfSense). L'avantage est que vous bénéficiez du matériel officiel avec la garantie absolue qu'il est totalement supporté par l'éditeur. Les inconvénients principaux à nos yeux sont : les durées de garantie extrêmement courtes, le temps nécessaire pour un échange, le prix.
Boutique en ligne Netgate : https://store.netgate.com
2/ Acquérir du matériel vendu par Provya : face au besoin de disposer de matériel fiable et économique et au manque de solutions qui étaient disponibles sur le marché, nous avons décidé de façonner notre propre matériel, avec des composants de qualité et au meilleur coût. L'assemblage, le support et la garantie sont effectués par nos soins depuis la France ; tous nos matériels sont garantis 3 ans avec remplacement/échange en 24-48h, et les composants sont choisis avec soin pour fonctionner au mieux et durablement avec pfSense (support AES-NI, disque SSD de qualité, ...).
Boutique en ligne Provya : https://store.provya.fr
Vous avez maintenant toutes les cartes en main pour dimensionner correctement votre firewall pour pfSense !
Pour aller plus loin
[pfSense] Comment bien choisir sa carte Wi-Fi
Best practices / Recommandations pour la configuration de votre firewall
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : matérielpfSense
En informatique, il est important d'avoir ses équipements (ordinateurs, serveurs, routeurs, switch, etc.) qui soient toujours à l'heure. Pour cela, il est possible d'utiliser le protocole NTP et envoyer ses requêtes vers un serveur NTP public ou bien alors d'utiliser une puce GPS !
Dans cet article, nous présenterons comment installer et utiliser une clé GPS avec pfSense afin qu'il soit toujours à l'heure et l'intérêt de cette méthode par rapport à d'autres.
Être à l'heure : pourquoi ?
Tout équipement informatique dispose d'un horloge matérielle ou logicielle à laquelle il fait référence pour horodater des fichiers, des transactions, des courriers électroniques, des baux DHCP, des autorisations d'accès, etc.
Cette horloge, aussi précise soit-elle va dériver dans le temps comme toute montre ordinaire. Ceci va poser des problèmes de sécurité, notamment en terme de traçabilité et d'auditabilité. Ainsi que des problèmes de contrôles des accès.
Pour pallier ce problème, il est possible d'utiliser des serveurs de temps de référence qui seront interrogés via le protocole NTP. De nombreux serveurs NTP sont accessibles en libre accès sur Internet et il est également possible d'implémenter son propre serveur NTP.
pfSense peut parfaitement servir de serveur NTP interne pour vos équipements. Pour garder notre serveur pfSense à l'heure, il est nécessaire soit de le synchroniser avec un autre serveur NTP de référence (accessible via Internet), soit de lui ajouter une clé GPS afin qu'il se synchronise par satellite. Cette seconde solution offre généralement une meilleure précision sur le temps fourni et permet surtout d'être indépendant de tous serveurs NTP externes.
La solution GPS, généralement peu connue du grand public et des PME, est celle majoritairement adoptée par les Grands comptes et par les Datacenters.
Activer le service NTP et la clé GPS sur pfSense
La première étape consiste à activer le service NTP pour que pfSense joue le rôle de serveur NTP pour les équipements du réseau. Pour cela, nous nous rendons dans le menu Services > NTP :
Nous sommes redirigés par défaut sur l'onglet Settings. Les paramètres à configurer sont les suivants :
- Interface : précise la ou les interfaces sur laquelle pfSense va agir en tant que serveur NTP. Dans notre exemple, nous choisissons les interfaces LAN et WIFI. Il est à noter que pour des raisons de sécurité, il ne faut pas rendre accessible par Internet le service NTP de pfSense.
- Time Servers : la liste de serveurs NTP avec lesquels pfSense pourra se synchroniser. Après avoir installé la clé GPS, ces serveurs serviront de serveurs de secours en cas de panne ou de défaillance de la clé GPS. Dans notre cas, nous utilisons le pool de serveurs par défaut 0.pfsense.pool.ntp.org. Si vous choisissez d'autres serveurs NTP, veillez à ajouter un pool ou une liste d'au moins 4 ou 5 serveurs.
Il reste à cliquer sur le bouton "Save" en bas de page.
Exemple de résultat obtenu :
Nous basculons sur l'onglet "Serial GPS". Les paramètres à configurer sont les suivants :
- GPS Type : sélectionnez votre modèle de GPS s'il figure dans la liste. Dans notre cas, il n'apparaît pas, nous choisissons donc Default.
- Serial Port : le port sur lequel le GPS est connecté. S'il s'agit d'un port série, le nom du port aura pour forme cuau (cuau0, cuau1, ...). S'il s'agit d'un port USB, le nom aura pour forme cuaU (cuaU0, cuaU1, ...). Dans notre cas, notre clé GPS étant connectée sur un port USB, nous choisissons cuaU0.
- Fudge Time 2 : ce champ permet de préciser un offset pour notre clé GPS. Si votre GPS est branché sur un port série, il faut laisser ce champ vide. En revanche, si vous utilisez un GPS connecté sur un port USB, alors il est nécessaire de préciser un offset de 0,5 seconde afin de compenser la latence introduite par le port USB. Dans notre cas, notre clé GPS étant connectée sur un port USB, nous indiquons la valeur 0.5.
- Flags : s'assurer que la case "Prefer this clock" soit bien cochée (par défaut).
Il reste à cliquer sur le bouton "Save" pour valider sa configuration et c'est tout ! Notre clé GPS est prête à fonctionner.
Exemple de résultat obtenu :
Vérifier le bon fonctionnement
Pour vérifier le bon fonctionnement du service NTP, se rendre dans le menu Status > NTP.
Exemple dans notre cas :
On peut voir que la clé GPS est le peer actif pour servir de référence de temps à pfSense.
On peut voir que le pool 0.pfsense.pool.ntp.org comporte bien plusieurs serveurs de temps joignables (4 sur la capture d'écran) prêts à prendre le relais en cas de problème avec la puce GPS.
On peut également voir la localisation (latitude et longitude) de sa clé GPS, avec un lien vers Google Maps.
Sur la capture d'écran suivante, on peut constater un problème avec la clé GPS (statut False Ticker) et qu'un serveur NTP tiers à pris le relais :
Cela arrive si votre clé GPS n'arrive pas à capter correctement le signal satellitaire ou si vous avez oublié de saisir un offset de 0,5 seconde pour un GPS connecté en USB.
Comment choisir sa clé GPS compatible pfSense
Pour le choix de sa clé GPS, il est indispensable de s'assurer que celle-ci soit compatible avec le logiciel pfSense et qu'elle dispose d'un câble suffisamment long. Ce qui n'est pas le cas de toutes les puces GPS...
Nous proposons sur notre boutique en ligne une clé GPS connectable en USB et 100% compatible avec les systèmes pfSense, FreeBSD et Linux. D'autres choix sont bien-sûr possibles. Il faut simplement s'assurer que la clé GPS choisie soit bien compatible.
Pour aller plus loin
[pfSense] Bien choisir et dimensionner son firewall
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : pfSense
English version: [pfSense] Configuring High Availability.
Dans cet article, nous allons voir comment configurer deux serveurs pfSense en mode cluster afin d'assurer un service en haute-disponibilité.
Il est à noter que pfSense est l'une des rares solutions open-source offrant des techniques de haute-disponibilité permettant de garantir que le firewall ne puisse pas être un point individuel de défaillance (SPOF).
Dans cet article, nous nous baserons sur l'architecture suivante pour réaliser nos configurations :
pfSenseA - WAN : 172.25.46.101
pfSenseB - WAN : 172.25.46.102
@IP virtuelle - WAN : 172.25.46.100
pfSenseA - LAN : 192.168.0.11
pfSenseB - LAN : 192.168.0.12
@IP virtuelle LAN : 192.168.0.10
Principe de fonctionnement
pfSense communique sur les réseaux LAN & WAN avec ses adresses IP virtuelles ; il n'utilise jamais l'adresse IP assignée à son interface.
En cas de défaillance de pfSenseA (pfSense primaire), pfSenseB (pfSense secondaire) prend le relais sans aucune interruption de service. La bascule de pfSenseA vers pfSenseB est totalement transparente.
Afin d'assurer la réplication du serveur pfSenseA vers le serveur pfSenseB, 3 éléments doivent être configurés : CARP, pfsync et XML-RPC.
CARP
CARP (Common Address Redundancy Protocol) est un protocole permettant à plusieurs hôtes présents sur un même réseau de partager une adresse IP.
Ici, nous utilisons CARP afin de partager une adresse IP WAN et une adresse IP LAN sur nos serveurs pfSense.
C'est cette adresse IP virtuelle que pfSense va utiliser pour sa communication sur le réseau. Ainsi, en cas de défaillance du pfSense primaire (pfSenseA), le pfSense secondaire (pfSenseB) prendra le relais de manière transparente au niveau réseau (reprise de l'adresse IP virtuelle).
pfsync
pfsync est un protocole permettant de synchroniser entre deux serveurs pfSense l'état des connexions en cours (et de manière plus large entre deux serveurs exécutant le firewall Packet Filter). Ainsi, en cas de défaillance du serveur primaire, l'état des connexions en cours est maintenu sur le serveur secondaire. Il n'y a donc pas de coupure liée à la bascule des services du pfSenseA vers le pfSenseB.
Il est recommandé d'effectuer cette synchronisation sur un lien dédié entre les deux serveurs pfSense. À défaut, le lien LAN peut être utilisé.
La réplication peut se faire d'un serveur primaire vers un ou plusieurs autres serveur(s).
XML-RPC
XML-RPC est un protocole permettant la réplication de données d'un serveur vers un autre. Il est utilisé dans pfSense afin de répliquer la configuration du serveur primaire vers le serveur secondaire.
Pour garantir son bon fonctionnement, il est important qu'il utilise la même interface que celle utilisée par le protocole pfsync.
1. Configurer les adresses IP virtuelles
Afin de fonctionner, chaque serveur pfSense doit disposer d'une adresse IP sur son interface, ainsi qu'une adresse IP virtuelle qui sera partagée entre les deux serveurs pfSense. De ce fait, nous utilisons 3 adresses IP par réseau.
Pour configurer l'adresse IP virtuelle, se rendre dans "Firewall" > "Virtual IPs" :
Cliquer sur l'icône "+ Add" pour ajouter une adresse IP virtuelle.
Les éléments à configurer sont les suivants :
- Type : ici, nous avons quatre possibilités :
- IP Alias
- CARP
- Proxy ARP
- Other
Nous choisissons "CARP". Nous ne rentrons pas ici dans le détail de l'usage de chaque option. Pour plus d'informations, nous vous invitons à lire l'article What are Virtual IP Addresses - EN.
- Interface : l'interface sur laquelle la VIP doit être configurée. Nous configurons la première sur l'interface WAN, puis la seconde sur l'interface LAN.
- Address(es) : l'adresse VIP et le masque du subnet de l'interface. Dans notre exemple : 172.25.46.100 et /24
- Virtual IP Password : mot de passe permettant de sécuriser les échanges au sein du groupe d'hôtes se partageant la VIP. Ce mot de passe devra être re-saisi sur le pfSense secondaire.
- VHID Group : Virtual Host Identifier. Un serveur peut faire parti de plusieurs groupes de VIP. Afin d'identifier chaque groupe, un ID unique lui est assigné. Nous laissons la valeur par défaut.
- Advertising Frequency : la valeur du champ "Skew" à 0 désigne le master (pfSense primaire). Une valeur plus élevée désignera l'esclave (pfSense de secours). La valeur de "Base" correspond au timeout en seconde au bout duquel l'hôte sera considéré comme inaccessible. Nous recommandons de laisser la valeur par défaut : 1.
Exemple de résultat obtenu :
Nous procédons à la même configuration sur l'interface LAN.
Enfin, nous réalisons les mêmes configurations sur les interfaces WAN et LAN du serveur de secours (pfSenseB), en pensant bien à passer la valeur du champ "Skew" à 1.
Nous pouvons vérifier l'état de nos adresses IP virtuelles depuis le menu "Status"> "CARP (failover)" :
Dans le cas présent, les deux adresses VIP créées ont bien le statut "master" sur le pfSenseA :
2. Forcer l'utilisation des adresses IP virtuelles
Les adresses VIP sont déclarées, mais non-utilisées. Il reste à configurer pfSense pour qu'il utilise les adresses VIP plutôt que les adresses IP attribuées à ses interfaces logiques.
Pour cela, nous devons configurer pfSense pour qu'il utilise l'adresse VIP WAN sur le trafic sortant, l'adresse VIP LAN pour le trafic entrant et configurer les différents services pour qu'ils travaillent avec l'adresse VIP LAN comme adresse par défaut (pour les configuration OpenVPN ou DHCP, par exemple).
Configuration du NAT
Nous allons dans le menu Firewall > NAT. Dans l'onglet Outbound, nous cochons la case "Hybrid Outbound NAT rule generation. (Automatic Outbound NAT + rules below)".
Nous modifions les règles ou en ajoutons une afin que le trafic sortant utilise l'adresse VIP. Les champs à configurer sont les suivants :
- Disabled : cocher cette case pour désactiver la règle sans devoir la supprimer.
- Do not NAT : cocher cette case permet de désactiver le NAT pour le trafic correspondant à cette règle. Il est très rare de devoir cocher cette case.
- Interface : l'interface logique sur laquelle nous souhaitons définir notre règle de NAT. Dans notre cas, nous choisissons "WAN".
- Protocol : les protocoles concernés par cette règle de NAT. Nous choisissons "any"
- Source : le réseau source. Dans notre cas, il s'agit du réseau local, nous saisissons donc "192.168.0.0" et "/24" pour le masque.
- Destination : le réseau de destination. Dans notre cas, nous choisissons "any".
- Address : l'adresse à utiliser lors du NAT. Nous choisissons l'adresse VIP créée précédemment, soit "172.25.46.100 (VIP WAN)".
- Port : nous laissons ce champ vide.
- No XMLRPC Sync : cocher cette case pour ne pas copier la règle sur le pfSense secondaire. Nous laissons cette case non-cochée.
- Description : un champ informatif
Exemple de résultat obtenu :
Cette configuration n'est à faire que sur le pfSense primaire. La configuration sera dupliquée automatiquement sur le pfSense secondaire.
Configuration du service DHCP
Si pfSense fait office de serveur DHCP, nous allons dans le menu "Services" > "DHCP Server". Nous modifions le champ "Gateway" pour y préciser l'adresse VIP (192.168.0.10). Autrement, le serveur DHCP de pfSense va continuer à indiquer aux clients du service DHCP l'adresse IP de l'interface LAN du pfSense.
Nous pouvons également compléter le champ "Failover peer IP" en renseignant l'adresse IP de l'interface LAN du pfSense secondaire (192.168.0.12). Cette configuration optionnelle permet de partager les leases DHCP entre le pfSense primaire et le pfSense secondaire.
Attention, si ce champ est renseigner, il est nécessaire de modifier la valeur du "skew" du pfSense secondaire pour le passer à un nombre supérieur à 20.
Davantage d'informations sur la configuration du service DHCP : [pfSense] Configurer son serveur DHCP.
Configuration du service OpenVPN server
Si un serveur OpenVPN est configuré sur le pfSense, il est nécessaire de modifier l'interface d'écoute du service (normalement "WAN") pour la remplacer par l'adresse VIP (172.25.46.100).
Cette modification s'opère dans "VPN" > "Servers".
Davantage d'informations sur la configuration du service OpenVPN : [pfSense] Monter un accès OpenVPN site-à-site.
Configuration du service VPN IPsec
Si un tunnel IPsec est configuré sur le pfSense, il est nécessaire de modifier l'interface d'écoute du VPN IPsec (normalement "WAN") pour la remplacer par l'adresse VIP (172.25.46.100).
Cette modification s'opère dans "VPN" > "IPsec". La modification s'effectue sur la phase 1.
Davantage d'informations sur la configuration du service VPN IPsec : [pfSense] Configurer un VPN IPsec site à site.
3. Configurer la haute-disponibilité
Il nous reste à configurer la haute-disponibilité. Pour cela, se rendre dans "System" > "High Avail. Sync" :
Depuis cette page, il y a 2 éléments à configurer : la partie pfsync (pour la synchronisation d'état) et XMLRPC Sync (pour la synchronisation de la configuration).
State Synchronization Settings (pfsync)
Les éléments à configurer sont les suivants :
- Synchronize States : cocher cette case pour activer pfsync (cette configuration est à faire sur le pfSense primaire et sur le pfSense secondaire)
- Synchronize Interface : l'interface de synchronisation. Si nous disposons d'une interface dédiée à la synchronisation, nous la choisissons ; autrement, nous choisissons "LAN".
- pfsync Synchronize Peer IP : sur le pfSense primaire, saisir l'adresse IP du serveur pfSense de secours (192.168.0.12). Si pour le choix de l'interface (ci-dessus) nous avons choisi "LAN", nous indiquons l'adresse IP de l'interface LAN du pfSense secondaire (192.168.0.12) ; si nous avons choisi une interface dédiée alors nous indiquons l'adresse IP de l'interface dédiée du pfSense secondaire. Par défaut, si aucune adresse IP n'est saisie, pfSense diffusera en multicast sur l'interface choisie préalablement. Sur le pfSense secondaire, on indique l'adresse IP du pfSense primaire (192.168.0.11)
Configuration Synchronization Settings (XMLRPC Sync)
- Synchronize Config to IP : sur le serveur pfSense primaire, saisir l'adresse IP du serveur pfSense secondaire (comme précédemment, il faut saisir l'adresse IP de l'interface choisie). Ce doit être la même adresse IP que celle renseignée dans le champ "pfsync Synchronize Peer IP". Ce champ doit être laissé vide sur le serveur pfSense secondaire.
- Remote System Username : sur le serveur pfSense primaire, saisir le nom d'utilisateur utilisé pour se connecter sur le WebGUI du pfSense de secours ("admin" par défaut). Ce champ doit être laissé vide sur le serveur pfSense de secours.
- Remote System Password : sur le serveur pfSense primaire, saisir le mot de passe du compte utilisateur saisi ci-dessus. Ce champ doit être laissé vide sur le serveur pfSense de secours.
Puis, nous choisissons les services que nous souhaitons synchroniser en cochant les cases appropriées. Par défaut, nous recommandons de tout cocher (Toggle All).
Exemple de résultat obtenu :
Autoriser les flux de réplication au niveau des règles du firewall
Il nous reste à autoriser les flux de réplications sur les firewall. La configuration se passe dans "Firewall" > "Rules".
Si la réplication se fait via l'interface LAN, les règles de firewall sont à appliquer sur cette interface ; si nous utilisons une interface dédiée, les règles seront à appliquer sur celle-ci.
Il y a deux flux réseau à autoriser :
- le flux pour la synchronisation XML-RPC qui s'effectue via le port 443
- le flux pour la synchronisation du protocole pfsync
Sur le firewall primaire, nous créons donc une première règle de firewall (en cliquant sur le bouton "Add") avec les paramètres suivants :
- Action : nous choisissons "Pass"
- Interface : nous choisissons l'interface dédiée à la réplication si le pfSense en possède une. Autrement, nous choisissons "LAN"
- Address Family : nous laissons "IPv4"
- Protocol : nous choisissons "TCP"
- Source : nous indiquons un alias qui contiendra les adresses IP des interfaces de synchronisation de chaque pfSense (dans notre cas, cet alias contiendra les adresses IP "192.168.0.11" et "192.168.0.12"). Si cette notion d'alias n'est pas claire pour vous, vous pouvez consulter notre article dédié [pfSense] Tout comprendre aux alias, ou vous pouvez choisir l'ensemble du réseau rattaché à l'interface de synchronisation (dans notre cas, ce serait "LAN net")
- Destination : nous choisissons "This firewall (self)"
- Destination port range : choisir "HTTPS (443)"
Exemple de résultat obtenu :
Sur le firewall primaire toujours, nous créons une seconde règle de firewall avec les paramètres suivants :
- Action : nous choisissons "Pass"
- Interface : nous choisissons l'interface dédiée à la réplication si le pfSense en possède une. Autrement, nous choisissons "LAN"
- Address Family : nous laissons "IPv4"
- Protocol : nous choisissons "PFSYNC"
- Source : nous indiquons un alias qui contiendra les adresses IP des interfaces de synchronisation de chaque pfSense (dans notre cas, cet alias contiendra les adresses IP "192.168.0.11" et "192.168.0.12"). Si cette notion d'alias n'est pas claire pour vous, vous pouvez choisir l'ensemble du réseau rattaché à l'interface de synchronisation (dans notre cas, ce serait "LAN net")
- Destination : nous choisissons "This firewall (self)"
Exemple de résultat obtenu :
Ces deux règles de firewall ont été répliquées automatiquement sur le pfSense secondaire.
4. Vérifier le bon fonctionnement de la haute-disponibilité
L'ensemble doit, à ce stade, être opérationnel. Vérifions !
Vérifier le statut du CARP (adresse VIP)
Nous pouvons vérifier l'état de nos adresses IP virtuelles depuis le menu "Status"> "CARP (failover)" :
Les adresses VIP doivent avoir le statut "MASTER" sur le pfSense primaire et "BACKUP" sur le pfSense secondaire.
Vérifier la réplication
Nous pouvons naviguer dans le menu "Firewall" > "Rules" et "Firewall" > "NAT" et vérifier que les règles créées sur le pfSense primaire sont bien présentes également sur le pfSense secondaire.
Faire des tests !
Avant toute chose, à ce stade, il est important de faire une sauvegarde de vos serveurs pfSense ("Diagnostics" > "Backup & Restore").
Ensuite, pour tester le bon fonctionnement de la haute-disponibilité, plusieurs tests peuvent être réalisés. En voici quelques exemples :
- arrêter le pfSense primaire
- débrancher le câble réseau de l'interface LAN ou WAN du pfSense primaire
- désactiver le service CARP sur le pfSense primaire ("Status" > "CARP (failover)")
- télécharger un fichier ou lancer des requêtes ping lors de la bascule du primaire vers le secondaire
Pour aller plus loin
[pfSense] Comprendre la gestion des interfaces réseaux
[pfSense] Configurer son serveur DHCP
[pfSense] Tout comprendre aux alias
[pfSense] Mettre à jour son serveur pfSense
[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Configurer un dual-WAN (plusieurs connexions Internet)
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : failoverpfSense
English version: [pfSense] Bridging interfaces
Dans son mode de fonctionnement par défaut, chaque interface de pfSense dispose de son propre plan d'adressage qui doit être unique.
Il est parfois nécessaire de disposer du même plan d'adressage sur plusieurs interfaces. C'est pratique pour disposer d'un seul sous-réseau pour son LAN et son Wi-fi, pour disposer du même réseau multicast ou encore pour mettre en place un firewall transparent sur un réseau sans avoir à modifier le plan d'adressage existant (en faisant un pont entre l'interface LAN et WAN, par exemple).
Il est très facile de mettre en œuvre un pont réseau entre plusieurs interfaces sur pfSense et de continuer à disposer, si on le souhaite, de règles de filtrage entre ces interfaces.
Dans cet article nous configurerons un pont réseau entre notre interface LAN et notre interface Wi-fi. Ainsi, ces deux interfaces disposeront du même plan d'adressage IP et du même domaine de broadcast.
1. Préparation des interfaces membres du pont-réseau
Chaque interface que nous souhaitons ajouter à notre pont réseau doit être créée et ne pas avoir d'adresse IP. Ce point est important. Ainsi, si nous souhaitons ajouter notre interface LAN à un pont réseau, il est indispensable de faire les configurations depuis une autre interface (depuis l'interface WAN, par exemple, sur laquelle nous aurons temporairement autorisé l'accès à l'interface d'administration du pfSense).
Exemple de configuration pour les interfaces LAN et WIFI :
Pour rappel : [pfSense] Configurer son point d'accès Wi-Fi
2. Configuration du pont-réseau
Une fois ces deux éléments de configuration réalisés, nous nous rendons dans le menu Interfaces > Assignments, puis onglet Bridges :
Nous cliquons sur le bouton "+Add". La configuration est la suivante :
- Member Interfaces : les interfaces membres du pont-réseau. Dans notre cas, LAN et WIFI
- Description : une description facultative
- Advanced Options : suivant votre configuration, il peut être pertinent d'activer le protocole Spanning Tree (RSTP/STP). Pour un pont entre un réseau filaire et sans-fil, cela n'est pas forcément nécessaire. Dans notre cas, nous ne modifions pas les options avancées.
Exemple de résultat obtenu :
Nous cliquons sur le bouton "Save" pour valider notre configuration. Et notre port réseau BRIDGE0 est créé. Il nous reste à lui associer une interface logique afin de pouvoir le configurer (pour rappel, pour bien comprendre la différence entre ports réseaux, interfaces logiques, interfaces virtuelles, etc. vous pouvez consulter notre article dédié : [pfSense] Comprendre la gestion des interfaces réseaux.
Nous retournons dans l'onglet Interface Assignments, puis nous cliquons sur le bouton "+Add" après avoir pris soin de sélectionner notre interface BRIDGE0 :
Il nous reste à configurer cette interface en lui précisant son adresse IP et en lui donnant un nom.
Exemple de résultat obtenu :
Point d'attention : vous pouvez remarquer que sur la capture d'écran, nous avons configuré le champ "MAC Address". La raison est que si ce champ est laissé vide, l'adresse MAC d'une interface "pont-réseau" est générée aléatoirement à la création de l'interface et lors du redémarrage du firewall. Le problème est que les ordinateurs qui tournent sous un Windows récent (Vista et suivants) utilisent l'adresse MAC de la gateway comme identifiant du réseau. Ainsi, si l'adresse MAC change, les ordinateurs Windows estimeront qu'il s'agit d'un nouveau réseau et demanderont à leurs utilisateurs de le paramétrer en précisant s'il s'agit d'un réseau privé/public/etc. En forçant l'adresse MAC, nous évitons ce problème.
Notre pont-réseau est créé. La configuration des services devra être effectuée pour cette interface (dans notre cas "LANFI") : DHCP, firewall, DNS, NTP, etc.
Il reste une dernière subtilité importante : le filtrage.
3. Configuration du filtrage (subtilité à connaître)
Par défaut, pfSense applique les règles de filtrage uniquement sur les interfaces des membres du pont-réseau et non pas sur l'interface du pont-réseau elle-même.
Cela signifie que, dans notre cas, par défaut, uniquement les règles de filtrage définies sur les interfaces LAN et WIFI sont prises en compte par pfSense. Les règles que nous pourrions créer sur l'interface LANFI seront ignorées !
Ce comportement par défaut permet d'avoir des règles de filtrages différentes pour chaque interface membre du pont.
Il est possible de modifier ce comportement afin que les règles de filtrage définies sur l'interface du pont-réseau soient prises en compte.
Cette modification s'opère depuis le menu System > Advanced, onglet System Tunables :
- le paramètre net.link.bridge.pfil_member : active le filtrage sur l'interface de chaque membre du pont-réseau lorsqu'il est positionné à 1
- le paramètre net.link.bridge.pfil_bridge : active le filtrage sur l'interface du pont-réseau lui-même lorsqu'il est positionné à 1
Il faut donc positionner la valeur du paramètre net.link.bridge.pfil_bridge à 1 si nous souhaitons appliquer nos règles de filtrage sur l'interface du pont-réseau.
Enfin, il faut garder en tête que seul le pont-réseau dispose d'une adresse IP sur son interface. Ainsi si nous souhaitons appliquer des règles de filtrages directement sur chaque interface membre du pont, nous pouvons travailler avec les valeurs LANFI_net et LANFI_address, mais pas LAN_net, WIFI_net, LAN_address et WIFI_address (car celle-ci ne sont pas définies).
4. Les limites
Il existe quelques limites à l'utilisation d'un pont-réseau sous pfSense. Les principales limites ou contraintes sont les suivantes :
Portail captif
Pour que le portail captif fonctionne correctement, il est important que la passerelle par défaut des clients soit l'adresse IP de l'interface du pont-réseau. Ainsi, il n'est pas possible de mettre en œuvre un portail captif sur un pfSense où le LAN et le WAN seraient liés en un pont-réseau.
Haute-disponibilité
Il est plutôt déconseillé d'utiliser des pont-réseaux dans un environnement en haute-disponibilité. Cela peut créer des dysfonctionnements ou des boucles réseaux. Si vous souhaitez absolument utiliser un environnement pfSense en haute-disponibilité avec des pont-réseaux, il est indispensable que le protocole Spanning Tree soit activé sur vos switch et sur le pont-réseau.
Multi-WAN
Comme pour le portail captif, il faut s'assurer que la passerelle par défaut des clients soit l'adresse IP de l'interface du pont-réseau. Autrement, vous risquez de rencontrer un problème de routage asymétrique.
Proxy transparent
Idem. Il faut s'assurer que la passerelle par défaut des clients soit l'adresse IP de l'interface du pont-réseau. De plus, un package comme Squid ne peut pas fonctionner dans un scénario de firewall transparent où les interfaces LAN et WAN sont liées sur un même pont-réseau.
Voilà ! Notre pont réseau est fonctionnel et vous connaissez les subtilités à connaître pour sa configuration.
Pour aller plus loin
[pfSense] Configurer son point d'accès Wi-Fi
[pfSense] Comprendre la gestion des interfaces réseaux
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 : interfaces réseaux pfSensepfSense
Il existe plusieurs méthodes pour monter un tunnel VPN site-à-site avec OpenVPN. Les deux principales consistent en l'utilisation de clés partagées ou en l'utilisation de certificats (X.509).
Après notre premier article sur la configuration d'OpenVPN avec clé partagée, nous abordons ici sa configuration avec la gestion des certificats.
Article mis à jour le : 17/09/2019
À noter : nous ne détaillons pas dans cet article tous les détails de configuration d'OpenVPN. Nous nous concentrons sur la création, l'utilisation et la révocation des certificats. Il existe déjà un article dédié à la configuration d'OpenVPN : [pfSense] Monter un accès OpenVPN site-à-site.
Principe de fonctionnement
Le client et le serveur OpenVPN sont authentifiés à l'aide de certificats. Pour cela, ces certificats doivent être émis par une autorité de certification reconnue comme sûre aussi bien par le serveur que par le client.
Dans notre cas, nous créerons une autorité de certification (appelée "CA" pour Certificate Authority) sur le pfSense faisant office de serveur. Puis nous créerons deux certificats : un certificat client (qui sera utilisé côté Client) et un certificat serveur (qui sera utilisé côté Serveur). Ces deux certificats seront signés par l'autorité de certification que nous aurons créé précédemment.
Pour signer un certificat, il est nécessaire de disposer de la clé privée de l'autorité de certification.
Pour valider la signature d'un certificat, il est nécessaire de disposer de la clé publique de l'autorité de certification.
Création d'une autorité de certification - CA
Actions à effectuer coté serveur OpenVPN
Pour commencer, nous nous rendons dans le menu System > Cert Manager :
Dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur le bouton "+ Add" se trouvant en bas à droite de la liste des CAs existants.
Les champs à renseigner sont les suivants :
- Descriptive name : le nom que l'on souhaite donner à notre autorité de certification
- Method : 3 méthodes sont possibles :
- Create an internal Certificate Authority : permet de créer une nouvelle autorité de certification
- Import an existing Certificate Authority : permet d'importer le certificat (clé publique + clé privée) d'une autorité de certification existante
- Create an intermediate Certificate Authority : permet de créer une autorité de certification intermédiaire. Cette autorité de certification intermédiaire doit être rattachée à une autorité de certification existante
Dans notre cas, côté serveur, nous créerons une nouvelle autorité de certification (Create an internal Certificate Authority). Côté client, nous importerons la clé publique de l'autorité de certification créée côté serveur (Import an existing Certificate Authority).
- Key length : la longueur de la clé de chiffrement du certificat. Nous gardons la valeur par défaut : 2048
- Digest Algorithm : la fonction de hachage qui sera utilisée. Nous gardons la valeur par défaut : SHA256
- Common Name : le nom du certificat sans espaces, ni caractères spéciaux ou accentués. Ce nom doit être unique.
- Lifetime : la durée de vie de l'autorité de certification. Si nous n'avons pas de raison de réduire sa durée de vie, nous laissons la valeur par défaut (10 ans)
- Autres champs : l'ensemble des champs suivants sont principalement cosmétiques et doivent permettre d'identifier l'organisation. Ils peuvent être laissés vides ou complétés.
Exemple de résultat obtenu :
Nous validons notre configuration en cliquant sur le bouton "Save".
Notre autorité de certification est créée.
Création d'un certificat serveur
Nous restons dans le menu System > Cert Manager et basculons sur l'onglet "Certificates" (deuxième onglet).
Pour créer un nouveau certificat (client ou serveur), nous cliquons sur le bouton "+ Add/Sign" se trouvant en bas à droite de la liste des certificats existants.
Les champs à renseigner sont les suivants :
- Method : 4 méthodes sont possibles :
- Create an internal Certificate : permet de créer une nouveau certificat
- Import an existing Certificate : permet d'importer la clé publique et la clé privée d'un certificat existant
- 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.
- Sign a Certificate Signing Request : permet de signer un fichier de requête
Dans notre cas, nous créons un nouveau certificat (Create an internal Certificate).
- Descriptive name : le nom que l'on souhaite donner à notre certificat serveur
- Certificate authority : l'autorité de certification qui signera le certificat que nous sommes en train de créer. Dans notre cas, nous choisissons le CA que nous venons de créer, soit "CA Provya"
- Key length : la longueur de la clé de chiffrement du certificat. Nous gardons la valeur par défaut : 2048
- Digest Algorithm : la fonction de hachage qui sera utilisée. Nous gardons la valeur par défaut : SHA256
- Lifetime : la durée de vie du certificat. Si nous n'avons pas de raison de réduire sa durée de vie, nous laissons la valeur par défaut (10 ans)
- Common Name : le nom du certificat sans espaces, ni caractères spéciaux ou accentués. Ce nom doit être unique.
- Autres champs : l'ensemble de ces champs sont principalement cosmétiques et doivent permettre d'identifier l'organisation émettrice du certificat. Ils peuvent être laissés vides ou complétés.
- Certificate Type : le type de certificat. Il existe 2 valeurs possibles :
- 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".
Exemple de résultat obtenu :
Nous validons notre configuration en cliquant sur le bouton "Save".
Notre certificat pour le serveur OpenVPN est créé.
Création d'un certificat client
Nous procédons exactement de la même manière que pour la création d'un certificat serveur. Le seul élément distinctif est le champ Certificate Type pour lequel nous choisissons "User Certificate".
Exemple de résultat obtenu :
Nous validons notre configuration en cliquant sur le bouton "Save".
Notre certificat pour le client OpenVPN est créé.
Configuration du serveur OpenVPN
Le détail de la configuration du serveur OpenVPN se trouve dans l'article dédié [pfSense] Monter un accès OpenVPN site-à-site.
Les différences au moment de la configuration sont les suivantes :
- Server Mode : choisir "Peer to Peer (SSL/TLS)"
- TLS Configuration : cocher la case "Use a TLS Key" pour davantage de sécurité. Nous conseillons de la cocher. La clé TLS sera générée automatiquement. Il restera à la copier côté client.
- Peer Certificate Authority : choisir l'autorité de certification créée précédemment ("CA Provya")
- Server Certificate : choisir le certificat serveur créé précédemment ("Certificat serveur OpenVPN Provya (Server: Yes, CA: CA Provya)")
- DH Parameters Length : Nous laissons la valeur par défaut (1024 bits)
Exemple de résultat obtenu :
La configuration coté serveur OpenVPN est terminée. Il reste à faire la configuration côté client.
Export des certificats
Nous devons exporter le certificat de l'autorité de certification (c'est-à-dire sa clé publique), ainsi que le certificat et la clé privée du client OpenVPN.
Pour cela, nous retournons dans le menu System > Cert Manager :
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 :
Puis, dans l'onglet "Certificates", nous cliquons successivement sur les icônes "Export Certificate" et "Export Key" du certificat client que nous avons créé précédemment :
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 le bouton "+ Add" se trouvant en bas à droite de la liste des CAs existants.
Nous allons importer la clé publique du CA que nous avons créé sur le serveur OpenVPN.
Les champs à remplir sont les suivants :
- Descriptive name : le nom que l'on souhaite donner à notre autorité de certification. Nous gardons le même que celui qui a été donné sur le serveur OpenVPN ("CA Provya")
- Method : nous choisissons "Import an existing Certificate Authority"
- Certificate data : on copie dans ce champ le contenu de la clé publique (.crt)
- Certificate Private Key (optional) : si l'on souhaite importer la clé privée (.key), elle est à copier dans ce champ. Dans notre cas, nous le laissons vide. En effet, nous ne souhaitons pas signer de nouveaux certificats (nécessite la clé privée de l'autorité de certification), nous souhaitons seulement valider la signature du certificat qu'utilise le serveur OpenVPN (nécessite la clé publique de l'autorité de certification)
- Serial for next certificate : ce champ est à remplir uniquement si l'on importe une clé privée. Dans ce cas, il est important que chaque certificat créé par un CA dispose d'un numéro de série unique (autrement, nous risquons de rencontrer des problèmes en cas de révocation de certificat). Il faut donc choisir une valeur suffisamment grande (supérieure au nombre de certificat déjà créé par ce CA) afin d'éviter toute collision.
Exemple de résultat obtenu :
Nous validons en cliquant sur le bouton "Save".
Import de la clé publique et de la clé privée du certificat client OpenVPN
Nous restons dans le menu System > Cert Manager et basculons sur l'onglet "Certificates" (deuxième onglet).
Nous cliquons sur le bouton "+ Add/Sign" se trouvant en bas à droite de la liste des certificats existants.
Nous allons importer la clé publique et la clé privée du certificat client que nous avons créé sur le pfSense serveur OpenVPN.
Les champs à remplir sont les suivants :
- Method : on choisit "Import an existing Certificate"
- Descriptive name : le nom que l'on souhaite donner à notre certificat. Nous gardons le même que celui qui a été donné sur le serveur OpenVPN ("Certificat client OpenVPN Provya")
- Certificate data : on copie dans ce champ le contenu de la clé publique (.crt)
- Private key data : on copie dans ce champ le contenu de la clé privée (.key)
Exemple de résultat obtenu :
Nous validons en cliquant sur le bouton "Save".
Configuration du client OpenVPN
Le détail de la configuration du client OpenVPN se trouve dans l'article [pfSense] Monter un accès OpenVPN site-à-site.
Les différences au moment de la configuration sont les suivantes :
- Server Mode : choisir "Peer to Peer (SSL/TLS)"
- TLS Configuration : cocher la case "Use a TLS Key" pour davantage de sécurité. Décocher la case "Automatically generate a TLS Key", et copier dans le champ "TLS Key" la clé TLS qui a été généré côte serveur OpenVPN.
- Peer Certificate Authority : choisir l'autorité de certification importée précédemment ("CA Provya")
- Client Certificate : choisir le certificat client importé précédemment ("Certificat client OpenVPN Provya")
- DH Parameters Length : Nous laissons la valeur par défaut (1024 bits)
Exemple de résultat obtenu :
Nous validons en cliquant sur le bouton "Save".
Révocation de certificat
Le dernier élément, pour être complet sur la gestion des certificats, est la liste de révocation de certificats ou "Certificate Revocation Lists" (CRLs).
Cette liste de révocation contient les certificats qui ne doivent plus être considérés comme sûrs (car ils ont été compromis ou pour n'importe quelle autre raison).
Pour les connexions OpenVPN, la CRL peut être utilisée par le serveur pour vérifier les certificats utilisés par les clients OpenVPN.
Une CRL est signée par un CA. Ainsi, pour générer une CRL, il est nécessaire de disposer de la clé privée du CA.
Généralement, une seule CRL est maintenue par CA. Cependant, pfSense peut en maintenir davantage.
Néanmoins, une seule CRL pourra être sélectionnée par instance OpenVPN.
Ce fonctionnement permet, par exemple, d'empêcher un certificat de se connecter à une instance OpenVPN, mais de l'autoriser à se connecter à une autre instance.
Une CRL peut être soit créée, soit importée. La configuration se fait dans le menu System > Cert Manager depuis l'onglet "Certificate Revocation" (troisième onglet).
Pour ajouter une nouvelle CRL, nous cliquons sur le bouton "+ Add or import CRL" correspondant au CA qui signera cette CRL (dans notre cas, "CA Provya"). Les champs à renseigner sont les suivants :
- Method : deux méthodes sont possibles :
- Create an internal Certificate Revocation List : permet de créer une nouvelle CRL (nécessite de disposer de la clé privée du CA)
- Import an existing Certificate Revocation List : permet d'importer une CRL générée depuis un serveur tiers (disposant de la clé privée du CA)
- Descriptive name : le nom de notre CRL. On y inclut généralement une référence au nom du CA et/ou l'usage de cette CRL
- Certificate Authority : le CA qui a signé ou va signer cette CRL
- Lifetime : la durée de vie de la CRL (10 ans par défaut)
- Serial : le numéro de série de la CRL (0 par défaut pour la première)
Exemple de résultat obtenu :
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").
Voilà ! Notre serveur OpenVPN est prêt à fonctionner avec des certificats.
Pour aller plus loin
[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Monter un VPN natté (Overlap network) avec OpenVPN
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 : certificatsopenVPNpfSenseVPNX.509
English version: [pfSense] How network interfaces work
La gestion des interfaces réseaux sous pfSense peut être quelque peu déroutante pour un débutant. Nous présentons ici les rappels de base et les cas d'utilisation de chaque type d'interface.
Article mis à jour le : 03/09/2019
Il existe 3 types d'interfaces sous pfSense :
- interface physique : correspond aux interfaces physiques réelles du serveur sur lequel tourne pfSense. Ces interfaces sont généralement nommées re0, re1 (pour des interfaces Realtek), igb0, igb1 (pour des interfaces Intel Gbps), etc.
- interface virtuelle : ces interfaces sont automatiquement créées lors de la création d'un VLAN, d'un serveur OpenVPN, etc. Elles sont donc associées à un service.
- interface logique : ce sont les interfaces que nous pouvons configurer (attribution d'adresse IP, règle de filtrage du firewall, etc.). Ces interfaces sont associées à une interface physique ou virtuelle.
Les deux premiers types d'interfaces (interface physique et interface virtuelle) sont appelés "ports réseaux".
Une interface logique doit être associée à un port réseau.
Un port réseau (c'est-à-dire une interface physique ou virtuelle) ne peut être associé qu'à une seule interface logique (c'est-à-dire configurable).
Interfaces physiques
Une interface physique correspond à une carte réseau du serveur pfSense.
Ces interfaces sont nommées en fonction de leur driver. Par exemple : re0, re1, igb0, igb1, ath0, etc. Elles sont identifiées par leur adresse MAC.
Lors de l'installation de pfSense, il est proposé de configurer les interfaces. Ce sont des interfaces logiques. Elles sont créées, configurées et associées aux interfaces physiques.
Ainsi, dans le cas d'un pfSense disposant de deux interfaces (une interface LAN et une interface WAN), on pourrait avoir l'association suivante :
WAN [interface logique] = igb0 [port réseau]
LAN [interface logique] = igb1 [port réseau]
Il est également possible de retrouver cette association depuis le menu Interfaces > Assignments :
Interfaces virtuelles
Ces interfaces sont créées lors de l'activation de certains services (VLAN, OpenVPN).
La configuration d'un serveur OpenVPN entraîne automatiquement la création d'une interface virtuelle associée à cette instance serveur OpenVPN. L'interface virtuelle sera nommée ovpns1, ovpns2, etc...
Cette interface n'est pas configurable en l'état : ce n'est qu'un port réseau. Il est nécessaire de l'associer à une interface logique afin de pouvoir lui associer des règles de firewall ou de NAT spécifiques.
Lorsque nous procédons à cette association, nous obtenons l'exemple suivant :
Dans la capture d'écran ci-dessus, nous voyons que l'interface logique "OPT2" est associée à l'interface virtuelle "ovpns1" qui a été créée lors de la configuration du serveur OpenVPN "VPN Provya".
De la même façon, la création d'un VLAN entraîne la création d'une interface virtuelle (qui sera nommée VLAN1, VLAN2, etc.).
Cette interface virtuelle devra être associée à une interface logique afin de pouvoir lui associer des règles de firewall ou de NAT spécifiques.
Interfaces logiques
Les interfaces logiques sont les interfaces configurables. Ce sont ces interfaces que nous allons pouvoir configurer : associer une adresse IP ; activer un serveur DHCP ; configurer des règles de firewall ou de NAT ; etc.
Ainsi, lors de la configuration d'un service (DHCP, OpenVPN, Portail Captif, etc.) les interfaces proposées seront toujours les interfaces logiques.
Les interfaces logiques les plus connues sont LAN et WAN.
Une interface logique est obligatoirement associée à un port réseau (c'est-à-dire à une interface physique ou virtuelle).
Groupe d'interfaces
Un groupe d'interfaces rassemble plusieurs interfaces logiques.
Ce groupe est donc un groupe logique auquel on peut appliquer des règles de firewall ou de NAT.
L'utilisation d'un groupe d'interfaces est utile si l'on dispose de plusieurs interfaces logiques sur lesquelles nous souhaitons appliquer exactement les mêmes règles.
Ainsi, les règles de firewall définies pour ce groupe s'appliqueront à toutes les interfaces du groupe.
La création de groupe d'interfaces se fait dans le menu Interfaces > Assignments, puis l'onglet "Interface Groups" :
L'ajout se fait en cliquant sur le bouton "+ Add".
Nous renseignons le nom du groupe d'interfaces, une description (facultative) et la liste des interfaces faisant partie du groupe :
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.
D'une façon générale, les règles de vérification du firewall s'opèrent dans l'ordre suivant :
- Règles définies en Floating
- Règles définies sur les groupes d'interfaces
- Règles définies sur les interfaces logiques
Cas particulier : OpenVPN
Lors de la création d'une instance serveur ou client OpenVPN, hormis les interfaces virtuelles (ovpns1 ou ovpnc1), un groupe d'interfaces nommé "OpenVPN" est automatiquement créé.
Les configurations réalisées sur ce groupe "OpenVPN" s'appliquent à l'ensemble des services OpenVPN (c'est-à-dire tous les serveurs ou tous les clients OpenVPN configurés).
Si nous souhaitons une granularité de configuration par instance OpenVPN, alors nous devons créer une interface logique pour chaque interface virtuelle OpenVPN existante.
Cas d'application
Lors de la configuration d'un service (DHCP, OpenVPN, Portail Captif, etc.) les interfaces proposées seront toujours les interfaces logiques.
Pour les services dont la configuration peut se faire pour plusieurs interfaces (une règle de firewall, par exemple), il sera également proposé les groupes d'interfaces.
Il existe deux cas particuliers à noter : la configuration des clients ou serveurs OpenVPN et IPsec.
Pour ces services, le choix de l'interface sera :
- les interfaces logiques
- les groupes de gateway
- les adresses VIP
- l'interface localhost
- toutes les interfaces logiques existantes (choix "any")
Les groupes d'interfaces ne seront pas proposés.
Nous voila maintenant armés pour bien comprendre et configurer correctement les services sur les bonnes interfaces réseau !
Pour aller plus loin
Best practices / Recommandations pour la configuration de votre firewall
[pfSense] Bien choisir et dimensionner son firewall
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 : interfaces réseaux pfSensepfSense
English version: [pfSense] Configuring traffic shaping with CBQ
pfSense offre plusieurs mécanismes de priorisation de trafic. Après notre premier article présentant le mode de fonctionnement des trois principaux mécanismes de priorisation ([pfSense] Comprendre la priorisation de trafic), nous procédons dans cet article à sa mise en application à l'aide du protocole CBQ.
Article mis à jour le : 28/08/2019
Si nos besoins en règles de priorisation de trafic sont des besoins traditionnels, il est conseillé de travailler avec CBQ.
Nous ne détaillerons pas ici le mode de fonctionnement de CBQ, ni ses avantages ou inconvénients. Nous traiterons d'un cas pratique de mise en application sous pfSense et des bonnes pratiques à respecter.
Le mode de fonctionnement de CBQ est présenté dans notre article dédié : [pfSense] Comprendre la priorisation de trafic
Généralités sur la priorisation de trafic
Pour la mise en place de la priorisation de trafic, nous allons configurer d'un côté des queues (file d'attente) et de l'autre des rules (règles d'affectation des paquets dans ces files d'attente) :
- Queues : "file d'attente" à laquelle est associée une priorité de traitement et une bande passante
- Rules : "règle d'affectation" définissant la queue par laquelle un paquet va transiter. Ces règles sont les mêmes que pour la configuration du firewall : filtrage par port et adresse IP source, port et adresse IP de destination, protocole utilisé, etc.
La priorité de traitement la plus forte doit toujours être donnée aux applications nécessitant un traitement temps-réel. Typiquement, la VoIP.
La priorité suivante doit toujours être donnée aux acquittements TCP (ACK). Les ACK correspondent à des sortes d'accusé de réception sur les données transmises en TCP. Il est important que ces paquets soient prioritaires car autrement l'émetteur considérera que les paquets envoyés n'ont pas été correctement reçus et procédera à leur réémissions. Ce qui, par effet boule de neige, augmentera la charge sur la ligne Internet.
On considère que la bande passante nécessaire pour les ACK est de 10 à 15% du débit maximum offert en dowload (nous verrons en fin d'article comment affiner ce réglage).
Enfin, par convention de nommage, les queues commencent toujours par la lettre "q" (ex : qVoIP, qACK, qDefault, ...).
Pour le nommage des queues, et afin de facilité la lisibilité, nous recommandons l'utilisation du lowerCamelCase.
Cas d'application
Nous partirons du cas d'application suivant : une entreprise disposant d'une connexion Internet SDSL de 3Mbps sur laquelle transite sa téléphonie (VoIP) vers son opérateur SIP et le reste de sa data (surf, messagerie, etc.).
Le besoin est de prioriser sa téléphonie afin de garantir la qualité des communications et de disposer d'une répartition dynamique de sa bande passante.
Nous respecterons le principe KISS et mettrons en place les trois queues suivantes :
- qVoIP : ce sera la queue réservée à la téléphonie
- qACK : ce sera la queue réservée aux paquets ACK
- qDefaut : la queue par défaut par laquelle nous ferons passer le reste du trafic
Il est important de démarrer avec un nombre de queues réduit et sur des règles d'affectation simples. Puis, de procéder à du fine-tuning si nécessaire.
La queue qVoip disposera de la priorité la plus forte et d'une bande passante de 1Mbps (ce qui correspond environ à 10 appels simultanés avec le codec G.711)
La queue qACK disposera de la priorité suivante et d'une bande passante de 10% du débit max en download, soit 300Kbps.
Enfin, la queue qDefaut disposera d'une priorité assez faible (et du reste de la bande passante) permettant l'ajout ultérieur de queues avec des priorités intermédiaires en cas de besoin.
Configuration des queues
Nous commençons par la configuration des queues sur l'interface WAN.
Se rendre dans le menu Firewall > Traffic Shaper :
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
- Scheduler Type : choisir "CBQ"
- Bandwidth : indiquer le débit max en upload diminué de 10% (soit 2700Kbps)
- Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
- TBR Size : laisser vide
Cliquer sur le bouton "Save" pour valider la configuration.
Exemple de résultat obtenu :
À 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, "1000 Kbps"
- Scheduler specific options : cocher cette case afin d'activer le partage dynamique de bande-passante pour cette queue
Cliquer sur le bouton "Save" pour valider la configuration.
Exemple de résultat obtenu :
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 :
- qVoIP : pour le trafic à destination ou en provenance du fournisseur SIP
- qACK : pour le trafic ACK (acquittement TCP)
- qDefaut : pour le reste du trafic
Nous allons maintenant activer la priorisation de trafic sur l'interface LAN. Cliquer sur « LAN » :
Renseigner les champs comme suit :
- Enable/Disable : cocher la case pour activer la priorisation de trafic sur l'interface LAN
- Scheduler Type : choisir "CBQ"
- Bandwidth : indiquer le débit max en 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 :
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 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 du trafic dans ces queues.
La configuration s'effectue au niveau des règles du Firewall. Elle peut s'effectuer directement depuis les règles existantes, ou en créant des règles génériques sur l'interface "Floating".
Les règles de vérification du Firewall s'opèrent dans l'ordre suivant :
- Règles définies en Floating
- Règles définies sur les groupes d'interfaces
- Règles définies sur les interfaces logiques
Pour un rappel sur le mode de fonctionnement des interfaces réseaux ou groupe d'interfaces sous pfSense, se référer à l'article dédié [pfSense] Comprendre la gestion des interfaces réseaux.
Dans notre cas, nous ne toucherons pas aux règles de filtrage en place sur nos interfaces ou groupe d'interfaces, mais nous créerons des règles spécifiques d'affectation du trafic depuis l'interface "Floating".
C'est ce que nous recommandons de faire systématiquement. Ainsi, nous ne mélangeons pas la partie "filtrage firewall" de la partie "règles de priorisation de trafic".
Pour cela, se rendre dans le menu "Firewall" > "Rules", puis sur l'onglet "Floating" :
La méthode de création des règles de firewall depuis l'onglet "Floating" est exactement la même que pour n'importe quelle interface. La seule différence est la présence de l'action "Match".
L'action "Match" signifie qu'aucune décision ne sera prise quant à l'acceptation (Pass) ou au refus (Block ou Reject) du paquet, mais que s'il correspond (="match") aux critères définis (adresse IP source ou destination, port source ou destination, système d'exploitation, protocole, etc.), alors il se verra appliquer les options définies dans les "Advanced Options" (comme les queues d'affectation ou la gateway, par exemple).
Si nous reprenons notre exemple, nous devons créer les règles suivantes :
- Une première règle pour diriger le trafic en provenance de l'opérateur de VoIP vers la queue "qVoIP"
- Une seconde règle pour diriger le trafic à destination de l'opérateur de VoIP vers la queue "qVoIP"
- Une dernière règle pour diriger tous les paquets ACK du trafic TCP vers la queue "qACK"
Nous créons notre première règle en cliquant sur le bouton "Add" et renseignons les champs comme suit :
- Action : nous choisissons "Match"
- Interface : nous choisissons l'interface "WAN"
- Direction : nous choisissons "in" (c'est-à-dire arrivant sur l'interface WAN)
- Protocol : nous choisissons "UDP" (les protocoles de VoIP SIP et RTP utilisant UDP)
- Source : nous choisissons "Single host or alias" et renseignons l'adresse IP du serveur VoIP de l'opérateur
Exemple de résultat obtenu :
Puis, dans la section "Advanced Options", nous cliquons sur le bouton "Display Advanced" et localisons en bas de page la ligne "Ackqueue / Queue". La première liste déroulante correspond à la queue d'acquittement (paquets ACK), la seconde liste déroulante correspond à la queue en tant que telle.
On ne peut choisir une "Ackqueue" (première liste déroulante), que si on a choisi une queue (seconde liste déroulante).
Ici, nous choisissons la queue "qVoIP" et nous laissons l'Ackqueue à "none" (les protocoles de VoIP SIP et RTP utilisant UDP).
Exemple de résultat obtenu :
Enfin, nous cliquons sur "Save" pour valider la règle.
Voila notre première règle créée :
Nous créons une nouvelle règle en cliquant sur le bouton "Add".
Nous renseignons les champs comme suit :
- Action : nous choisissons "Match"
- Interface : nous choisissons l'interface "WAN"
- Direction : nous choisissons "out" (c'est-à-dire sortant par l'interface WAN)
- Protocol : nous choisissons "UDP"
- Destination : nous choisissons "Single host or alias" et renseignons l'adresse IP du serveur VoIP de l'opérateur
Dans la section "Advanced Options", nous cliquons sur le bouton "Display Advanced", puis localisasons la ligne "Ackqueue / Queue".
Nous laissons la première liste déroulante à "none", et choisissons "qVoIP" pour la seconde.
Exemple de résultat obtenu :
Nous cliquons sur "Save" pour valider la règle.
Nous créons enfin la dernière règle en cliquant sur le bouton "Add".
Nous renseignons les champs comme suit :
- Action : nous choisissons "Match"
- Interface : nous choisissons les interfaces "WAN" et LAN
- Protocol : nous choisissons "TCP"
Dans la section "Advanced features", nous cliquons sur le bouton "Advanced" se trouvant sur la ligne "Ackqueue/Queue".
Nous choisissons "qACK" dans première liste déroulante à "none", et choisissons "qDefaut" dans la seconde.
On clique sur "Save" pour valider la règle.
Exemple de résultat obtenu :
Nos trois règles d'affectation sont créées. Nous cliquons sur "Apply changes" pour valider la configuration.
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" :
À 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" :
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
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 : CBQpfSensepriorisation de traficQoS
English version: [pfSense] Upgrading pfSense (how-to)
Il est important de conserver une version de pfSense à jour sur ses firewall en production.
Nous présentons ici la procédure que nous utilisons lors de la mise à jour d'un pfSense standalone ou d'un cluster de pfSense.
Article mis à jour le : 20/08/2019
Avant de commencer, si votre système de fichiers est ZFS, pensez à créer un point de restauration avant de lancer la mise à jour.
1. Procédure de mise à niveau pour un pfSense seul
Dans le cas d'un serveur pfSense fonctionnant de manière autonome, la mise à jour va s'effectuer en 3 étapes :
- Sauvegarde de la configuration : permettra un retour-arrière rapide en cas de problème
- Mise à jour du serveur pfSense
- Sauvegarde de la configuration après la mise à jour : permet de bénéficier d'une sauvegarde à jour de la configuration en cas de panne ultérieure
Sauvegarde de la configuration
Se rendre dans le menu Diagnostics > Backup/Restore :
Dans le champ "Backup configuration" > "Backup area" choisir "ALL", laisser coché la case "Do not backup RRD data", et décoché les deux autres cases, puis cliquer sur "Download Configuration as XML" :
Mise à jour du serveur pfSense
Naviguer dans le menu System > Update :
Puis cliquer sur "Upgrade now" pour lancer la mise à jour.
Lors de la mise à jour, une coupure de service est à prévoir (redémarrage du serveur pfSense possible).
Sauvegarde de la configuration après la mise à jour
Refaire une sauvegarde en suivant la procédure décrite précédemment.
La mise à jour du serveur pfSense est terminée !
2. Procédure de mise à niveau d'un cluster de pfSense
Dans le cas de serveurs pfSense fonctionnant en redondance, la mise à jour va s'effectuer de la manière suivante :
- Faire une sauvegarde du pfSense secondaire
- Lancer la mise à jour du pfSense secondaire
- Une fois la mise à jour du pfSense secondaire complète, faire une sauvegarde du pfSense primaire
- Désactiver CARP sur le pfSense primaire => les adresses VIP vont basculer sur le pfSense secondaire
- Lancer la mise à jour du pfSense primaire
Sauvegarde de la configuration du pfSense secondaire
Se rendre dans le menu Diagnostics > Backup/Restore :
Dans le champ "Backup configuration" > "Backup area" choisir "ALL", cocher la case "Do not backup RRD data", décocher les deux autres cases, puis cliquer sur "Download Configuration" :
Mise à jour du serveur pfSense secondaire
Naviguer dans le menu System > Update :
Puis cliquer sur "Upgrade now" pour lancer la mise à jour.
Sauvegarde de la configuration du pfSense primaire
Une fois la mise à jour terminée sur le pfSense secondaire, effectuer une sauvegarde du pfSense primaire en suivant la procédure détaillée à l'étape précédente.
Désactivation CARP du pfSense primaire
Avant de mettre à jour le pfSense primaire, nous basculons les adresses VIP sur le pfSense secondaire afin de ne pas perturber le service.
Pour cela, se rendre dans dans Status > CARP (failover) :
Puis cliquer sur "Enter Persistent CARP Maintenance Mode" :
Les adresses VIP vont basculer sur le serveur pfSense secondaire.
Mise à jour du serveur pfSense primaire
Nous pouvons maintenant mettre à jour tranquillement le serveur primaire. La procédure est toujours la même que celle décrite aux étapes précédentes.
Une fois la mise à jour du serveur primaire terminée, la VIP ne va pas re-basculer d'elle-même sur le serveur pfSense primaire. Il faut la réactiver. Pour cela, nous nous rendons dans le menu Status > CARP (failover) et cliquons sur "Leave Persistent CARP Maintenance Mode" :
Il ne reste plus qu'à faire une sauvegarde du serveur pfSense primaire afin d'avoir une sauvegarde de la dernière configuration à jour.
La mise à jour du cluster de pfSense est terminée !
3. Vérifier et corriger la mise à jour des packages
Les packages peuvent parfois être une source de problème lors d'une mise à jour. Si des packages semblent ne plus fonctionner correctement après une mise à jour, il est recommandé de désinstaller le ou les packages concernés, puis de les réinstaller.
Pour aller plus loin
Best practices / Recommandations pour la configuration de votre firewall
[pfSense] Configurer un cluster de 2 pfSense redondants (failover)
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 : mise à jour pfSensepfSensepfSense redondantupgrade
Un cas fréquent lorsque l'on souhaite connecter deux sites en VPN est que ces deux sites soient sur le même plan d'adressage. Dans ce cas, une bonne solution peut être de recourir au NAT pour la mise en place d'un VPN natté.
Article mis à jour le : 13/08/2019
Par exemple, si l'on souhaite connecter deux sites utilisant le sous-réseau 192.168.1.0/24, ceux-ci ne pourront pas communiquer l'un vers l'autre à travers le VPN car le plan d'adressage du réseau distant est le même que celui du réseau local.
Afin d'y remédier, nous proposons d'utiliser le NAT pour communiquer d'un réseau à l'autre. C'est le principe du VPN natté (overlap network).
À noter : nous ne détaillons pas dans cet article comment configurer OpenVPN. Il existe déjà un article dédié sur le sujet : [pfSense] Monter un accès OpenVPN site-à-site.
Principe de fonctionnement
Pour chaque sous-réseau commun sur les sites distants, nous utiliserons un nouveau sous-réseau disponible associé à du 1:1 NAT.
Nous allons prendre l'exemple de deux sites (A et B) disposant tous deux du même plan d'adressage 192.168.1.0/24 :
Afin de pouvoir relier ces deux sites en VPN, nous allons translater l'intégralité du plan d'adressage réseau du site B afin qu'il soit joignable depuis le site A à travers le VPN. Et nous ferons de même du plan d'adressage réseau du site A afin qu'il soit joignable depuis le site B à travers le VPN.
Le trafic à destination du site A sera translaté en 192.168.100.0/24.
Le trafic à destination du site B sera lui translaté en 192.168.200.0/24.
Une entrée 1:1 NAT sera ajoutée pour chaque sous-réseau afin de translater l'intégralité du /24.
Ainsi, pour joindre le site A depuis le site B, on utilisera une adresse IP du type 192.168.100.x et pour joindre le site B depuis le site A, on utilisera une adresse IP du type 192.168.200.x.
Grâce au 1:1 NAT, on conservera le dernier octet de l'adresse réseau de chaque site. C'est-à-dire que pour joindre l'adresse IP 192.168.1.10 du site A, depuis le site B on utilisera l'adresse IP 192.168.100.10. Et pour joindre l'adresse IP 192.168.1.50 du site B, depuis le site A on utilisera l'adresse IP 192.1168.200.50.
Configuration du VPN natté
Sur le serveur pfSense du site A, nous nous rendons dans menu Firewall > NAT, puis sur l'onglet 1:1 :
Nous cliquons sur le bouton "Add". Les champs à configurer sont les suivants :
- Interface : l'interface de notre tunnel VPN OpenVPN
- External subnet IP : le sous-réseau utilisé pour le NAT. Soit, pour le site A : 192.168.100.0
- Internal IP : le sous-réseau local que nous souhaitons translater. Dans notre cas : LAN net
- Destination : Any
Exemple de résultat obtenu :
Nous procédons de la même manière sur le serveur pfSense du site B, en adaptant le champ "External IP" qui passe à 192.168.200.0 dans notre cas.
Exemple de résultat obtenu :
Enfin, dans la configuration du client et du serveur OpenVPN, le champ "IPv4 Remote network(s)" doit correspondre aux plages d'adresses IP nattées.
C'est-à-dire que sur le pfSense du site A, le champ "IPv4 Remote network(s)" est renseigné à "192.168.200.0/24". Sur le pfSense du site B, le champ "IPv4 Remote network(s)" est quant à lui renseigné à "192.168.100.0/24".
La configuration est terminée.
Pour davantage d'information sur la configuration OpenVPN sur pfSense, voir l'article dédié sur le sujet : [pfSense] Monter un accès OpenVPN site-à-site.
Le VPN natté est en place !
Pour aller plus loin
[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] La gestion des certificats pour les connexions OpenVPN
[pfSense] Monter un VPN IPsec natté (Overlap network)
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 : NATopenVPNpfSenseVPN
pfSense peut être utilisé comme serveur DHCP ou relai DHCP.
Nous allons configurer ici pfSense en tant que serveur DHCP pour des adresses IPv4.
Article mis à jour le : 06/08/2019
Activer le service DHCP
Pour commencer, se rendre dans le menu "Services" > "DHCP Server" :
On choisi l'interface sur laquelle nous souhaitons activer le serveur DHCP. Dans notre cas, ce sera "LAN".
Pour commencer, nous cochons évidemment la case "Enable DHCP server on LAN interface".
Configuration du serveur DHCP
Les éléments pouvant être configurés sont les suivants :
- BOOTP : cocher cette case permet de désactiver la prise en charge des requêtes BOOTP. Le protocole BOOTP est en quelque sorte l'ancêtre du protocole DHCP.
- Deny unknown clients : cette option permet de filtrer les requêtes DHCP.
Par défaut (option non-cochée), pfSense attribue une adresse IP à n'importe quel terminal connecté sur le réseau qui fait une demande d'adresse IP. C'est, à priori, le mode souhaité dans la plupart des cas. Cependant, il est possible, dans des environnements plus restrictifs, de n'autoriser la distribution d'adresses IP qu'aux terminaux connus (c'est-à-dire dont l'adresse MAC a été renseignée dans pfSense) ; dans ce cas, cette case doit être cochée. Il est à noter que cette option se défini par plage d'adresses.
- Ignore denied clients : cocher cette case permet d'ignorer les requêtes DHCP des clients interdits plutôt que de leur renvoyer une réponse explicite de refus. Cette option n'est pas compatible avec une configuration de pfSense en haute-disponibilité.
- Ignore client identifiers : permet d'ignorer l'UID du client. Cette option peut être intéressante si l'on souhaite qu'un ordinateur disposant d'un dual-boot conserve la même adresse IP lorsqu'il bascule d'un système d'exploitation à l'autre. Cependant, activer cette option revient à ne pas respecter les spécification officielles du fonctionnement du protocole DHCP.
- Subnet : cette ligne rappelle l'adresse du réseau.
- Subnet mask : cette ligne rappelle le masque de sous-réseau.
- Available range : cette ligne donne la plage maximale sur laquelle des adresses IP peuvent être attribuées. Cette information est bien pratique pour les réseaux n'étant pas en /24.
- Range : permet de définir la plage d'adresses IP qui sera utilisée.
Par défaut, pfSense propose la plage d'adresse allant de 100 à 199 (soit, par exemple, 192.168.1.100 à 192.168.1.199). Nous sommes libres de la modifier dans la limite de la taille maximale rappelée à la ligne précédente (available range).
Si nous souhaitons définir plusieurs plages d'adresses IP différentes (soit pour filtrer les terminaux connus des terminaux inconnus, soit pour d'autres raisons liées à notre architecture réseau), il est possible de définir plusieurs plages d'adresses IP (section Additional Pools juste en-dessous).
Pour ajouter une seconde plage d'adresses IP, cliquer sur le bouton "+ Add pool" de la section "Additional Pools". Cela aura pour effet d'ouvrir une nouvelle fenêtre permettant de définir l'ensemble des paramètres propres à cette plage d'adresses IP.
Évidemment, cette option n'est utile que si nous disposons d'un serveur WINS sur notre réseau. Les serveurs WINS n'ont pas forcément besoin d'être sur le même sous-réseau (dans ce cas, il faut veiller à bien configurer les règles de routage et de filtrage au niveau du firewall).
Dans le cas où nous n'utilisons pas de serveur WINS (ce qui doit être le cas de la quasi-totalité des réseaux modernes), nous laissons ces champs vides.
- DNS servers : ce champ peut être renseigné ou resté vide. Si l'on souhaite passer au client la même configuration DNS que celle configurée dans pfSense, alors il faut laisser ces champs vides. En revanche, si l'on souhaite passer au client d'autres serveurs DNS que ceux configurés dans pfSense, ou si l'on souhaite que ce soit pfSense qui agisse comme serveur DNS, il faut renseigner les adresse IP correspondantes ici.
Pour les réseaux locaux avec des terminaux Windows et un serveur Active Directory, il est conseillé d'indiquer l'adresse du serveur Active Directory.
- Gateway : si pfSense est la passerelle pour ce réseau, ce champ peut être laissé vide. Dans le cas contraire, nous indiquons ici l'adresse IP de la passerelle.
- Domain name : permet d'indiquer aux clients le nom de domaine correspondant au réseau et donc qu'ils devront utiliser pour former leur FQDN. Si rien n'est indiqué, c'est le nom de domaine renseigné dans la configuration gloable de pfSense qui sera passé aux clients.
- Domain search list : cette information est utile dans le cas où l'on dispose de plusieurs domaines.
Lors d'une recherche sur un nom d'hôte sur le réseau, le client concaténera le nom d'hôte au nom de domaine. Chaque domaine doit être séparé par un point-virgule. Cette information est passée au client via l'option DHCP 19. Donc, dans le cas où il n'y a qu'un seul domaine local, ce champ doit être laissé vide (lorsque qu'un client fera une recherche sur un nom d'hôte, la concaténation se fera avec le nom de domaine défini à la ligne précédente).
- Default lease time et Maximum lease time : ces deux options permettent de contrôler la durée des baux DHCP.
Default lease time est utilisée quand un client ne demande pas de durée spécifique d'enregistrement pour son bail. Si le client demande une durée de bail qui est supérieure à Maximum lease time, la durée de bail donnée sera celle définie dans Maximum lease time. Ces valeurs sont définies en secondes.
Si les champs sont laissés vides, les valeurs par défaut sont de 7.200 secondes (2h) pour la durée de bail par défaut et 86.400 secondes (1 jour) pour la durée de bail max.
- Failover peer IP : si vous possédez deux serveurs pfSense configurés en failover, renseignez ici l'adresse IP physique (pas l'adresse virtuelle) du second serveur pfSense. Autrement, laissez ce champ vide.
- Static ARP : cette option est l'exact opposé de "Deny unknow clients" : elle permet de lister les machines capables de communiquer avec pfSense sur le réseau. Ainsi, tous les terminaux n'étant pas référencés (c'est-à-dire dont l'adresse MAC est connue et référencée dans pfSense) ne pourront pas communiquer avec pfSense. Il faut faire très attention lorsque l'on manipule cette option ! De plus, lorsqu'elle est cochée, cette option reste active même si le service DHCP est arrêté.
- Time format change : par défaut, les durées de baux DHCP sont affichées au format UTC. En cochant cette option, elles sont formatées au fuseau horaire local. C'est une option d'affichage purement esthétique.
- Statistics graphs : cocher cette option permet d'activer les graphiques RRD. Cette option est désactivée par défaut.
- Dynamic DNS : cette option permet de définir un serveur DNS dynamique (à saisir dans le champ correspondant). Dans le cas où pfSense est configuré en mode "DNS forwarder", cette option ne devrait pas être cochée, et le DNS forwarder devrait être configuré en conséquence.
- MAC Address Control : cette option permet de filtrer les accès au serveur DHCP par adresses MAC.
Le premier champ permet de définir les adresses MAC autorisées. Le second champ, les adresses MAC interdites. Ces adresses MAC peuvent être saisies partiellement (par exemple, saisir 01:E5:FF autorisera ou interdira, suivant le champ dans lequel elle aura été saisie, toutes les adresses MAC commençant par cette séquence).
Les adresses MAC (ou adresses MAC partielles) doivent être séparées par une virgule, sans espace. Ces champs peuvent être laissés vides si l'on ne souhaite pas appliquer de contrôle sur les adresses MAC des terminaux.
Il est important de comprendre qu'à partir du moment où une adresse MAC (ou adresse MAC partielle) est saisie dans le champ des adresses autorisées, toutes les autres adresses MAC seront interdites d'accès ; et inversement, si l'on saisi une ou des adresses MAC dans le champ des adresses interdites, toutes les autres adresses MAC seront autorisées.
Un exemple d'utilisation de cette fonctionnalité est la séparation des téléphones IP et des ordinateurs sur un même réseau sans utilisation de VLAN. En admettant que tous les téléphones IP disposent d'une adresses MAC commençant par aa:bb:cc, alors sur la plage d'adresses réservées aux ordinateurs, nous interdirons les adresses MAC commençant par aa:bb:cc (en saisissant cette séquence dans le champ des adresses interdites) ; et sur la plage d'adresse réservées à la VoIP, nous autoriserons uniquement les adresses MAC commençant par aa:bb:cc (en saisissant cette séquence dans le champ des adresses autorisées).
- TFTP server : permet de saisir l'adresse IP ou le nom d'hôte d'un serveur TFTP. Cette option est principalement utilisée pour l'auto-provisioning pour la téléphonie sur IP. Elle correspond à l'option DHCP 66.
- LDAP : permet d'envoyer l'URI d'un serveur LDAP aux clients en faisant la demande. Cela correspond à l'option DHCP 95. Le format saisi doit être celui d'une URI LDAP tel que ldap://ldap.example.com/dc=example,dc=com.
- Network booting : pour activer cette fonctionnalité, il faut cocher la case correspondante (Enables network booting), saisir l'adresse IP du serveur ainsi que le nom du fichier d'image disque bootable. L'ensemble de ces champs doit être complété pour que cette option fonctionne correctement.
- Additional BOOTP/DHCP Options : permet de pousser n'importe quelle option DHCP (dont nous détaillons le paramétrage au paragraphe suivant).
Une fois l'ensemble des configurations effectué, il ne reste plus qu'à cliquer sur Save !
Les options avancées du serveurs DHCP
L'une des grandes forces du serveur DHCP de pfSense est qu'il offre une interface de configuration simple pour la plupart des fonctionnalités DHCP. De plus, il permet également de délivrer l'intégralité des options DHCP. La liste des options DHCP possibles est disponible sur le site de l'IANA.
Plusieurs formats sont disponibles pour ces options DHCP. Les noms de ces formats pouvant être peu intuitifs, nous les détaillons ici :
Text : texte libre de forme.
String : une suite de chiffres hexadécimaux séparés par le caractère deux-points ":" (ex : 00:a8:c9)
Boolean : la valeur true ou la valeur false
Unsigned 8, 16, or 32-bit Integer : un nombre entier positif (supérieur à zéro), jusqu'à 86400
Signed 8, 16, or 32-bit Integer : un nombre entier positif ou négatif, jusqu'à -512
IP address or host : une adresse IP (ex : 192.168.1.2) ou un nom d'hôte (ex : www.example.com)
Exemple de configuration avancée : serveur DHCP pour ordinateurs et téléphones IP
Nous prendrons l'exemple d'une configuration où les postes téléphoniques et les ordinateurs se trouvent sur le même réseau (sans séparation par VLAN). Nous souhaitons regrouper les adresses IP des postes téléphoniques et celles des ordinateurs.
Dans notre exemple, nous utiliserons le plan d'adressage suivant : 192.168.2.0/24 ; le serveur pfSense dispose de l'adresse IP 192.168.2.1 ; le serveur de téléphonie de l'adresse IP 192.168.2.2.
Sur ce réseau, nous avons une vingtaine de postes informatiques et autant de postes téléphoniques.
Dans notre exemple, les téléphones IP ont tous une adresse MAC commençant par la séquences AA:BB:CC.
Nous souhaitons attribuer des adresses IP de 192.168.2.10 à 192.168.2.99 aux téléphones IP ; et des adresses IP de 192.168.2.100 à 192.168.2.199 aux autres terminaux (ordinateurs, imprimantes, etc.).
Le schéma de notre réseau est donc le suivant :
Nous configurons pfSense avec une première plage (champ Range) allant de 192.168.2.10 à 192.168.2.99 pour laquelle nous autorisons uniquement les adresses MAC (premier champ de l'option MAC Address Control) commençant par AA:BB:CC :
Nous ajoutons ensuite une seconde plage (bouton "+ Add" de la section "Additional Pools") allant de 192.168.2.100 à 192.168.2.199 pour laquelle nous interdisons les adresses MAC (second champ de l'option MAC Address Control) commençant par AA:BB:CC :
Notre configuration est terminée :
Dernière étape : si un serveur d'auto-provisioning des téléphones IP est présent sur le réseau, on pourrait ajouter ce paramètre au serveur DHCP.
Pour aller plus loin
[pfSense] Configurer ses VLAN
Best practices / Recommandations pour la configuration de votre firewall
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : auto-provisioningDHCPpfSense
16/10/2019 - 4 commentaires
