Provya

Sécurité et téléphonie

Sommaire des articles  -  Liens & Actualités  -  Firewall pour pfSense

pfSense 2.5.0 et pfSense Plus 21.02 sont disponibles !

icon 18/02/2021 - Aucun commentaire

English version: pfSense 2.5.0 and pfSense Plus 21.02 now available

Mercredi 17 février 2021 est sortie la dernière version de pfSense. La version 2.5.0. Ainsi que la première version de pfSense Plus : la version 21.02.

Il s'agit d'une mise à jour importante en terme de fonctionnalités, de correctifs de sécurité et de stabilité.

Dans cet article, nous faisons le tour des éléments marquants de cette mise à jour.



Nouveautés

Les nouveautés principales sont les suivantes :

  • mise à jour de l'OS vers FreeBSD 12.2 (qui est la dernière version stable de FreeBSD) ;
  • implémentation de Wireguard, qui est une solution VPN open-source qui se veut être très simple à mettre en œuvre et très performante ;
  • suppression de la fonctionnalité "Load Balancer" intégrée à pfSense : il est recommandé de se tourner vers le package HAProxy ;
  • Ajout de l'authentification Radius pour les utilisateurs SSH ;
  • Amélioration de la gestion des sauvegardes (davantage d'options sont disponibles, notamment pour sauvegarder les baux DHCP, ou les adresses MAC utilisées sur le portail captif, ...)
  • mise à jour d'OpenSSL vers la version 1.1.1 ;
  • mise à jour d'OpenVPN vers la version 2.5.0 ;
  • mise à jour de PHP (7.4) et de Python (3.7)



Bugs / Améliorations

Plusieurs bugs ont été corrigés et des améliorations apportées :

  • Alias : correction de plusieurs bugs (notamment pour les alias mélangeant des adresses IPv4 et IPv6).
  • LDAP / Radius : correction de plusieurs bugs pour l'authentification LDAP / Radius.
  • Portail captif : correction de plusieurs bugs mineurs sur la gestion de l'authentification.
  • Certificats : amélioration sur la gestion, la création et le renouvellement des certificats.
  • Service DHCP : ajout de fonctionnalités diverses (suppression de tous les baux en un clic, ajout d'options DHCP pour les entrées statiques, ...).
  • Passerelle : amélioration de la gestion des passerelles par défaut : il est maintenant possible d'obtenir une passerelle par DHCP qui soit en dehors du sous-réseau de l'interface ; et corrections de quelques bugs mineurs liés à IPv6.
  • IPsec : pas mal d'améliorations cosmétiques ou techniques : plusieurs petits bugs ont été corrigés et la gestion des VPN IPsec gagne en lisibilité.
  • Notifications : évolution de la gestion des notifications : les notifications via Growl ont été supprimées ; ajout de la possibilité d'envoi de notifications via Telegram.
  • OpenVPN : il n'est plus possible de désactiver la négociation des paramètres de sécurité (NCP - Negotiable Cryptographic Parameters) ; et dorénavant par défaut, lorsqu'un client envoie des paquets compressés, pfSense les décompresse, mais les réponses ne seront pas compressées (la compression sous OpenVPN est dépréciée depuis très longtemps pour des raisons de sécurité et de performance).



Processus de mise à jour

Cette nouvelle version est disponible pour les mises à jour et en téléchargement pour les nouvelles installations.

Si aucune mise à jour ne vous est proposée, il peut être utile de rafraîchir les dépôts de votre pfSense à l'aide des commandes suivantes (en saisir en console ou depuis un shell) :

pkg-static clean -ay; pkg-static install -fy pkg pfSense-repo pfSense-upgrade

Pensez à faire une sauvegarde avant de lancer la mise à jour, et suivez notre tuto complet : [pfSense] Mettre à jour son serveur pfSense.

Enfin, vous pouvez consulter la liste complète des changements en visitant la page suivante : 21.02/2.5.0 New Features and Changes [EN]



Pour aller plus loin

[pfSense] Mettre à jour son serveur pfSense
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 du matériel de qualité ? Alors contactez-nous.

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


           

store.provya.fr

icon Tags de l'article :

Avec pfSense Plus, l'avenir de pfSense ne sera pas (que) open-source

icon 09/02/2021 - 2 commentaires

Netgate, l'éditeur du logiciel pfSense a annoncé en janvier 2021 de grands changements dans le cycle de développement du logiciel pfSense avec l'arrivée d'un nouveau logiciel : "pfSense Plus".

pfSense Plus sera une version propriétaire et plus évoluée de pfSense.

Dans cet article nous faisons le point sur cette annonce et ses conséquences.

Logo pfSense Plus




pfSense, pfSense CE, pfSense FE, etc : commençons par quelques précisions liminaires

Il nous paraît important de commencer par bien préciser les termes que nous employons.

pfSense est une marque déposée par la société Netgate. Cette marque est déposée et protégée internationalement.

Autour de cette marque, deux logiciels sont proposés :

pfSense Community Edition (également appelé pfSense CE) qui désigne le logiciel open-source pfSense en tant que tel. Aussi, lorsque nous parlons de "pfSense" pour désigner le logiciel, ceci est un abus de langage : pour être très précis, nous devrions parler de "pfSense CE".
Cet abus de langage est communément répandu pour deux raisons : à l'origine, le terme pfSense désignait le logiciel et la marque (jusqu'au rachat par Netgate en 2014) ; et l'éditeur communique très majoritaire sur le terme "pfSense software" pour parler du logiciel pfSense CE.

pfSense Factory Edition (également appelé pfSense FE) qui désigne un logiciel propriétaire que l'on retrouve sur les firewall commercialisés par Netgate et chez des fournisseurs de solutions de cloud (Cloud Service Provider - CSP) comme AWS ou Azure.

Aussi, il faut bien avoir en tête que lorsque vous achetez des firewall Netgate ou que vous installez pfSense via le marketplace d'AWS ou d'Azure, vous n'utilisez en aucun cas un logiciel open-source : vous utilisez le logiciel propriétaire pfSense FE.



pfSense CE et pfSense FE : quelles différences ?

Les principales caractéristiques de pfSense FE, par rapport à pfSense CE, sont les suivantes :

  • pfSense FE n'est pas open-source ;
  • pfSense FE supporte les firewall Netgate qui tourne sur des architectures ARM ;
  • pfSense FE est proposée sur les marketplace d'AWS et d'Azure ;
  • pfSense FE propose des options de configurations spécifiques aux ports switch des firewall Netgate (la plupart des firewall Netgate ne dispose pas de ports réseaux indépendants, mais de ports switch : cela leur permet d'offrir une plus grande densité de ports réseaux pour un coût plus faible, mais au prix d'une performance plus limitée).

Les autres fonctionnalités que l'on trouve sous pfSense CE ou pfSense FE sont exactement les mêmes. Ce sont donc des logiciels très proches.



pfSense Plus, qu'est-ce que c'est ?

En février 2021, le logiciel propriétaire pfSense Factory Edition sera renommé pfSense Plus.

À partir de cette date, les logiciel pfSense CE et pfSense Plus vont diverger.

Netgate va procéder à une ré-écriture d'une grande partie du code-source de pfSense Plus afin de le rendre plus lisible, plus sécurisé et plus facilement maintenable.
Il s'agit là d'un des reproches majeurs formulés à l'encore de pfSense : un code-source à la qualité inégale et pas suffisamment structuré.

Ensuite, pfSense Plus incorporera rapidement de nouvelles fonctionnalités très demandées, comme par exemple :

  • Une refonte complète de l'interface graphique (plus sécurisée)
  • Un tableau de bord plus moderne et efficace
  • Des outils de statistiques et de reporting avancés
  • La prise en charge des normes sans-fil 802.11ac (Wi-Fi 5) et 802.11ax (Wi-Fi 6)
  • Le support du mode Zero Touch Provisioning pour des déploiements facilités

La roadmap détaillée de développement sera précisée prochainement par Netgate.

Autre élément important, pfSense Plus sera publié selon un rythme beaucoup plus régulier que pfSense CE. Il y a aura 3 versions majeures par an : janvier, mai et septembre.

C'est également là un des reproches formulés à l'encore de pfSense : un rythme de mise à jour trop irrégulier et ne respectant pas les cycles de versions de FreeBSD.
Par exemple, la dernière version stable de pfSense à ce jour est la version 2.4.5-RELEASE-p1 qui repose sur FreeBSD 11.3. Or, FreeBSD 11.3 est arrivé en fin de vie le 30/09/2020 et n'est donc plus maintenu depuis plusieurs mois déjà !

Le nommage des versions de pfSense Plus se fera selon le format AA.MM (année sur deux chiffres, mois sur deux chiffres). La première version de pfSense Plus, qui devrait sortir en février 2021, sera donc la version 21.02.

Dernier élément important : pfSense Plus sera dans un premier temps proposé uniquement pour les firewall Netgate, puis sur les instances de cloud partenaire, et enfin (d'ici la fin de l'année 2021) pour tous, installable sur tous matériels.



Quel sera le prix de pfSense Plus ?

Ces informations n'ont pas encore été communiquées par Netgate.

Ce que l'on sait pour le moment, c'est que l'utilisation de pfSense Plus pour un usage non-commercial (usage personnel, labo de tests, etc.) sera gratuite.

Pour les usages commerciaux, la grille de prix n'a pas encore été communiquée. Elle le sera dans le courant du mois de juin 2021.

À titre de comparaison, les tarifs de tnsr (logiciel propriétaire de Netgate pour des réseaux de + 40 Gbps) démarrent à 400 dollars / an. On peut donc, a priori, s'attendre à un tarif similaire ou inférieur pour pfSense Plus.



pfSense Plus marque-t-il la fin de pfSense CE ?

Le message délivré par Netgate est très clair : la priorité de développement est donnée à pfSense Plus. La plupart des améliorations qui seront apportées à pfSense Plus ne seront pas directement reversées à pfSense.

Cependant, les développements concernant des éléments communs aux deux versions de pfSense seront bien évidemment reversés vers pfSense CE ; comme par exemple les contributions à FreeBSD ou à packet filter.
Il faut garder en tête que Netgate est, depuis des années, et restera, un gros contributeur à de nombreux projets open-source.

pfSense CE continuera à être maintenu.
Le rythme de développement continuera comme aujourd'hui : c'est-à-dire qu'une nouvelle version sortira quand elle sera prête !

Beaucoup de monde avait déjà constaté que le rythme de développement de pfSense CE avait énormément ralenti. Il faut visiblement s'attendre à ce qu'il soit peut-être encore plus faible.

Ainsi, les corrections de bugs, les mises à jour de sécurité ou les améliorations apportées aux briques open-source utilisées dans pfSense CE continueront à être proposées. En revanche, il ne faut pas s'attendre à l'ajout de nouvelles fonctionnalités importantes. Ces nouvelles fonctionnalités seront réservées prioritairement (voire quasi-uniquement ?) à pfSense Plus.

Vraisemblablement, pfSense CE va continuer à être maintenu mais ne va plus vraiment évoluer.



pfSense Plus, bonne ou mauvaise nouvelle ?

Les deux !

C'est une bonne nouvelle car :
Ces annonces permettent de clarifier la stratégie de développement de Netgate concernant pfSense.
Tout le monde avait constaté un ralentissement du rythme de développement et des mises à jour. Il était donc nécessaire de clarifier le projet industriel porté par Netgate. C'est chose faite.

Netgate annonce un rythme de développement soutenu de pfSense Plus, la refonte d'une partie du code source (qui en a bien besoin...) et l'ajout de nouvelles fonctionnalités très attendues.
Si les tarifs annuels proposés sont raisonnables et que le côté "logiciel propriétaire" n'est pas un point de blocage pour vous, alors pfSense Plus être une très bonne solution.

Enfin, cette solution reste gratuite d'utilisation pour un usage non-commercial.

Mais c'est également une mauvaise nouvelle car :
Les annonces faites sont très claires : le développement sera prioritairement (quasi-exclusivement ?) sur pfSense Plus. Il n'y aura aucun rythme de développement nouveau pour pfSense CE.

Aucune nouvelle fonctionnalité n'est annoncée pour pfSense CE, hormis les corrections de bugs, mises à jour de sécurité et les mises à jour des briques open-source utilisées dans pfSense CE.

Il ne faut pas se voiler la face : ces annonces augure très visiblement la fin à petit feu de la version open-source de pfSense.



Que faire ? Quelles solutions envisagées ?

Notre première réponse est surtout de ne pas se précipiter !

pfSense CE 2.5.0 va sortir très prochainement (en février 2021). Il s'agit d'une version majeure qui apportera son lot de nouveautés. Wireguard sera notamment intégré à pfSense 2.5.0.

Il n'y a donc pas d'urgence à migrer. pfSense reste un bon logiciel, robuste, stable et sécurisé. Au cours des prochaines années il continuera d'être maintenu, mais évoluera très peu.

Nous attendons de voir l'offre tarifaire associée à pfSense Plus. Nous ne rejetons pas, a priori, cette solution. Les fonctionnalités et le rythme de développement annoncés pour pfSense Plus attirent notre curiosité.
Nous attendons les annonces complémentaires de Netgate sur le sujet.

Il est à noter que Netgate annonce que la compatibilité de migration de pfSense CE vers pfSense Plus sera maintenue. Il sera ainsi possible de migrer facilement de pfSense CE vers pfSense Plus à l'avenir.

Enfin, il est possible de se tourner vers OPNsense qui est un fork de pfSense né fin 2014, début 2015.
OPNsense bénéficie d'un code-source qui a été en très grande partie réécrit (+ 90 %), sécurisé, épuré et simplifié. L'interface graphique d'OPNsense est moderne et vraiment bien pensée.

OPNsense bénéficie d'un rythme de mise à jour important et régulier : deux mises à jour majeures par an, ainsi que des mises à jour additionnelles mineures dès que nécessaire.

Au cours de ses premières années, OPNsense souffrait de bugs trop nombreux pour en faire un bon firewall utilisable en production. Depuis, le logiciel a grandement gagné en maturité et en stabilité. Il s'agit donc sûrement de la solution idéale vers laquelle se tourner à l'avenir.

Nous sommes curieux de savoir si nous allons assister à une migration massive des utilisateurs de pfSense vers OPNsense ?

Wait & see.


Vous pouvez retrouver toutes les informations détaillées concernant pfSense Plus sur le blog de Netgate (en anglais) :




Et vous, que pensez-vous des annonces liées à la sortie de pfSense Plus ?



Pour aller plus loin

Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez du matériel de qualité ? Alors contactez-nous.

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


           

store.provya.fr

icon Tags de l'article :

[pfSense] Sauvegarder automatiquement sa configuration avec AutoConfigBackup

icon 26/01/2021 - Aucun commentaire

English version: [pfSense] Making automatic backups with AutoConfigBackup

Cet article est le premier d'une série présentant des solutions pour sauvegarder automatiquement la configuration de son pfSense.

Dans cet article nous nous appuyons sur le service AutoConfigBackup directement intégré à pfSense.



Principe de fonctionnement

AutoConfigBackup (ACB) est un service directement intégré de base à pfSense. Aucun package supplémentaire n'est nécessaire pour l'utiliser.

Lorsqu'il est activé, dès qu'un changement est fait sur le firewall, ou à intervalle régulier, AutoConfigBackup extrait la configuration du firewall, la chiffre à l'aide d'une phrase secrète (passphrase), puis l'envoie via HTTPS vers les serveurs de sauvegarde de Netgate (l'éditeur du logiciel pfSense).

Il est également possible de forcer une sauvegarde manuelle via AutoConfigBackup.

Les cent dernières sauvegardes sont conservées sur les serveurs de Netgate. Il est donc possible de revenir jusqu'à cent sauvegardes en arrière.



Principe de sécurité

Afin de garantir la confidentialité des données sauvegardées, le firewall les chiffre à l'aide de l'algorithme AES-256-CBC et d'une phrase secrète, puis envoie les données chiffrées vers les serveurs de Netgate.
Ainsi, les données envoyées et stockées sur les serveurs Netgate sont indéchiffrables sans cette phrase secrète.

Cette phrase secrète est personnalisable et conservée exclusivement en local sur le firewall. Elle n'est jamais directement transmise aux serveurs Netgate.

Il est important de faire une sauvegarde manuelle de cette phrase secrète car elle sera nécessaire en cas de restauration. Si cette phrase secrète est perdue, il n'y a aucune possibilité de la retrouver. Il ne sera donc pas possible de restaurer les données sauvegardées via AutoConfigBackup.

Enfin, pour identifier de manière unique un firewall, AutoConfigBackup utilise un hash SHA256 de la clé publique SSH du firewall.

Cet identifiant unique doit également être conservé. En cas de perte de cet identifiant, il ne sera pas possible de restaurer les données sauvegardées via AutoConfigBackup.

Il y a donc deux éléments que nous devons conserver précieusement :

  • la phrase secrète
  • l'identifiant unique

Passons à la configuration du service AutoConfigBackup.



Configuration du service AutoConfigBackup

Pour démarrer la configuration, nous nous rendons dans le menu Services > Auto Config Backup, onglet Settings

Menu Services > Auto Config Backup - pfSense - Provya


Les éléments à configurer sont les suivants :

  • Enable ACB : cocher cette case pour activer le service AutoConfigBackup.
  • Backup Frequency : 2 choix sont possibles - sauvegarder la configuration à chaque changement (Automatically backup on every configuration change) ou sauvegarder la configuration à intervalle régulier (Automatically backup on a regular schedule).
  • Schedule : si nous choisissons de faire une sauvegarde à intervalle régulier, il faut préciser les heures et jours de sauvegarde. Le format à utiliser est le format cron.
  • Encryption Password : notre phrase secrète. Les données sauvegardées étant envoyées sur des serveurs tiers, il est important que cette phrase secrète soit suffisamment robuste. Si cette phrase secrète est perdue, il n'y a aucune possibilité de restaurer les données sauvegardées.
  • Hint/Identifier : il est possible de préciser un identifiant qui sera transmis en clair avec les sauvegardes et qui pourra être utilisé par le support Netgate dans le cas où nous aurions perdu l'identifiant unique du firewall. Ce champ est utile uniquement si vous avez souscrit un contrat de support auprès de Netgate. Attention cependant, Netgate prévient officiellement qu'ils ne garantissent pas qu'ils puissent récupérer les sauvegardes via ce paramètre.
  • Manual backups to keep : le nombre de sauvegarde manuelle à conserver. Sur les cent sauvegardes conservées, il est possible de réserver jusqu'à cinquante places pour les sauvegardes manuelles. Nous proposons le nombre 10, qui nous semble être un bon compromis.

Exemple de résultat obtenu pour une sauvegarde automatique à chaque changement de configuration :

Exemple configuration AutoConfigBackup à chaque changement - pfSense - Provya


Exemple de résultat obtenu pour une sauvegarde automatique à intervalle régulier :

Exemple configuration AutoConfigBackup à intervalle régulier - pfSense - Provya

Les sauvegardes sont réalisées tous les samedi à 23h30


Il reste, bien-sûr, à cliquer sur le bouton "Save" afin de sauvegarder notre configuration.

Le service AutoConfigBackup est configuré !

Pour s'assurer que le service fonctionne bien, il nous reste à faire une modification sur la configuration de notre firewall (comme modifier une règle de filtrage, par exemple), puis se rendre dans le menu Services > Auto Config Backup, onglet Restore pour visualiser les sauvegardes automatiques réalisées :

Voir les sauvegardes automatiques - pfSense - Provya


Dans le cas où nous avons choisi de faire une sauvegarde à intervalle régulier, plutôt qu'à chaque changement, il faut attendre que la sauvegarde planifiée ait lieu.


Faire une sauvegarde manuelle

Une sauvegarde manuelle peut être réalisée à n'importe quel moment. Par exemple, avant et après une mise à jour ou des modifications importantes.

Pour lancer une sauvegarde manuelle, il suffit de se rendre dans le menu Services > Auto Config Backup, onglet Backup Now :

Menu Sevices > Auto Config Backup - Backup Now - pfSense - Provya


Il faut saisir les informations liées à la modification afin de pouvoir la retrouver plus facilement, puis cliquer sur le bouton "Backup".

Exemple d'une sauvegarder manuelle via Auto Config Backup - pfSense - Provya




Restauration des sauvegardes

La restauration d'une sauvegarde se fait depuis le menu Services > Auto Config Backup, onglet Restore :

Liste des sauvegardes réalisées avec Auto Config Backup - pfSense - Provya


Il est possible de personnaliser le champ "Device key" afin de restaurer la configuration provenant d'un autre firewall ; la phrase secrète sera également nécessaire.

Pour chaque sauvegarde, il est possible de réaliser 3 actions :

  • Restaurer : Restore this revision - permet de restaurer la sauvegarde choisie - il est conseillé de redémarrer le firewall après avoir lancé la restauration
  • Visualiser : Show info - permet de visualiser le fichier de configuration au format xml
  • Supprimer : Delete config - permet de supprimer une sauvegarde donnée


Voilà, votre firewall est sauvegardé régulièrement et vous savez comment procéder à une restauration depuis une sauvegarde réalisée par AutoConfigBackup.



Limites du service AutoConfigBackup

Le service AutoConfigBackup est très pratique car directement intégré à pfSense et configurable en quelques clics. Il permet d'avoir des sauvegardes régulières et de faire face sereinement en cas de nécessité de retour-arrière ou en cas de défaillance du firewall.
Il s'agit d'une solution efficace et vraiment très simple à mettre en œuvre.

Cependant, en utilisant ce service, les sauvegardes sont envoyées sur les serveurs d'une entreprise tiers, située aux États-Unis et par conséquent soumis au droit américain. De plus, vous devez avoir pleine confiance dans la disponibilité et la fiabilité des serveurs Netgate : en cas de panne chez eux, vous risquez de perdre en partie, voire en totalité, vos sauvegardes.

Pour ces raisons, nous ne conseillons pas forcément d'utiliser ce service. En tout état de cause, si vous décidez d'utiliser AutoConfigBackup, nous vous recommandons de le coupler, a minima, avec des sauvegardes manuelles régulières.

Dans un prochain article, nous présenterons une solution pour sauvegarder soi-même, en toute autonomie et de manière automatisée, la configuration de son pfSense.



Pour aller plus loin

[pfSense] Mettre à jour son serveur pfSense
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez du matériel de qualité ? Alors contactez-nous.

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


           

store.provya.fr

icon Tags de l'article :

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

icon 27/10/2020 - Aucun commentaire

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

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 un VPN IPsec site-à-site. Il existe déjà un article dédié sur le sujet : [pfSense] Configurer un VPN IPsec site à site.



Principe de fonctionnement

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

schéma réseau pfSense - VPN IPsec NAT - Provya


Afin de pouvoir relier ces deux sites en VPN, nous avons deux possibilités :

  • translater l'intégralité du plan d'adressage réseau du site A afin qu'il soit joignable depuis le site B à travers le VPN IPsec. Et inversement, nous ferons de même du plan d'adressage réseau du site B afin qu'il soit joignable depuis le site A à travers le VPN IPsec.
  • translater l'intégralité du trafic sur une seule adresse IP. C'est un peu ce principe qui est utilisé lors de la navigation sur Internet : toutes les adresses IP privées du réseau local sont nattées sur l'adresse IP publique de la connexion Internet.

Le choix du type de NAT dépend du contexte et des attendus.

Si l'on souhaite accéder à plusieurs équipements et que le plan d'adressage disponible le permet, le mieux est de réaliser un NAT un-pour-un (1:1 NAT) - c'est-à-dire la première solution évoquée ci-dessus.
Dans le cas contraire, un NAT simple sur une seule adresse IP suffira.

Dans notre exemple, nous allons faire en sorte que :

  • depuis le site A : le réseau local du site B sera joignable via le sous-réseau 192.168.200.0/24 ; ainsi, depuis le site A, pour joindre le serveur 192.168.1.222 (présent sur le site B), on attaquera l'adresse IP 192.168.200.222.
  • depuis le site B : le réseau local du site A sera joignable via le sous-réseau 192.168.100.0/24 ; ainsi, depuis le site B, pour joindre le serveur 192.168.1.111 (présent sur le site A), on attaquera l'adresse IP 192.168.100.111.



Configuration du VPN natté

Sur le serveur pfSense du site A, nous nous rendons dans le menu VPN > IPsec :

Menu VPN > IPsec - pfSense - Provya


Nous ne détaillons pas la configuration de la phase 1; cette partie est traitée dans notre article dédié [pfSense] Configurer un VPN IPsec site à site.

Concernant la phase 2, les éléments spécifiques à configurer sont les suivants :

  • Mode : choisir Tunnel IPv4. Attention, le NAT n'est pas possible avec la mise en place d'un VPN IPsec routé [Routed (VTI)].
  • Local Network : choisir "LAN subnet", ou d'une façon générale, le sous-réseau local réel que nous souhaitons rendre accessible à travers le VPN IPsec (192.168.1.0/24, dans notre cas).
  • NAT/BINAT translation : choisir "Network" et indiquer "192.168.100.0/24" pour les champs adresses et masques.
  • Remote Network : choisir "Network" et indiquer "192.168.200.0/24".

Les autres paramètres de la phase 2, ne sont pas spécifiques au fait de monter un VPN natté, nous ne les détaillons donc pas ici.

Exemple de résultat obtenu pour le site A :

Exemple de configuration d'une phase 2 nattée du VPN IPsec - pfSense - Provya


Sur le serveur pfSense du site B, nous réalisons la même configuration, mais en pensant à bien inverser les valeurs.

Exemple de résultat obtenu pour le site B :

Exemple de configuration d'une phase 2 nattée du VPN IPsec - pfSense - Provya




Configuration des règles de filtrage

Il nous reste à adapter nos règles de filtrage au plan d'adressage translaté.

Ainsi, sur notre interface LAN, pour filtrer le trafic du réseau local du site A à destination du site B, en source nous préciserons le LAN subnet (192.168.1.0/24) et en destination le sous-réseau natté pour le site B (192.168.200.0/24).

Exemple de résultat obtenu pour le site A :

Configuration du filtrage sur un VPN IPsec natté - pfSense - Provya


Pour filtrer le trafic en provenance du VPN IPsec (onglet IPsec), l'opération de NAT ayant déjà eu lieu, le filtrage doit bien se faire sur les adresses IP réelles du site local et sur les adresses IP nattées du site distant.

Exemple de résultat obtenu pour le site A :

Exemple configuration du filtrage sur un VPN IPsec natté - pfSense - Provya


Voilà, nous avons vu comment mettre en œuvre un VPN IPsec natté avec pfSense.



Pour aller plus loin

[pfSense] Configurer un VPN IPsec site à site
[pfSense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense
[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 du matériel de qualité ? Alors contactez-nous.

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


           

store.provya.fr

icon Tags de l'article :

[pfSense] Ajouter un accès IPv6 à une connexion Internet IPv4 (via un tunnel)

icon 08/09/2020 - 2 commentaires

Dans cet article, nous présentons une solution pour bénéficier d'un accès Internet IPv6 pour les connexion Internet ne proposant qu'une connectivité IPv4. Cette solution repose sur la mise en place d'un tunnel IPv6.

La solution présentée repose sur le service Tunnelbroker d'Hurricane Electric. Ce service est gratuit et permet de bénéficier d'une plage /48 d'adresses IPv6.
La méthodologie suivie est, bien évidemment, applicable pour d'autres fournisseurs de tunnels IPv6.



Pré-requis

Le seul pré-requis est que nous disposions d'une adresse IPv4 publique pouvant répondre aux PING. Il n'est pas nécessaire que cette adresse IPv4 soit fixe.



1. Création d'un compte sur Tunnelbroker.net

La première étape consiste à se créer un compte sur le site tunnelbroker.net.

Inscription TunnelBroker IPv6 pour pfSense - Provya


On valide l'inscription en suivant le lien envoyé par e-mail. Puis on peut se connecter au site Tunnelbroker.

Dans la colonne de gauche "User functions", nous cliquons sur le lien "Create Regular Tunnel" :

Création d'un tunnel IPv6 chez TunnelBroker - Provya


Il faut renseigner son adresse IPv4 publique (qui doit répondre aux ping) et choisir le serveur avec lequel le tunnel IPv6 sera monté. Étant basé en France métropolitaine, nous choisissons le serveur Hurricane de Paris. Nous cliquons enfin sur "Create Tunnel".

TunnelBroker - choisir le serveur IPv6 d'accès - Provya


Une fois le tunnel créé, nous disposons de toutes les informations nécessaires pour créer notre interface IPv6 sur notre pfSense :

TunnelBroker - information de configuration pour pfSense - Provya


Depuis l'onglet "Advanced", il est possible de personnaliser un certain nombre de paramètres :

  • MTU : il est de 1 480 par défaut. Si vous utilisez une connexion Internet montée via le protocole PPPoE, alors il faut réduire ce MTU. 1 452 devrait être une bonne valeur.
  • Adresse IP publique dynamique : si votre connexion Internet IPv4 ne dispose que d'une adresse IP publique dynamique, alors il faudra mettre à jour automatiquement le tunnel à l'aide de l'Update Key (nous décrivons la procédure dans la suite de l'article).



2. Préparer pfSense au tunnel IPv6

Comme indiqué en pré-requis, il est nécessaire que notre adresse IPv4 publique puisse répondre au PING. Pour configurer notre pfSense afin qu'il réponde au ping sur son adresse IPv4 publique, nous nous rendons dans le menu Firewall > Rules :

menu Firewall > Rules - pfSense - Provya


Depuis l'onglet WAN, nous cliquons sur le bouton "+ Add" afin d'ajouter une nouvelle règle qui comportera les paramètres suivants :

  • Action : Pass
  • Interface : WAN, ou d'une façon générale, l'interface sur laquelle est rattachée votre connexion Internet
  • Address Family : IPv4
  • Protocol : ICMP
  • ICMP Types : any
  • Source : "Single host or Alias" et nous indiquons l'adresse IP du serveur choisi à l'étape précédente. Soit dans notre cas : 216.66.84.42
  • Destination : This firewall

Nous cliquons sur "Save", puis sur "Apply Changes" pour sauvegarder et appliquer la configuration.
La règle une fois créée devrait ressembler à quelque chose comme ceci :

Autoriser ping sur l'interface WAN de pfSense - Provya


Enfin, il est nécessaire que notre pfSense accepte le trafic IPv6. Il s'agit de la configuration par défaut de pfSense. Cependant, si le support d'IPv6 a été désactivé, il est possible de le réactiver en se rendant dans le menu System > Advanced, onglet "Networking" :

Menu System > Advanced > Networking - pfSense - Provya


Vérifier que la ligne "Allow IPv6" soit bien cochée, puis cliquer sur "Save".


Activer IPv6 sur pfSense - Provya




3. Création de l'interface IPv6 sur pfSense

Nous pouvons maintenant créer une nouvelle interface pour notre connexion IPv6. Pour cela, se rendre dans le menu Interfaces > Assignment > GIFs :

Menu Interfaces > Assignments > GIFs - pfSense - Provya


Nous cliquons sur le bouton vert "+ Add". Les champs à remplir sont les suivants :

  • Parent Interface : WAN dans notre cas
  • GIF Remote Address : l'adresse IPv4 du serveur distant, soit dans notre cas : 216.66.84.42
  • GIF tunnel local address : l'adresse IPv6 du client. Cette information correspond à la ligne "Client IPv6 Address" du tableau "Tunnel Details" vu précédemment. Soit, dans notre cas : 2001:470:abcd:781::2
  • GIF tunnel remote address : l'adresse IPv6 du serveur. Cette information correspond à la ligne "Server IPv6 Address" du tableau "Tunnel Details" vu précédemment. Soit, dans notre cas : 2001:470:abcd:781::1
  • GIF tunnel subnet : la taille du sous-réseau IPv6 (au format CIDR). Soit, dans notre cas : 64.

Les autres options doivent être laissées vides ou non-cochées, à moins que vous ne sachiez ce que vous faites.

Exemple de résultat obtenu :

Configuration d'une interface GIF pour IPv6 sur pfSense - Provya


Notre tunnel GIF est créé.
Il reste à lui associer une interface logique. Pour cela, nous nous rendons dans l'onglet Assignment, choisissons l'interface GIF nouvellement créée et cliquons sur le bouton "+ Add" :

Création d'une interface logique GIF sur pfSense - Provya


Nous cliquons sur notre interface OPT1 (ou OPTx d'un façon générale) afin de la configurer de la manière suivante :

  • Enable : cocher la case pour activer l'interface
  • Description : le nom de l'interface. On lui donne un nom plus parlant qu'OPT1. Exemple : WANv6

Les autres options doivent être laissées vides ou non-cochées, à moins que vous ne sachiez ce que vous faites.

Exemple de résultat obtenu :

Configuration d'une interface IPv6 sur pfSense - Provya




4. Configuration de la gateway IPv6 sur pfSense

Lors de la création de l'interface IPv6 (WANv6), une gateway est automatiquement ajoutée.
Si vous possédez déjà une passerelle IPv6, la nouvelle passerelle ne sera pas marquée comme passerelle par défaut. Si vous le souhaitez, il faut donc penser à modifier votre passerelle par défaut depuis le menu System > Routing et renseigner les champs du tableau "Default gateway" :

Configurer passerelle par défaut - pfSense - Provya




5. Ajouter des résolveurs DNS IPv6

TunnelBroker fournit un résolveur DNS IPv6 qui sera ajouté automatiquement à pfSense lorsque l'interface GIF sera montée. Cependant, il est toujours possible d'opter pour d'autres résolveurs DNS. Cette configuration s'opère depuis le menu System > General Setup.

Voici quelques exemples de résolveurs DNS IPv6.

DNS Google :
  • 2001:4860:4860::8888
  • 2001:4860:4860::8844

DNS Quad9 :
  • 2620:fe::fe
  • 2620:fe::9

DNS FDN :
  • 2001:910:800::12
  • 2001:910:800::40



6. Configurer le LAN pour IPv6

À ce stade, pfSense lui-même dispose d'une connectivité IPv6. Pour en faire bénéficier les ordinateurs du LAN, une possibilité est de configurer un dual-stack IPv4/IPv6.

Se rendre dans le menu Interfaces > LAN et apporter les modifications suivantes :

  • IPv6 Configuration Type : choisir "Static IPv6"
  • IPv6 address : indiquer une adresse comprise dans le /64 routé fourni par tunnelbroker. Cette information se trouve à la ligne "Routed /64" du tableau "Tunnel Details" vu précédemment. Soit, dans notre cas 2001:470:abce:781::/64 ; nous pouvons, par exemple, choisir l'adresse 2001:470:abce:781::1 comme adresse IPv6 pour la patte LAN du pfSense

Exemple de résultat obtenu :

Configurer l'interface LAN en IPv6 - pfSense - Provya


Puis, nous cliquons sur "Save" et "Apply Changes" pour valider les modifications.

Nous nous rendons ensuite dans le menu Services > DHCPv6 Server & RA. Les champs à renseigner sont les suivants :

  • DHCPv6 Server : cocher la case pour activer DHCPv6 sur le LAN
  • Range : choisir la plage d'adresses IP que nous souhaitons utiliser pour le service DHCP

Exemple de résultat obtenu :

Configurer DHCPv6 pour l'interface LAN - pfSense - Provya


Nous cliquons sur "Save" pour sauvegarder les changements, puis nous basculons sur l'onglet "Router Advertisements"


Enfin, il ne nous reste plus qu'à configurer une règle de firewall afin d'autoriser le trafic IPv6 pour le LAN. Normalement, une telle règle existe déjà par défaut, mais si nous l'avons supprimée, il faudra la re-créer. Pour cela, nous nous rendons dans le menu Firewall > Rules, onglet LAN et nous cliquons sur "+Add" afin d'ajouter une règle avec les paramètres suivants :

  • Action : pass
  • Interface : LAN
  • Address Family : IPv6
  • Protocol : any
  • Source : LAN net
  • Destination : any

Exemple de résultat obtenu :

Règle de filtrage IPv6 pour l'interface LAN - pfSense - Provya



À ce stade, tout doit fonctionner. On peut tester !

Plusieurs sites permettent de tester sa connectivité. LaFibre.info : ip.lafibre.info/

Tester sa connexion IPv6 sur lafibre.info - Provya


Test-IPv6.com : test-ipv6.com

Tester sa connexion IPv6 - Provya




Mise à jour du tunnel pour les connexions IPv4 avec une adresse IP publique dynamique

Dernier point qui ne concerne que ceux qui ne disposent pas d'une adresse IPv4 fixe : il faut maintenir le tunnel à jour. Pour cela, il faut naviguer dans le menu Services > Dynamic DNS et cliquer sur le bouton "+Add" et configurer les champs de la manière suivante :

  • Service Type : HE.net Tunnelbroker
  • Interface to monitor : WAN
  • Hostname : le tunnel ID qui se trouve sur la première ligne de notre tableau "Tunnel Details"
  • Username : saisir le nom d'utilisateur pour l'accès au site tunnelbroker.net
  • Password : saisir l'Update Key configurable depuis l'onglet "Advanced" du tableau "Tunnel Details"

Cliquer sur "Save" pour sauvegarder les paramètres.


Voilà, nous avons ajouté un accès IPv6 à une connexion Internet n'offrant qu'une connectivité IPv4.

TunnelBroker n'est pas la seule solution existante. Il existe une liste comparative sur Wikipedia (EN)



Pour aller plus loin

[pfSense] Comprendre la gestion des interfaces réseaux
[pfSense] Configurer son serveur DHCP
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez du matériel de qualité ? Alors contactez-nous.

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


           

store.provya.fr

icon Tags de l'article :

[pfSense] Troubleshooting / Dépannage de ses règles de NAT

icon 30/06/2020 - Aucun commentaire

La gestion du NAT peut parfois poser problème.

Dans cet article, nous traitons des problèmes les plus fréquemment rencontrés avec la gestion du NAT sous pfSense.


La gestion du NAT sous pfSense (généralités)

Il existe principalement 3 types de NAT (Network Address Translation) sous pfSense :

  • Port forward : pour la gestion de la redirection de port par adresse IP ; on parle de D-NAT (Destination NAT), c'est-à-dire une modification de l’adresse IP de destination.
  • 1:1 NAT : NAT un-pour-un pour la redirection de tout le trafic d'une adresse IP vers une autre ; on parle également de D-NAT (Destination NAT), c'est-à-dire une modification de l’adresse IP de destination.
  • Outbound : les règles de NAT pour le trafic sortant ; dans ce cas, on part de S-NAT (Source NAT), c'est-à-dire une modification de l'adresse IP source.

Pour approfondir le fonctionnement du NAT sous pfSense, vous pouvez consulter notre article dédié [pfSense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense.



Problèmes de port forward (redirection de port)

Règle de redirection de port incorrecte

Avant toute autre analyse, il est important de vérifier que la règle de redirection de port soit correctement configurée.
Il faut vérifier notamment les éléments suivants :

  • Interface : s'assurer que ce soit la bonne : celle sur laquelle les paquets réseaux arrivent ; il s'agit de l'interface d'entrée, soit le WAN pour une redirection de port depuis Internet vers le réseau local par exemple.
  • Protocol : TCP, UDP, ICMP, ... ; si vous avez un doute entre TCP et UDP, choisir "TCP/UDP".
  • Source : il est très rare de devoir la préciser ; elle devrait être laissée à sa valeur par défaut, c'est-à-dire "*" ou "any".
  • Dest. Address : il s'agit de l'adresse de destination recevant les paquets devant être translatés ; cette adresse IP est portée par le pfSense. Dans le cas d'une redirection de port depuis Internet vers le réseau local, il s'agit donc de l'adresse IP côté WAN.
  • Dest. Ports : le port ou la plage de ports de destination recevant les paquets devant être translatés ; il s'agit donc bien du port d'écoute sur le pfSense, pas du port de destination sur le serveur cible (qui peuvent être similaires ou différents).
  • NAT IP : l'adresse IP translatée ; c'est-à-dire l'adresse IP de destination finale vers laquelle le trafic doit être redirigé par pfSense. Dans le cas d'une redirection de port depuis Internet vers le réseau local, il s'agira donc de l'adresse IP locale du serveur cible.
  • NAT Ports : le port ou la plage de ports de destination finale recevant les paquets ; il s'agit donc bien du port d'écoute du serveur cible final, pas du port d'écoute du pfSense (ils peuvent être similaires ou différents).

Enfin, il faut également avoir en tête que le filtrage s'effectue après la règle de redirection de port. Ainsi, si l'on n'a pas choisi la création automatique d'une règle de filtrage (Add associated filter rule), il faut créer une règle avec la bonne adresse IP de destination, c'est-à-dire l'adresse IP locale du serveur cible.


Règle de filtrage incorrecte ou manquante

Il s'agit d'une erreur couramment rencontrée.
Il faut créer la règle de filtrage sur l'interface d'arrivée du paquet réseau (soit l'interface WAN dans le cas d'une redirection de port depuis Internet vers le réseau local) et il faut garder en tête que la translation d'adresse à déjà eu lieu et que c'est donc avec l'adresse IP de destination translatée (l'adresse IP finale) et le port de destination translaté (le port final) qu'il faut configurer la règle de filtrage.


Un pare-feu est présent sur le serveur cible

Un autre point à prendre en considération : la redirection de trafic peut être correctement effectuée par pfSense, mais le serveur cible peut avoir un pare-feu local d'installé qui bloque le trafic. Il convient donc de vérifier ce point également.


Le service sur le serveur cible n'est pas en écoute sur le bon port réseau

Il faut s'assurer que le serveur cible soit bien en écoute sur le port de destination.
S'il s'agit d'un port TCP, on peut utiliser l'outil de test intégré à pfSense et accessible depuis le menu Diagnostics > Test Port :

Menu Diagnostics > Test Port - pfSense - Provya


En cas de connexion réussie :

Test connexion TCP avec succès - pfSense - Provya

Connexion TCP réussie


En cas d'échec :

Test connexion TCP en échec - pfSense - Provya

Connexion TCP échouée



pfSense n'est pas la passerelle par défaut du serveur cible

Si pfSense n'est pas la passerelle par défaut du serveur cible, alors les paquets ne seront pas routés correctement. Il y a deux solutions par rapport à ce problème :

  • définir pfSense comme passerelle par défaut sur le serveur cible ;
  • configurer une règle d'Outbound NAT (NAT sortant) afin que l'adresse IP source du trafic reçue par le serveur cible soit l'adresse IP du pfSense ; cette solution peut poser des problèmes d'affinité de session côté serveur, elle est donc à manier avec prudence.

Si vous souhaitez implémenter une règle de NAT sortant, dans le cas d'une redirection de port depuis Internet vers le réseau local, la configuration à réaliser serait la suivante :

  • Interface : votre interface locale sur laquelle est rattachée le serveur cible (LAN, DMZ, OPT, ...) ;
  • Protocol : TCP, UDP, ICMP, ... ; si vous avez un doute entre TCP et UDP, choisir "TCP/UDP" ;
  • Source : dans notre cas pris en exemple, choisir any ;
  • Destination : choisir "Network" et indiquer l'adresse IP du serveur cible ; indiquer "32" pour le champ masque afin de ne cibler que le trafic à destination de ce serveur et, enfin, préciser le port réseau de destination sur lequel le serveur est en écoute.

Il faudra également passer le mode d'Outbound NAT d'Automatic vers Hybrid (ou Manual).
Exemple de configuration obtenue :

Exemple configuration Outbound NAT pfSense - Provya

Exemple de règle d'Outbound NAT pour un serveur cible n'ayant pas pfSense comme passerelle par défaut



Tester depuis le réseau local directement au lieu de le faire depuis l'extérieur

Il s'agit ici d'une erreur très courante lorsque l'on souhaite tester une configuration de redirection de port : faire les tests depuis le réseau local lui-même.
Par défaut, la redirection de port ne fonctionnera que pour les connexions provenant de l'extérieur du réseau.


Si après tous ces tests et toutes ces vérifications, la redirection de ports ne fonctionne toujours pas, vous pouvez relire nos articles [pfSense] Comprendre et analyser ses règles de routage et [pfSense] Troubleshooting / Dépannage de ses règles de filtrage.



Problèmes d'Outbound NAT (NAT sortant)

La démarche a suivre sera très similaire à celle détaillée précédemment pour les règles de redirection de port.

Le premier élément à avoir en tête est que les règles d'Outbound NAT se configurent sur l'interface de sortie du firewall. Tandis que pour les règles de redirection de port, c'est l'inverse : elles se configurent sur l'interface d'arrivée du firewall.

Le deuxième élément est qu'il est nécessaire de configurer autant de règles de NAT sortant qu'il y a de réseaux locaux.

Une bonne indication démontrant qu'il existe un problème de NAT sortant sera de voir des paquets quitter pfSense avec une adresse IP source en dehors du sous-réseau de l'interface ; par exemple, voir des paquets réseaux avec une adresse IP source du LAN sur l'interface WAN de pfSense indique qu'il y a une anomalie de NAT. Ces éléments se voient aisément à l'aide de l'outil "Packet Capture" accessible depuis le menu Diagnostics > Packet Capture :

Menu Diagnostics > Packet Capture pfSense - Provya


L'utilisation de l'outil "Packet Capture" fera l'objet d'un article dédié.



Pour aller plus loin

[pfSense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense
[pfSense] Comprendre et analyser ses règles de routage
[pfSense] Troubleshooting / Dépannage de ses règles de filtrage
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez du matériel de qualité ? Alors contactez-nous.

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


           

store.provya.fr

icon Tags de l'article :

pfSense 2.4.5-p1 est disponible !

icon 10/06/2020 - Aucun commentaire

English version: pfSense 2.4.5-p1 now available

Mardi 09 juin 2020 est sortie la dernière version de pfSense. La version 2.4.5-p1.

Cette mise à jour comporte des correctifs de sécurité et de stabilité.

Dans cet article, nous faisons le tour des éléments marquants de cette mise à jour.



Sécurité

Les mises à jour de sécurité majeures sont les suivantes :

  • Correction du bug provoquant un emballement du CPU sur les pfSense virtualisés. Le bug apparaissait lors du rechargement d'une grande table pf (comme la liste des bogons, par exemple). Nous avions détaillé le bug dans notre article pfSense 2.4.5 est disponible !.
  • Correction d'un bug sur le package SSHGuard qui l'empêchait de protéger correctement les attaques par force brute.
  • Mise à jour de Unbound afin de corriger les vulnérabilités CVE-2020-12662 [EN] et CVE-2020-12663 [EN] ; il s'agit de vulnérabilités d'importance "haute" ; Unbound est un résolveur DNS.
  • Mise à jour de json-c afin de corriger la vulnérabilité CVE-2020-12762 [EN] ; il s'agit d'une vulnérabilité d'importance "haute" ; json-c est une bibliothèque d'implémentation du format JSON en C.
  • Correction d'une mauvaise gestion des droits attribués aux groupes d'utilisateurs.
  • Corrections de plusieurs avis de sécurité de FreeBSD.



Bugs / Amélioration

Plusieurs bugs ont été corrigés et des améliorations apportées :

  • Correction d'un problème lié au choix de la langue. C'est principalement le Mandarin de Taïwan qui était impacté par ce problème.
  • Ajout du pilote iwm pour les cartes wifi Intel (le pilote ne permet aux cartes wifi Intel de ne fonctionner qu'en mode client uniquement).
  • Ajour du pilote glxgb pour le support des cartes Ethernet QLogic 10Gbit/s.
  • Mise à jour du support de la norme EDNS ; EDNS (Extension mechanisms for DNS) est une extension au protocole DNS permettant l'ajout de fonctionnalités et l'augmentation de la taille de certains paramètres.
  • Squid : correction d'un dysfonctionnement sur les filtres LDAP contenant des accents.



Processus de mise à jour

Cette nouvelle version est disponible pour les mises à jour, et en téléchargement pour les nouvelles installations.

Si aucune mise à jour ne vous est proposée, il peut être utile de rafraîchir les dépôts de votre pfSense à l'aide des commandes suivantes (en saisir en console ou depuis un shell) :

pkg-static clean -ay; pkg-static install -fy pkg pfSense-repo pfSense-upgrade

Pensez à faire une sauvegarde avant de lancer la mise à jour, et suivez notre tuto complet : [pfSense] Mettre à jour son serveur pfSense.

Enfin, vous pouvez consulter la liste complète des changements en visitant la page suivante : 2.4.5-p1 New Features and Changes [EN]



Pour aller plus loin

[pfSense] Mettre à jour son serveur pfSense
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 du matériel de qualité ? Alors contactez-nous.

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


           

store.provya.fr

icon Tags de l'article :

[pfSense] La gestion des utilisateurs

icon 09/06/2020 - Aucun commentaire

Dans cet article nous traitons de la gestion des utilisateurs et des droits associés sous pfSense. Cette gestion permet de donner des droits aux utilisateurs pour l'accès à l'interface d'administration du pfSense ou pour l'authentification des utilisateurs sur les connexions VPN.



Gestion des utilisateurs

Il existe deux types d'utilisateurs sous pfSense : les utilisateurs locaux, c'est-à-dire dont l'administration (création, modification, suppression) va être gérée localement sur le pfSense ; et les utilisateurs externes authentifiés par un serveur d'authentification, c'est-à-dire des utilisateurs dont l'administration s'effectue depuis un serveur centralisé de type LDAP ou Radius.

Les utilisateurs peuvent être inclus dans un ou plusieurs groupes. Des droits sont donnés soit à l'utilisateur directement, soit au groupe. Les droits appliqués à un groupe s'appliquent à l'ensemble des utilisateurs membres du groupe.

La gestion des droits permet de définir avec précision les autorisations d'accès à l'interface du pfSense. Pour chaque utilisateur (ou chaque groupe), il est possible de définir jusqu'à quelle page précisément il a accès.
La gestion des utilisateurs permet également l'authentification pour les connexions VPN (OpenVPN ou IPsec) des utilisateurs nomades.

La gestion des droits s'opère depuis le menu System > User Manager :

menu System > User Manager sous pfSense - Provya


C'est depuis ce menu que sont gérés les utilisateurs, les groupes et les serveurs d'authentification.



Gestion des droits

Les droits peuvent être gérés au niveau des utilisateurs ou au niveau des groupes. Que l'on souhaite donner un droit à un utilisateur ou à un groupe, l'ordre des opérations à réaliser sera exactement le même : il faut d'abord créer l'utilisateur ou le groupe, puis modifier cet utilisateur (ou ce groupe) afin de lui attribuer les droits souhaités.

Pour chaque utilisateur, les droits attribués sont listés dans le tableau Effective Privileges. Pour chaque droit existant, il existe un champ description qui permet de facilement comprendre le périmètre associé.

Exemple gestion des droits utilisateur sous pfSense - Provya


Sur la capture d'écran ci-dessus, on peut voir que l'utilisateur dispose du droit "WebCfg - Diagnostics: Halt system" qui se lit : accès à l'interface web (WebCfg), menu Diagnostics, page Halt System. Le champ description nous précise que ce droit "permet d'accéder à la page 'Diagnostics: Halt system'.".

Il est possible d'ajouter de nouveaux droits en cliquant sur le bouton "+ Add" se trouvant sous le tableau des droits déjà attribués.

Les droits disponibles sont affichés sous la forme d'une liste. Il est possible de sélectionner plusieurs éléments dans la liste en maintenant la touche "Ctrl" enfoncée.

Le champ Filter permet de filtrer sur un terme précis (il faudra cliquer sur le bouton "Filter" en bas de page pour activer le filtre).

Enfin, le champ sur fond bleu en bas de la page présente la description liée au droit sélectionné.

Exemple de recherche sur la gestion des droits utilisateur sous pfSense - Provya


Sur la capture d'écran ci-dessus, une recherche sur le terme "openvpn" a été faite (1). La ligne "WebCfg - Status: OpenVPN" a été sélectionnée (2) et le champ description sur fond bleu en bas de page nous précise que ce droit permet l'accès à la page 'Status: OpenVPN' (3).

Les principaux droits couramment utilisés sont les suivants :

  • WebCfg - All Pages : donne l'accès à toutes les pages de l'interface web de pfSense.
  • WebCfg - Dashboard (all) : donne l'accès uniquement au tableau de bord et à toutes ses fonctions associées (widgets, graphs, etc.).
  • WebCfg - System: User Password Manager : donne accès uniquement à la page de modification de son mot de passe et à rien d'autre.
  • User - System: Shell account access : donne le droit de se connecter en SSH au pfSense. Cependant, si l'utilisateur ne dispose pas d'un compte root, les fonctionnalités offertes seront limitées...



Ajout / Modification d'un utilisateur

L'ajout d'un utilisateur se fait en cliquant sur le bouton "+ Add" en bas à droite de la page "Users" (page par défaut du menu System > User Manager). Les champs configurables sont les suivants :

  • Disabled : cocher cette case pour désactiver l'utilisateur sans pour autant le supprimer ;
  • Username : le login de l'utilisateur. Le nom d'utilisateur peut faire jusqu'à 16 caractères au maximum et ne doit contenir que des lettres, chiffres, points, tirets ou underscores ;
  • Password : le mot de passe et sa confirmation ;
  • Full name : le nom complet de l'utilisateur ;
  • Expiration date : il est possible de définir une date d'expiration au compte utilisateur. Si ce champ est laissé vide, le compte n'expirera jamais. Si l'on souhaite renseigner une date il faut faire attention au format qui est le format américain (MM/JJ/AAAA - Mois/Jour/Année) ;
  • Custom Settings : permet de modifier les paramètres d'affichage pour l'utilisateur comme le thème de l'interface web, le comportement du menu, l'ordre d'affichage des interfaces réseaux, etc. ;
  • Group membership : les groupes d'appartenance de l'utilisateur. Un utilisateur peut faire partie de plusieurs groupes. Les droits de chaque groupe s'applique alors à l'utilisateur ;
  • Effective Privileges : ce tableau permet d'attribuer des droits directement à l'utilisateur. Il est à noter que ce tableau n'apparaît qu'à la modification d'un utilisateur, il n'est pas proposé lors de la création ;
  • Certificate : permet la création d'un certificat utilisateur. Il est à noter que cette section n'a pas exactement le même affichage suivant si l'on crée ou si l'on modifie l'utilisateur. Lors de la modification d'un utilisateur, il sera possible de lui associer un certificat existant. Pour davantage d'informations sur la création d'un certificat, voir notre article [pfSense] La gestion des certificats pour les connexions OpenVPN ;
  • Authorized keys : une clé publique pour l'authentification SSH peut être saisie ici. Ainsi, l'utilisateur pourra s'authentifier avec sa clé privée plutôt qu'avec un son mot de passe ;
  • IPsec Pre-Shared Key : utilisé uniquement si l'on utilise un VPN IPsec mobile avec une clé pré-partagée pour une authentification non-XAuth (Extended Authentication). Dans le cas contraire, ce champ doit être laissé vide.

Si certaines options ne sont pas accessibles lors de la création de l'utilisateur, il faut sauvegarder, puis modifier l'utilisateur pour y avoir accès.



Ajout / Modification d'un groupe

Les groupes sont le moyen le plus pratique pour gérer les droits affectés aux utilisateurs sans avoir besoin de les gérer individuellement utilisateur par utilisateur.
Un utilisateur bénéficiera des droits cumulés de chaque groupe dont il fait partie.

Comme pour les utilisateurs, il faut d'abord créer un groupe avant de pouvoir lui attribuer des droits. Il faut donc créer un groupe, puis le modifier pour lui ajouter des droits.

L'ajout d'un groupe se fait en cliquant sur le bouton "+ Add" en bas à droite de la page "Groups" (accessible depuis le menu System > User Manager). Les champs configurables sont les suivants :

  • Group name : le nom du groupe. Le nom du groupe peut faire jusqu'à 16 caractères au maximum et ne doit contenir que des lettres, chiffres, points, tirets ou underscores ;
  • Scope : la portée du groupe. Deux valeurs sont possibles : local - crée le groupe localement pour des utilisateurs locaux ; remote utilisé pour l'authentification via un serveur externe ;
  • Description : champ optionnel purement informatif ;
  • Group Membership : la liste des utilisateurs membres du groupe ;
  • Assigned Privileges : Ce tableau permet d'attribuer des droits aux membres du groupe. Il est à noter que ce tableau n'apparaît qu'à la modification d'un groupe, il n'est pas proposé lors de la création.



Quelques options avancées

L'onglet Settings permet de configurer deux éléments : la durée de validité d'une session et comment les utilisateurs sont authentifiés.

Durée de validité de la session (Session timeout)

La durée de validité d'une session est, par défaut, de quatre heures (240 minutes). Il est possible de réduire ou d'augmenter la durée de validité de la session. La durée de session est exprimée en minutes.
Il est également possible de faire en sorte que les sessions n'expirent jamais ; il faut pour cela passer la valeur à 0.

Notre recommandation est d'avoir une validité de session d'une durée d'une heure au maximum.


Serveur d'authentification (Authentication Server)

Cette option permet de choisir le serveur primaire d'authentification. Ce peut être un serveur distant Radius ou LDAP, ou la base de données locale de pfSense.
Dans le cas, où une authentification via un serveur distant est configurée et que celui-ci n'est pas accessible, l'authentification se fera via la base de donnée locales en secours.

Lorsque l'on souhaite utiliser l'authentification via un serveur Radius ou LDAP, les utilisateurs et/ou les groupes doivent également être définis côté firewall afin que les droits soient correctement alloués. Il n'y a pas vraiment de solution pour obtenir dynamiquement les autorisations à partir d'un serveur d'authentification.

Ainsi, pour que les droits attribués à un groupe fonctionnent, il faut :

  1. Que le groupe existe sur le serveur d'authentification distant.
  2. Que le même groupe (avec le même nom) existe en local sur le firewall.
  3. Que le pfSense puisse joindre le serveur d'authentification et récupérer la liste des groupes.

Nous avons fait le tour des éléments à connaître pour la gestion des utilisateurs sous pfSense.
L'authentification via un serveur externe fera l'objet d'un autre article détaillé.



Pour aller plus loin

Best practices / Recommandations pour la configuration de votre firewall
[pfSense] La gestion des certificats pour les connexions OpenVPN
[pfSense] Sécurisez l'accès distant de vos collaborateurs nomades avec OpenVPN
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez du matériel de qualité ? Alors contactez-nous.

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


           

store.provya.fr

icon Tags de l'article :

[pfSense] Créer des règles de firewall basées sur des conditions horaires

icon 05/05/2020 - Aucun commentaire

Une fonctionnalité pratique de pfSense, mais très méconnue, est la possibilité de définir des règles de filtrage qui seront appliquées en fonction de la date, du jour ou de l'heure.

On peut imaginer l'utilité pour ouvrir des accès temporaires le temps de mises à jour planifiées, pour différencier les horaires d'accès à Internet pour un usage professionnel / personnel ou encore pour un événement éphémère.

Ces règles de filtrage sont présentes avec les autres règles, mais elles seront actives uniquement sur les créneaux horaires définis. Le reste du temps, elles seront simplement ignorées par pfSense.



Configurer un calendrier

La première étape consiste à configurer un calendrier. Cela se passe dans le menu Firewall > Schedules :

menu Firewall > Schedules - pfSense - Provya


Cliquer sur le bouton "+ Add".

Les champs à compléter sont les suivants :

  • Schedule Name : le nom de votre "calendrier", sans espace ni caractères spéciaux.
  • Description : champ purement informatif.
  • Month : le mois et l'année applicable ; on ne peut sélectionner qu'un seul mois à la fois.
  • Date : les jours où la condition horaire sera appliquée. Pour sélectionner chaque jour individuellement, il suffit de cliquer sur la case correspondante. Un jour sélectionné sera sur fond vert. Il est également possible de sélectionner toutes les occurrences d'un jour donné (par exemple tous les samedis) ; pour cela, on peut cliquer directement sur l'entête de colonne correspondant (Sat dans notre exemple du samedi). Les jours sélectionnés seront sur fond bleu.
  • Time : l'horaire de début et de fin (se configure par tranche de quinze minutes)

Par exemple, si nous souhaitons sélectionner tous les samedis du mois de mai 2020 sur le créneau 12h - 14h, le résultat ressemblera à ceci :

Exemple de condition horaire sous pfSense - Provya


Une fois notre configuration réalisée, il faut la valider en cliquant sur le bouton "+Add Time".
Cela permet également d'ajouter d'autres dates et d'autres créneaux horaires à notre calendrier.

Enfin, il reste à cliquer sur le bouton "Save" pour sauvegarder notre calendrier.



Appliquer le calendrier à une règle de filtrage

La création, ou la modification, d'une règle de filtrage s'effectue depuis le menu Firewall > Rules :

menu Firewall > Rulles - pfSense - Provya


Une fois sur votre règle de filtrage, il faut se rendre dans les options avancées (Section "Extra Options", cliquer sur le bouton "Display Advanced" :

options avancées des règles de filtrages - pfSense - Provya


Puis pour le champ Schedule, choisir le calendrier créé précédemment :

Affectation d'un calendrier au filtrage - pfSense - Provya


Exemple de résultat obtenu :

exemple règle de firewall - pfSense - Provya


Le pictogramme jaune indique que la règle n'est actuellement pas active ; c'est le cas de la première règle avec le calendrier "samedi_provya".
Le pictogramme vert indique que la règle est actuellement active ; c'est le cas de la seconde règle avec le calendrier "vendredi_provya".


Dernier élément pour conclure ce court article : par défaut les états sont réinitialisés dès l'expiration du calendrier.
Cela signifie que l'accès est immédiatement coupé y compris pour les sessions actives.

Si l'on souhaite conserver les sessions actives jusqu'à leur expiration, il faut cocher la case "Do not kill connections when schedule expires" accessible depuis System > Advanced, onglet "Miscellaneous".



Pour aller plus loin

Best practices / Recommandations pour la configuration de votre firewall
[pfSense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense
[pfSense] Troubleshooting / Dépannage de ses règles de filtrage
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez du matériel de qualité ? Alors contactez-nous.

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


           

store.provya.fr

icon Tags de l'article :

[pfSense] Aider la montée en charge (scalabilité) de ses liens OpenVPN

icon 14/04/2020 - 2 commentaires

Dans cet article nous allons voir les bonnes pratiques à connaître et appliquer afin d'accompagner le mieux possible la montée en charge de ses accès OpenVPN.
Le but est d'améliorer le débit et le nombre maximum d'utilisateurs simultanés.

Dans cet article, nous nous concentrons sur les accès OpenVPN. Dans un prochain article, nous nous attaquerons à IPsec.



IPsec est plus rapide

De part son mode de fonctionnement et son implémentation, IPsec offre de meilleures performances qu'OpenVPN.
Aussi, une solution (radicale ?), pour accroître la capacité de vos liens VPN est de basculer d'OpenVPN vers IPsec.

IPsec peut être utilisé aussi bien pour établir un lien VPN entre deux sites distants, que pour des utilisateurs nomades. Quoique nous ne recommandions pas IPsec pour les utilisateurs distants (OpenVPN est bien plus pratique et facile à mettre en œuvre et passe bien mieux les problématiques de NAT ou CGN).

Notre recommandation est d'utiliser IPsec pour les liens VPN en mode site-à-site, et d'utiliser OpenVPN pour les accès utilisateurs distants.



Utiliser UDP

Lors de la configuration d'OpenVPN, vous avez le choix du protocole de transport TCP ou UDP.
De par son mode de fonctionnement (transmission sans connexion, contrairement à TCP), UDP sera plus efficace et plus rapide.

Ainsi, il vaut donc mieux conserver UDP qui est le protocole par défaut.



Utiliser TLS uniquement pour l'authentification

OpenVPN peut utiliser le protocole TLS aussi bien pour l'authentification que pour le chiffrement du Control Channel (c'est-à-dire le canal de communication établi entre le serveur et le client OpenVPN).
Il est possible d'utiliser TLS uniquement pour l'authentification. Il s'agit d'ailleurs de la configuration par défaut proposée sous pfSense.

TLS pour l'authentification OpenVPN sous pfSense - Provya


Dans tous les cas, le trafic VPN sera chiffré.



Utiliser l'accélération cryptographique

De plus en plus de firewall sont pourvu d'une puce d'accélération cryptographique (AES-NI). La différence de performance pour les liens VPN entre les firewall supportant l'AES-NI et les autres est véritablement importante, d'environ un facteur 10, voire davantage.

Si votre firewall le supporte, il faut activer l'accélération cryptographique AES-NI et BSD Cryptodev depuis le menu System > Advanced ; onglet Miscellanous :

Menu System > Advanced > Miscellaneous - pfSense - Provya


Pour l'option "Cryptographic Hardware", choisir "AES-NI and BSD Crypto Device (aesni, cryptodev)" et penser à valider le changement en cliquant sur le bouton "Save" en bas de page :

Activer l'accélération cryptographique sous pfSense - Provya


Il faut ensuite configurer votre VPN avec un algorithme de chiffrement compatible avec l'accélération cryptographique AES-NI, comme par exemple AES-GCM ou AES-CBC.



Utiliser AES-GCM

L'utilisation d'un chiffrement efficace comme les codes AEAD (authenticated encryption with associated data), qui combinent chiffrement et authentification, permet d'accroître la sécurité et les performances.
Aussi bien IPsec, qu'OpenVPN peuvent utiliser AES-GCM, qui est un code AEAD. En revanche, le support côté client peut varier selon la plate-forme.

C'est pourquoi pour les accès OpenVPN pour les utilisateurs distants, il est conseillé de proposer en priorité AES-GCM, tout en autorisant la négociation des paramètres cryptographiques (NCP - Negotiable Cryptographic Parameters) si besoin.

D'un point de vue configuration de votre serveur OpenVPN, la configuration ressemblera à cela :

  • Encryption Algorithm : choisir AES-GCM
  • Enable NCP : cocher la case Enable Negotiable Cryptographic Parameters
  • NCP Algorithms : choisir AES-GCM (à placer en premier) ainsi que les autres algorithmes que vous souhaitez activer

Utiliser AES-GCM pour OpenVPN sous pfSense - Provya




Réduire le chiffrement au strict minimum

Pour la configuration des liens VPN, nous recommandons généralement d'opter pour de l'AES-256 ou supérieur. Cependant, dans le cas d'une forte activité ou si vous constatez des lenteurs, il est possible de diminuer le niveau de chiffrement et par conséquent le niveau de sécurité au pallier inférieur. Le strict minimum aujourd'hui est l'utilisation d'une clef de 128 bits.

Dans son Référentiel Général de Sécurité (RGS), l'ANSSI recommande l'utilisation de clés symétriques d'une taille d'au moins 128 bits.



Désactiver la compression

Il peut être tentant d'activer la compression sur les liens à faible débit. En réalité, c'est inefficace et non-sécurisé.

Aujourd'hui, la plupart des données qui transitent via les liens VPN est déjà chiffrée ou incompressible. Aussi, activer la compression sur le lien OpenVPN va juste gaspiller du CPU, sans réellement réduire la consommation de bande-passante.
De plus, la compression utilisée par OpenVPN est sensible à des attaques telles que VORACLE (EN).

Aussi, côté serveur OpenVPN, il faut conserver la compression désactivée dans tous les cas. Il s'agit du choix par défaut sur pfSense.
Le paramètre Compression doit rester à Disable Compression :

Désactiver la compression LZO sur les liens OpenVPN sous pfSense - Provya




Utiliser plusieurs serveurs OpenVPN

OpenVPN ne supporte pas le multithreading. Aussi, si votre serveur dispose de plusieurs CPU, un seul sera utilisé par votre serveur OpenVPN.
Ainsi, si le CPU est le facteur limitant, une bonne solution de contournement consiste à configurer plusieurs serveur OpenVPN.

Deux approches sont possibles :

  • Répartir de manière fixe la charge sur plusieurs serveurs OpenVPN : certains clients auront accès à un serveur OpenVPN, d'autres à un autre serveur. Il s'agit de la solution la plus simple et rapide à mettre en œuvre (mais pas nécessairement la meilleure).
  • Répartir la charge aléatoirement sur les plusieurs serveurs OpenVPN : pour cela, il faut que la configuration soit la même pour les deux serveurs OpenVPN (même CA, mêmes paramètres de chiffrement, etc.), mais avec un sous-réseau différent pour chacun. Puis, il faut ajouter le paramètre remote-random dans la configuration du client afin qu'il se connecte de manière aléatoire sur l'un des serveurs OpenVPN configurés. Il s'agit de la solution optimale d'un point de vue scalabilité.

Attention, en démultipliant le nombre de serveurs OpenVPN en fonctionnement sur un même serveur pfSense, on augmente forcément la consommation de mémoire-vive.



Réduire le MSS

Il est possible que vous rencontriez des lenteurs importantes pour des accès via VPN à des partages de fichiers Windows ou à des sites web (ou d'une façon générale à des services utilisant TCP). Dans ce cas, il peut être très utile de réduire le MSS (Maximum Segment Size).

Ce paramètre se définit en ajoutant le code suivant dans le champ "Custom Options" de votre serveur OpenVPN :
mssfix 1400

Régler MSS MTU d'OpenVPN sous pfSense - Provya


Notre recommandation est de démarrer avec une valeur à 1400, puis, si ça fonctionne, l'augmenter progressivement jusqu'à ce que les problèmes réapparaissent. Une fois atteint le point de dysfonctionnement, il suffit de réduire de nouveau très légèrement la valeur du MSS.


Nous avons fait le tour des recommandations de configuration pour l'optimisation de ses accès OpenVPN. D'autres réglages sont également possibles et peuvent permettre, suivant les cas, d'aider à la montée en charge de son VPN, mais ces réglages sont souvent expérimentaux et générateurs de bugs ou entraînent de grosses lacunes de sécurité ; c'est la raison pour laquelle nous ne les présentons pas ici.



Pour aller plus loin

[pfSense] Sécurisez l'accès distant de vos collaborateurs nomades avec OpenVPN
[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Configurer un VPN IPsec site à site
[pfSense] Les pannes courantes et leurs solutions sur un VPN IPsec
Tous nos articles classés par thème
Voir un article au hasard


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

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


           

store.provya.fr

icon Tags de l'article :