Provya

Sécurité et téléphonie

Articles & Tutoriaux  -  Liens & Actualités

[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


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


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 :

pfSense 2.4.5 est disponible !

icon 31/03/2020 - 2 commentaires

English version: pfSense 2.4.5 now available

Jeudi 26 mars est sortie la dernière version de pfSense. La version 2.4.5.

Cette mise à jour comporte des correctifs de sécurité, plusieurs nouvelles fonctionnalités et des correctifs de stabilité.

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



Nouvelles fonctionnalités

Les nouvelles fonctionnalités majeures sont les suivantes :

  • Le système d'exploitation est mis à jour vers FreeBSD 11.3 ;
  • Ajout de la possibilité de faire des recherches et des filtres sur plusieurs pages, dont notamment, la page de gestion des certificats (System > Cert. Manager), la page de visualisation des baux DHCP (Status > DHCP Leases), la page de visualisation de la table ARP (Diagnostics > ARP Table) ;
  • Ajout des groupes DH et PFS 25, 26, 27 et 31 pour les VPN ;
  • Modification de la configuration par défaut du système de fichiers UFS à noatime pour les nouvelles installations (ce paramètre n'est pas appliqué si vous faites une mise à jour de votre pfSense). Cela permet de réduire les écritures inutiles sur le disque ;
  • Ajout du paramètre autocomplete=new-password sur les formulaires de l'interface web contenant des champs d'authentification. Cela évite une auto-complétion par le navigateur ;
  • Ajout de Gandi et Linode dans la gestion des DNS dynamique (Services > Dynamic DNS).



Sécurité

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

  • Renforcement contre les attaques de type cross-site scripting (XSS) sur plusieurs pages de l'interface web ;
  • Résolution d'un problème d'escalade de privilège : un utilisateur authentifié, qui était autorisé à accéder au widget d'image pouvait exécuter un code PHP arbitraire ou accéder à des pages pour lesquelles il n'avait normalement pas les droits ;
  • Correction du format des messages d'échec d'authentification XMLRPC (servant pour la réplication sur une installation avec deux pfSense en cluster) afin que ces messages puissent être traités par sshguard ;
  • Mise à jour de la page d'erreur CSRF (Cross-site request forgery).



Bugs

Plusieurs bugs importants ont également été corrigés. C'est une très bonne chose.

Les bugs en question sont les suivants :

  • La durée de vie par défaut du certificat de l'interface web a été réduite à 398 jours. Ce qui est beaucoup plus conforme aux standards actuels. Un certificat avec une durée de vie trop longue entraînait des erreurs sur un certain nombre de plateformes (principalement iOS 13 et macOS 10.15). Si vous êtes sur une mise à jour et non pas sur une nouvelle installation, vous pouvez générer un nouveau certificat à partir de la console ou en SSH avec la commande : pfSsh.php playback generateguicert ;
  • Corrections de plusieurs bugs sur les IPsec VTI (IPsec routé) ;
  • Correction de plusieurs bugs d'affichage avec la gestion des vues personnalisées sur la page de supervision (Status > Monitoring) ;
  • Correction du bug de redirection pour les utilisateurs (autre que le compte admin) qui étaient redirigés vers une mauvaise page lorsqu'ils souhaitaient accéder à la page de gestion des utilisateurs (System > User Manager) ;
  • Correction d'un problème lors de la résolution des entrées FQDN dans les alias où certaines entrées pouvaient être manquantes.



Processus de mise à jour

En raison de la nature importante des changements dans cette mise à jour, des alertes ou des erreurs peuvent être affichées durant le process de mise à jour. Il ne faut pas spécialement en tenir compte. Notamment si vous voyez des erreurs concernant PHP ou la mise à jour de packages.
En conséquence, seules les erreurs qui persistent après la mise à jour sont significatives.

Dans tous les cas, 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 New Features and Changes[EN]



Avertissement : Hyper-V

Attention, un bug a été rapporté pour les installations pfSense 2.4.5 fonctionnant sous Hyper-V (versions 2016 ou 2019). Il y a un emballement du CPU dès que plus de 2 CPU sont attribués à la VM faisant tourner pfSense.
Une solution de contournement consiste à réduire à un le nombre de CPU virtuel alloué à la VM.

Merci à @Hello qui a signalé ce problème en commentaire.

Mise à jour : l'origine du problème a été trouvé. Un bug a été ouvert : pf: tables use non SMP-friendly counters. Le bug apparaît lorsqu'un grande table est rechargée (la liste des bogons, par exemple) ; aussi une possible solution de contournement est de décocher la case "Block bogon networks" sur toutes les interfaces.



Pour aller plus loin

[pfSense] Mettre à jour son serveur pfSense
[pfSense] Configurer un cluster de 2 pfSense redondants (failover)
[pfSense] Tout comprendre aux alias
Best practices / Recommandations pour la configuration de votre firewall


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 :

[pfSense] Comprendre et analyser les logs de son VPN IPsec

icon 10/03/2020 - Aucun commentaire

Savoir lire les logs de pfSense concernant IPsec peut être difficile.
Nous donnons dans cet article les clefs pour comprendre les logs IPsec et identifier les erreurs de configuration associées.

Après notre article sur comment configurer un VPN IPsec sous pfSense, notre article sur les causes de défaillances généralement rencontrées sur un VPN IPsec et leurs solutions les plus probables, nous abordons dans cet article la gestion des logs d'IPsec sous pfSense et la signification des messages pouvant être rencontrés dans ces fichiers de journalisation.



Configurer les logs IPsec

Les logs pour les VPN IPsec peuvent être configurés pour apporter des informations utiles pour le debogage. Pour effectuer cette configuration, se rendre dans le menu VPN > IPsec, puis onglet Advanced :

menu VPN > IPsec > Advanced - pfSense - Provya


Au sein de la rubrique "IPsec Logging Controls", configurer les options avec les valeurs suivantes :

  • IKE SA : Diag
  • IKE Child SA : Diag
  • Configuration Backend : Diag
  • Autres options : Control

Exemple de résultat obtenu :

Configuration des logs pour debug VPN IPsec sous pfSense - Provya


Il est à noter que modifier ces options ne coupera pas le VPN IPsec.



Interpréter les logs IPsec liés à la phase 1

Les logs des VPN IPsec sont accessibles depuis le menu Status > System Logs, onglet IPsec :

Menu Status > System Logs > IPsec - pfSense - Provya


Nous allons parcourir les messages que l'on peut rencontrer le plus couramment dans les logs.

La bonne manière de procéder, pour analyser les logs, consiste à rechercher les expressions clés indiquant quelles étapes fonctionnent ou, au contraire, échouent. Cela permet d'orienter très pécisément le diagnostique.

Par exemple, si l'on voit dans les logs "IKE_SA ... established", cela signifie que la phase 1 s'est déroulée avec succès et qu'une SA (Security Association) a été négociée. Ce qui signifie que les deux firewall établissant le tunnel IPsec arrivent à échanger de manière sécurisée.

Si l'on voit "CHILD_SA ... established", alors cela signifie qu'une phase 2 s'est déroulée avec succès également. Le tunnel doit être UP (en tout cas, pour au moins l'une des phases 2 ; dit autrement, pour au moins un sous-réseau local et un sous-réseau distant).



Connexions réussies

Lorsqu'un tunnel est correctement monté, les deux firewall doivent disposer dans leurs logs respectifs d'informations indiquant qu'un IKE SA et un Child SA ont été montés avec succès.

Quand il y a plusieurs phases 2, on doit visualiser un "CHILD_SA ... established" pour chacune d'entre elles.

Exemple de log d'un tunnel monté avec succès :

Logs IPsec tunnel monté pfSense - Provya


On voit sur cette capture d'écran que la phase 1 a été négociée avec succès (IKE_SA con2000[11] established) entre le firewall possédant l'adresse IP 192.0.2.90 et celui possédant l'adresse IP 192.0.2.74).

Puis, on voit qu'une phase 2 a été négociée avec succès (CHILD_SA con2000{2} established) permettant aux sous-réseaux 192.168.48.0/24 d'un côté et 10.42.42.0/24 de l'autre d'échanger entre eux.



Connexions échouées

Les exemples suivants montrent plusieurs cas de connexions IPsec échouées.

Un point important à avoir en tête est que dans la plupart des cas, le firewall initiant la connexion IPsec (initiateur) aura peu d'informations pertinentes dans ses logs (on ne saura pas précisément la raison de l'échec de la connexion) ; tandis que le firewall répondant à la demande de connexion IPsec (répondant) aura des informations beaucoup plus précises et détaillées. C'est normal. Il s'agit là d'un élément de sécurité : il serait en effet peu sûr de fournir à un attaquant potentiel trop d'informations sur la configuration du VPN.



Phase 1 - Écart de configuration Main / Aggressive

Dans cet exemple, l'initiateur est configuré en mode "Aggressive", tandis que le répondant est configuré en mode "Main".

Extrait des logs pour l'initiateur :

Échec négociation phase 1 IPsec pfSense - Provya


On lit bien dans les logs que la négociation de la phase 1 se fait en mode "Aggressive" et que l'authentification a échoué (AUTHENTICATION FAILED). Mais l'on ne connaît pas la raison de cet échec.

Extrait des logs pour le répondant :

Échec négociation phase 1 côté répondant IPsec pfSense - Provya


On lit dans les logs que la négociation de la phase 1 a échoué et que la raison de cet échec est que le mode "Aggressive" n'est pas autorisé. Les logs sont bien plus explicites.



Phase 1 - Erreur d'identifiant

Lorsque l'identifiant ne correspond pas (pour rappel, l'identifiant est généralement configuré pour être l'adresse IP publique du firewall), l'initiateur montre seulement que l'authentification a échoué. Le répondant précise la raison de cet échec.

Extrait des logs pour l'initiateur :

Échec identifiant phase 1 côté initiateur IPsec pfSense - Provya


On peut voir que l'erreur retournée est la même que dans le cas précédent : il s'agit d'une erreur d'authentification standard.

Extrait des logs pour le répondant :

Échec identifiant phase 1 côté répondant IPsec pfSense - Provya


Les logs sont beaucoup plus explicites : "no peer config found" ; l'identifiant correspondant à la requête n'a pas été trouvé.



Phase 1 - Erreur sur la Pre-Shared Key

Une erreur sur la PSK peut être difficile à diagnostiquer. En effet, on ne trouvera pas de message explicite dans les logs indiquant qu'il y a une erreur sur la Pre-Shared Key.

Les logs, aussi bien côté initiateur que répondant, ressembleront à ceci :

Erreur PSK sur VPN IPsec phase 1 pfSense - Provya


Si vous voyez ces messages apparaître dans vos logs IPsec, un conseil : vérifiez la valeur de votre Pre-Shared Key sur chaque firewall établissant le VPN IPsec.



Phase 1 - Écart sur le choix de l'algorithme de chiffrement ou de hachage

Extrait des logs pour l'initiateur :

Erreur chiffrement sur VPN IPsec phase 1 côté initiateur pfSense - Provya



Extrait des logs pour le répondant :

Erreur chiffrement sur VPN IPsec phase 1 côté répondant pfSense - Provya


Les messages sont très explicites et indiquent le problème exact. Ici, l'initiateur était configuré avec de l'AES-128 et le répondant avec de l'AES-256.

Il est à noter que la portion de message "MODP" correspond au groupe Diffie-Hellman (DH group). Ici, on voit que les deux firewall ont bien la même configuration de groupe Diffie-Hellman "MODP_1024".
S'il y avait eu un écart, nous aurions eu deux valeurs différentes, comme par exemple MODP_1024 d'un côté et MODP_8192 de l'autre.

Enfin, la portion "HMAC" correspond à l'algorithme de hachage. Ici, la valeur est HMAC_SHA1_96. Encore une fois, s'il y a un écart entre les deux, il faut alors corriger.



Interpréter les logs IPsec liés à la phase 2

Phase 2 - Erreur sur la configuration des sous-réseaux

Dans l'exemple ci-dessous, la phase 2 du firewall initiateur est configurée avec le sous-réseau 10.3.0.0/24 vers le 10.5.0.0/24. Tandis que le firewall répondant est configuré avec 10.5.1.0/24 pour son côté.

Extrait des logs pour l'initiateur :

Erreur log config VPN IPsec phase 2 côté initiateur pfSense - Provya


Extrait des logs pour le répondant :

Erreur log config VPN IPsec phase 2 côté répondant pfSense - Provya


Dans les logs du répondant, on peut visualiser les sous-réseaux présents dans la négociation de la phase 2 (ligne "looking for a child config for ...") et les sous-réseaux présents dans sa configuration locale (lignes "proposing traffic selectors for ...").

En comparant les deux, une erreur peut être détectée.
Enfin, la mention "no matching CHILD_SA config found" sera toujours présente dans les logs lorsqu'il y aura une erreur de configuration de ce type. Ce message signifie que pfSense n'a pas pu trouver de phase 2 correspondant à la requête du firewall initiateur.



Phase 2 - Écart sur le choix de l'algorithme de chiffrement ou de hachage

Extrait des logs pour l'initiateur :

Erreur chiffrement sur VPN IPsec phase 2 côté initiateur pfSense - Provya


Extrait des logs pour le répondant :

Erreur chiffrement sur VPN IPsec phase 2 côté répondant pfSense - Provya


Dans ce cas, l'initiateur reçoit un message indiquant que le répondant n'a pas pu trouver de proposition correspondant à la demande (ligne "received NO_PROPOSAL_CHOSEN").
Côté répondant, les logs sont plus détaillés et précisent la proposition reçue (ligne received proposals) et la proposition configurée localement (ligne configured proposals).

Dans l'exemple ci-dessus, sur les extraits de logs, on voit que c'est l'algorithme de chiffrement qui est différent (AES_CBC_128 dans un cas et AES_CBC_256 dans l'autre).

La portion "HMAC" correspond à l'algorithme de hachage. Ici, la valeur est HMAC_SHA1_96. Encore une fois, s'il y a un écart entre les deux, il faut alors corriger.


Voilà ! Nous avons fait le tour des messages de logs les plus courants pour les VPN IPsec sous pfSense.



Pour aller plus loin

[pfSense] Configurer un VPN IPsec site à site
[pfSense] Les pannes courantes et leurs solutions sur un VPN IPsec
[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Troubleshooting / Dépannage de ses règles de filtrage


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 :

[pfSense] Les pannes courantes et leurs solutions sur un VPN IPsec

icon 25/02/2020 - Aucun commentaire

Comprendre et dépanner un VPN IPsec qui ne fonctionne pas comme voulu n'est jamais une chose facile.
Heureusement, pfSense offre tout un panel d'outils permettant d'aider à orienter le diagnostique afin de trouver l'origine du problème.

Après notre article sur comment configurer un VPN IPsec sous pfSense, nous présentons dans cet article les causes de défaillances généralement rencontrées et leurs solutions les plus probables.
Dans un autre article, nous présentons dans le détail comment lire et comprendre les logs d'IPsec sous pfSense.



Le tunnel ne monte pas

La première étape consiste à vérifier que le service IPsec est bien démarré sur pfSense. Pour cela, se rendre dans le menu Status > Services et vérifier que le service IPsec ne soit pas arrêté :

Vérifier statut service VPN IPsec sous pfSense - Provya


Sur la capture d'écran ci-dessus, on peut voir que le service ipsec est bien démarré.

Si le service ipsec n'est pas lancé ou arrêté (c'est-à-dire soit il n'apparaît pas dans la liste des services, soit il est à l'état "stop"), il faut vérifier que la phase 1 du VPN IPsec soit bien démarrée. Cette vérification s'effectue depuis le menu VPN > IPsec :

État phase 1 VPN IPsec pfSense - Provya


Sur la capture d'écran ci-dessus, on peut voir que le tunnel IPsec est désactivé. Il suffit de cliquer sur le bouton vert "Enable" se trouvant en début de ligne pour activer le tunnel IPsec.

De la même façon, s'il s'agit d'un VPN IPsec pour client mobile, il faut se rendre dans l'onglet "Mobile Clients" et vérifier que la case "Enable IPsec Mobile Client Support" soit bien cochée.

Si le service est correctement lancé, il faut ensuite vérifier dans les logs du firewall (menu Status > System Logs ; onglet Firewall) que la connexion IPsec ne soit pas bloquée. Le cas échéant, il faudra ajouter une règle de filtrage pour autoriser le trafic bloqué.

Les règles de filtrage sont normalement activées automatiquement pour IPsec, mais cette option étant désactivable, mieux vaut vérifier...

Enfin, si le tunnel ne monte toujours pas, la cause principale (et de loin) pour laquelle un VPN IPsec ne monte pas est une erreur de configuration. C'est parfois une erreur simple comme le groupe DH qui n'est pas configuré de la même manière des deux côtés, ou une erreur sur un masque de sous-réseau (/24 d'un côté et /32 de l'autre).
Si le lien VPN est monté avec un routeur autre que pfSense de l'autre côté, il faut avoir en tête que sur ces équipements des options peuvent être masquées par défaut sous un bouton "Advanced" ou "Configuration avancée". Bref, il est important de vérifier avec précision que la configuration de chaque côté du tunnel IPsec soit bien la même pour les différentes options.

Dernier point à vérifier : en fonction du type d'accès à Internet utilisé de part et d'autre, notamment dans le cas d'un VPN IPsec pour les clients mobiles (qui peuvent être derrière un CGN - Carrier-grade NAT) il est possible que le trafic IPsec puisse être bloqué. Dans ce cas, l'utilisation du NAT-T (NAT Traversal) peut être une solution car il permet d'encapsuler le protocole ESP sous le port UDP 4500 pour contourner ces problèmes.



Le tunnel monte mais le trafic ne passe pas

Le suspect numéro un dans ce type de situation est un problème au niveau des règles de filtrage. Il faut s'assurer que les règles de filtrage ont correctement été configurées. Il faut vérifier l'état des règles de filtrage pour l'interface LAN (ou les autres interfaces locales, le cas échéant) et pour l'interface IPsec. Si les règles semblent être bonnes à première vue et que le trafic ne passe toujours pas, il faut activer la journalisation (dans les options avancées des règles de filtrage concernées) et vérifier les logs (depuis le menu Status > System Logs - onglet Firewall).

Si les paquets ne semblent pas bloqués mais que le trafic ne passe toujours pas, il est possible que ce soit un problème de routage.

Dernier point à vérifier : la configuration des phases 2. Il est important, pour la configuration des réseaux locaux ou distants, de saisir l'adresse IP du réseau et non l'adresse IP du firewall. Par exemple, si d'un côté, il est configuré 192.168.0.1/24 et de l'autre 192.168.0.0/24, alors il est fort probable que le trafic ne passera pas. Il faut saisir correctement l'adresse du sous-réseau. Soit 192.168.0.0/24.



Certains hôtes du réseau sont joignables, mais pas tous

Lorsque pour un même sous-réseau on arrive à joindre certains hôtes, mais pas tous, alors le problème a très probablement pour origine l'une de ces quatre erreurs de configuration :

Passerelle par défaut manquante, incorrecte ou ignorée

Si la machine concernée n'a pas pour passerelle par défaut le pfSense (ou le firewall portant le lien VPN d'une façon générale), il est probable qu'il y ait une problème de routage sur votre réseau interne. Il faut corriger la passerelle par défaut renseignée sur la machine concernée ou corriger le problème de routage interne à votre réseau local.


Masque de sous-réseau incorrect

Il faut vérifier la configuration du masque de sous-réseau pour les machines concernées. Par exemple, si, sur votre réseau local, vous utilisez le sous-réseau 192.168.1.0/24, mais que l'une des machines est configurée avec une adresse IP fixe (ce qui est une mauvaise pratique ; mieux vaut utiliser l'adressage statique via votre serveur DHCP) avec un mauvais masque de sous-réseau comme, par exemple, 192.168.1.0/16 ; cela ne va pas perturber le fonctionnement sur votre réseau local et par conséquent vous n'allez pas forcément vous en rendre compte. En revanche, si le réseau distant joignable via IPsec est, par exemple, le 192.168.2.0/24, alors il sera injoignable par cette machine car elle croira qu'il fait parti du même sous-réseau (/16) et les paquets ne seront donc pas envoyés vers la gateway.

Si ces notions de masque ou de sous-réseau ne sont pas claires pour vous, nous vous recommandons la lecture, très rapide, de la page Wikipédia "Sous-réseau"


Pare-feu de la machine

S'il y a un pare-feu configuré sur la machine, il est possible qu'il bloque les connexions. Il faut vérifier.


Règles de filtrage sur pfSense

Enfin, il faut vérifier que les règles de filtrage soient bien configurées sur les deux firewall établissant le VPN IPsec.



Perte régulière de la connexion

Historiquement, IPsec peut rencontrer des problèmes avec les paquets fragmentés. C'est de moins en moins le cas aujourd'hui, mais si des pertes de paquets ou de connexions sont rencontrées uniquement sur certains protocoles spécifiques (SMB, RDP, etc.), alors l'activation et la configuration du paramètre MSS clampling (Maximum Segment Size) pour le VPN peut être nécessaire.

Le paramètre MSS clamping peut être activé depuis le menu VPN > IPsec - onglet Advanced Settings.
Cocher la case "Enable Maximum MSS" (se trouvant plutôt en bas de page) et saisir une valeur :

Configurer le paramètre MSS clamping 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.



Déconnexions "aléatoires" du tunnel VPN sur des routeurs peu puissants

Si votre tunnel IPsec tombe régulièrement, puis remonte, et que vous utilisez un mini-PC (du type carte Alix) ou un firewall dont le CPU tourne à 100% de charge, alors vous pouvez rencontrer des problèmes avec le mécanisme de DPD (Dead Peer Detection).
Cela peut se produire lors d'une utilisation élevée de la bande-passante. Dans ce cas, il peut arriver que les paquets DPD ne soient pas envoyés ou que les réponses soient ignorées.
Il n'y a pas 36 solutions, votre firewall n'est pas correctement dimensionné pour votre usage, il faut envisager de le remplacer par un firewall plus puissant.



Le tunnel monte lorsque le firewall initie la connexion, mais pas lorsqu'il répond

Si un tunnel monte uniquement de temps en temps, mais pas tout le temps, c'est qu'il y a sûrement un écart de configuration entre les deux firewall établissant le tunnel IPsec.
Cela peut se produire lorsqu'il y a un écart de niveau de sécurité entre les deux firewall ; celui qui a les paramètres de sécurité les plus forts réussira à initialiser la connexion, mais refusera lorsque c'est l'autre firewall qui sera en initialisation.
Par exemple, si le firewall1 est configuré en mode "Main" pour la négociation d'IKEv1 et que le firewall2 est configuré en mode "Aggressive", alors le tunnel montera lorsque le firewall1 initiera la connexion. En revanche, si c'est le firewall2 qui initie la connexion en mode "Aggressive", alors elle sera refusée par le firewall1.


Nous avons fait le tour des pannes couramment rencontrées lorsque l'on met en place un VPN IPsec.
Un dernier élément à aborder pour être complet est l'analyse des logs. Ce sujet étant très riche, il fera l'objet d'un prochain article dédié.



Pour aller plus loin

[pfSense] Configurer un VPN IPsec site à site
[pfSense] Comprendre et analyser les logs de son VPN IPsec
[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Troubleshooting / Dépannage de ses règles de filtrage


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 :

[pfSense] Configurer un VPN IPsec site à site

icon 11/02/2020 - 5 commentaires

Dans cet article nous traitons de la configuration d'un VPN IPsec entre deux firewall.
La configuration porte sur un firewall pfSense, mais les grandes lignes de configuration sont applicables à tous les équipements du marché supportant IPsec.


1/4. Schéma de mise en œuvre

Nous suivrons la configuration présentée sur le schéma suivant :

Schéma réseau tunnel VPN IPsec pfSense - Provya


Pour le site A :
  • Adresse IP publique : 1.1.1.1
  • Réseau local : 192.168.50.0/24

Pour le site B :
  • Adresse IP publique : 2.2.2.2
  • Réseaux locaux : 192.168.10.0/24 et 192.168.20.0/24

Nous présenterons la configuration pour le site A uniquement. La configuration pour le site B étant facilement déductible à partir de celle du site A.


2/4. Configuration de la Phase 1

Se rendre dans le menu VPN > IPsec

Menu VPN > IPsec - pfSense - Provya


Cliquer sur le bouton "+ Add P1". Les éléments à configurer sont les suivants :

  • Disabled : cocher cette case permet de désactiver la phase 1 du VPN IPsec (et donc de désactiver le VPN IPsec)
  • Key Exchange version : permet de choisir la version du protocole IKE (Internet Key Exchange). Nous choisissons "IKEv2". Si l'autre pair ne support par l'IKEv2 ou si un doute subsiste, il est recommandé de choisir "Auto".
  • Internet Protocol : IPv4 ou IPv6 ; dans notre cas, nous choisissons IPv4
  • Interface : l'interface sur laquelle nous souhaitons monter notre tunnel VPN IPsec. Nous choisissons WAN
  • Remote Gateway : l'adresse IP publique du site distant. Dans notre cas : 2.2.2.2
  • Description : champ facultatif de commentaire (mais que nous conseillons de remplir pour une meilleure lisibilité)
  • Authentication Method : la méthode d'authentification des deux pairs. Deux choix sont possibles : authentification par clé pré-partagée (PSK) ou par certificat (RSA). Le plus simple et le plus courant est de choisir "Mutual PSK" ; ce que nous faisons.
  • My identifier : notre identifiant unique. Par défaut, il s'agit de l'adresse IP publique. Nous laissons donc la valeur "My IP address".
  • Peer identifier : l'identifiant unique de l'autre pair. Par défaut, il s'agit de son adresse IP publique. Nous laissons la valeur "Peer IP address"
  • Pre-Shared Key : la clé pré-partagée. Nous laissons pfSense la générer et cliquons pour cela sur "Generate new Pre-Shared Key". Cette clé pré-partagée devra être saisie sur l'autre firewall lors de sa configuration.
  • Encryption Algorithm : l'algorithme de chiffrement. Si les deux parties supportent l'AES-GCM, nous recommandons l'utilisation d'AES256-GCM ou d'AES128GCM ; ce qui permettra de bénéficier d'un bon niveau de chiffrement et sera compatible avec l'accélération cryptographique offert par AES-NI. Autrement, choisir AES avec une longueur de clé de 256 bits dans l'idéal. Enfin, nous conservons SHA256 pour fonction de hachage et 14 ou 16 pour la valeur du groupe Diffie-Hellman (DH group - utilisé pour l'échange de clés).
  • Lifetime (Seconds) : permet de définir la fréquence de renouvellement de la connexion. La valeur par défaut, 28800 secondes, reste un bon choix
  • Advanced Options : nous laissons les valeurs par défaut

Exemple de résultat obtenu :

Exemple configuration VPN IPsec - Phase 1 - pfSense - Provya


Nous cliquons sur le bouton "Save" pour enregistrer les changements.



3/4. Configuration des Phases 2

Sur la page des tunnels VPN IPsec (sur laquelle vous devez être actuellement), pour notre entrée P1 que nous venons de créer, nous cliquons successivement sur les boutons "Show Phase 2 Entries (0)", puis sur "+ Add P2".

Les éléments à configurer sont les suivants :

  • Disabled : cocher cette case permet de désactiver cette phase 2 du VPN IPsec
  • Mode : nous laissons le mode par défaut "Tunnel IPv4"
  • Local Network : le réseau-local joignable par l'hôte distant sur ce VPN IPsec. Dans notre cas, nous choisissons "LAN subnet".
  • NAT/BINAT translation : si l'on souhaite configurer du NAT sur le tunnel IPsec. Ceci peut être très utile si le plan d'adressage est le même sur les deux sites distants que nous souhaitons interconnecter. Ce n'est pas notre cas dans notre exemple. Nous laissons donc la valeur à "None".
  • Remote Network : l'adresse IP ou le sous-réseau du site distant. Dans notre cas, nous renseignons ici le premier sous-réseau, soit 192.168.10.0/24 ; puis nous créerons une seconde phase 2 en précisant cette fois le second sous-réseau du site distant (192.168.20.0/24).
  • Description : champ facultatif de commentaire (mais que nous conseillons de remplir pour une meilleure lisibilité)
  • Protocol : nous choisissons ESP. AH est rarement utilisé en pratique. Techniquement, le protocole ESP permet de chiffrer l'intégralité des paquets échangés, tandis qu'AH ne travaille que sur l'entête du paque IP sans offrir la confidentialité des données échangées.
  • Encryption Algorithms : Algorithmes de chiffrement. Comme pour la phase 1, si les deux parties supportent l'AES-GCM, nous recommandons l'utilisation d'AES256-GCM ou d'AES128GCM ; ce qui permettra de bénéficier d'un bon niveau de chiffrement et sera compatible avec l'accélération cryptographique offert par AES-NI. Autrement, choisir AES avec une longueur de clé de 256 bits dans l'idéal. Enfin, nous conservons SHA256 pour fonction de hachage et 14 ou 16 pour la valeur du groupe Diffie-Hellman (PFS key group).
  • Lifetime : nous laissons la valeur par défaut, soit 3600 secondes
  • Automatically ping host : une adresse IP à pinguer sur le site distant afin de conserver le tunnel actif. Ce peut être l'adresse IP du firewall sur le site distant par exemple ; nous indiquons 192.168.10.1 dans notre cas.

Exemple de résultat obtenu :

Exemple configuration VPN IPsec - Phase 1 - pfSense - Provya


Nous cliquons sur le bouton "Save" pour sauvegarder notre configuration. Puis nous créeons une nouvelle phase 2 en indiquant cette fois, pour le champ "Remote Network", le second sous-réseau du site B (LAN 2 : 192.168.20.0/24) et choisissons, bien sûr, une adresse IP dans ce sous-réseau pour le champ "Automatically ping host".

Une fois ces configurations effectuées, nous obtenons le résultat suivant :

Exemple de configuration complète d'un tunnel VPN IPsec sous pfSense - Provya


Il ne nous reste plus qu'à cliquer sur le bouton "Apply Changes" pour appliquer nos configurations.

À ce stade, le VPN IPsec doit être monté. Il ne nous reste plus qu'à configurer nos règle de filtrage afin d'autoriser le trafic.



4/4. Règles de filtrage

Il y a au moins deux règles de filtrage à implémenter : celles autorisant le trafic depuis le LAN vers les réseaux du site distant ; et celles autorisant le trafic depuis les deux sous-réseaux du site distant vers le LAN.

Soit, pour l'interface LAN, voici un exemple de règles :

Exemple règles de filtrage du LAN vers le VPN IPsec sous pfSense - Provya



Et pour l'interface IPsec, voici un exemple de règles :

Exemple règles de filtrage du VPN IPsec vers le LAN sous pfSense - Provya



Ces règles sont, en l'état, très permissives. Nous vous recommandons de les affiner afin qu'elles apportent une meilleure sécurité et qu'elles soient en conformité avec votre politique de filtrage.

Dernier élément, si vous avez modifié les options avancées accessibles depuis le menu System > Advanced, onglet Firewall/NAT et que vous avez coché la case "Disable all auto-added VPN rules", alors vous devrez créer des règles de filtrage sur l'interface WAN afin d'autoriser le trafic IPsec avec l'hôte distant. IPsec utilise les ports UDP 500 et 4500, ainsi que le protocole ESP (ou AH, le cas échéant).

La configuration est terminée et doit être fonctionnelle. Pour visualiser les logs associés au VPN IPsec, cela se passe dans le menu Status > System Logs, onglet Firewall.

Dans un autre article nous détaillons quelle procédure suivre pour dépanner et déboguer un tunnel IPsec qui ne fonctionne pas comme voulu.



Pour aller plus loin

[pfSense] Les pannes courantes et leurs solutions sur un VPN IPsec
[pfSense] Comprendre et analyser les logs de son VPN IPsec
[pfSense] Troubleshooting / Dépannage de ses règles de filtrage
[pfSense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense
[pfSense] Monter un accès OpenVPN site-à-site


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 :

[pfSense] Comprendre et analyser ses règles de routage

icon 28/01/2020 - Aucun commentaire

Lorsque l'on essaie de diagnostiquer un problème de routage d'un flux réseau, l'une des premières choses à faire est de vérifier les routes connues par pfSense.

Dans cet article, nous présentons le fonctionnement de la table de routage sous pfSense et les détails à connaître pour un diagnostique efficace.



Visualiser les routes

Pour commencer, si vous n'êtes pas à l'aise avec cette notion de routes ou de table de routage, nous vous conseillons la lecteur du court article Table de routage sur Wikipédia.

Sous pfSense, il y a deux manières de visualiser les routes présentes dans la table de routage : via l'interface graphique ou en ligne de commande.

Pour visualiser la table de routage, nous nous rendons dans le menu Diagnostics > Routes :

Menu Diagnostics > Routes - pfSense - Provya


Le résultat obtenu en ligne de commande est exactement le même que celui obtenu via l'interface graphique. La commande à saisir est :

netstat -rWn

Exemple de résultat obtenu :

table de routage de pfSense - Provya


L'explication du contenu de chaque colonne est le suivant.

Destination

Cette colonne contient l'hôte de destination (désigné par son adresse IP) ou le réseau de destination (désigné par son adresse IP et son masque de sous-réseau associé).

La destination default correspond à la route par défaut du pfSense. C'est vers la passerelle (gateway) associée que seront envoyés les flux destinés à un réseau qui n'est pas directement connu de pfSense.


Gateway

Une passerelle (gateway) est un routeur vers lequel le flux est envoyé afin qu'il soit routé vers une certaine destination. Si la colonne indique un lien comme link#1, alors cela signifie que le réseau est directement joignable sur l'interface du pfSense et qu'aucun routage complémentaire ne sera nécessaire pour acheminer le flux réseau.

Enfin, si c'est une adresse MAC qui est indiquée, cela signifie qu'il s'agit d'un hôte local directement joignable.


Flags

La signification de chaque flag (encore appelé indicateur ou drapeau en français) est la suivante :

  • 1 (RTF_PROTO1) : routage spécifique au protocole flag #1
  • 2 (RTF_PROTO2) : routage spécifique au protocole flag #2
  • 3 (RTF_PROTO3) : routage spécifique au protocole flag #3
  • B (RTF_BLACKHOLE) : suppression des paquets lors des mises à jour
  • b (RTF_BROADCAST) : représente une adresse de broadcast
  • D (RTF_DYNAMIC) : créée dynamiquement par redirection
  • G (RTF_GATEWAY) : la destination est joignable via une gatway
  • H (RTF_HOST) : entrée spécifique à un hôte (ou un réseau)
  • L (RTF_LLINFO) : protocole de validation pour la translation d'adresse physique (ex : pour arp)
  • M (RTF_MODIFIED) : modifiée dynamiquement par redirection
  • R (RTF_REJECT) : hôte ou réseau injoignable
  • S (RTF_STATIC) : entrée ajoutée manuellement
  • U (RTF_UP) : route utilisable
  • X (RTF_XRESOLVE) : un processus externe prend en charge la translation d'adresse physique

Par exemple, une route disposant des flags UGS signifie qu'elle est utilisable (U), que les paquets sont envoyés à une passerelle (G) et qu'elle a été ajoutée manuellement (S).


Use

Cette colonne est une compteur représentant le nombre total de paquets qui ont été envoyés via cette route. C'est très utile pour déterminer si une route est actuellement utilisée ; si c'est le cas, le nombre va continuer à s'incrémenter au fur et à mesure que des paquets réseaux passent par cette route.


MTU


La MTU configurée pour cette route.


Netif

L'interface réseau utilisée pour cette route (ex : igb0 ; igb1.10 ; ovpns1 ; ...).


Expire


Ce champ ne concerne que les entrées dynamiques. Il indique le délai au bout duquel la route va expirer si elle n'est plus utilisée.



Utiliser la commande traceroute

L'utilitaire traceroute est très pratique pour vérifier la bonne configuration de ses routes, notamment dans un environnement multi-WAN. Cet utilitaire présente le cheminement d'un flux réseau de routeur en routeur jusqu'à sa destination.

Sous pfSense, un traceroute peut être effectué depuis le menu Diagnostics > Traceroute :

menu Diagnostics > Traceroute - pfSense - Provya


Pour davantage d'informations sur le fonctionnement de cet utilitaire, vous pouvez lire le chapitre Fonctionnement de l'utilitaire traceroute sur Wikipédia.

Utilisé depuis son ordinateur (commande tracert sous les systèmes Windows) ou depuis pfSense, traceroute permettra de s'assurer qu'un flux réseau est dirigé vers la bonne gateway (le cas échéant, vers la bonne interface pour un environnement multi-WAN).



Routes et VPN

En fonction du type de VPN utilisé, une route peut être présente ou non dans la table de routage de pfSense. Par défaut, IPsec n'utilise pas la table de routage. IPsec maintient sa propre table de routage avec des entrées SPD (security policy database). Ainsi, la configuration manuelle d'une route statique sous pfSense ne permettra jamais de rediriger du trafic à travers un tunnel VPN IPsec. Il faut bien avoir cet élément en tête dans la configuration de sa stratégie de routage et dans la configuration de son tunnel VPN IPsec.

OpenVPN, quant à lui, utilise la table de routage de pfSense (pour être exact, il s'agit en fait de la table de routage de FreeBSD). Ainsi les réseaux joignables via un lien OpenVPN seront visualisables dans la table de routage.

De la même manière, il faut garder en tête que contrairement à OpenVPN, un tunnel IPsec lui-même n'a pas d'adresse IP. Ainsi, lors d'un traceroute, un timeout sera affiché pour le saut correspondant au tunnel IPsec.



Pour aller plus loin

[pfSense] Troubleshooting / Dépannage de ses règles de filtrage
[pfSense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense
[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Configurer un VPN IPsec site à site


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 :

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

icon 26/11/2019 - 2 commentaires

Vous avez peut-être déjà rencontré des problèmes de grosses lenteurs d'accès au dashboard de pfSense ?
Nous aussi !

Ces lenteurs apparaissent lorsque pfSense n'arrive plus à se connecter à Internet ou, pour être plus précis, n'arrive plus à joindre un serveur de Netgate.

Nous avons cherché à comprendre le problème et à le corriger. En parallèle de ce travail, nous avons constaté que cette anomalie avait déjà été rapportée et qu'un ticket était ouvert sur le redmine de pfSense.
Nous pensions initialement que le problème serait corrigé rapidement. Mais comme ce n'est visiblement pas le cas, nous avons pensé qu'il pouvait être utile de partager la solution de contournement et d'en profiter pour présenter la méthodologie d'analyse que nous avons suivie.

Dans cet article, nous partageons la méthodologie d'analyse suivie afin de comprendre l'origine du problème rencontré et, bien-sûr, trouver la solution au problème.



1. Le problème : le tableau de bord est lent lorsque pfSense n'a plus accès à Internet

Le contexte est généralement le suivant : vous disposez d'une interface WAN active, mais non-connectée à Internet.
Les raisons à ce type de situations sont nombreuses : perte de la connexion Internet, serveurs DNS inaccessibles, règles d'Outbound NAT mal configurées, cas où pfSense est configuré en tant que firewall de cœur de réseau n'ayant pas vocation à avoir accès à Internet, etc.

Mais le problème peut également survenir alors que votre connexion Internet est parfaitement fonctionnelle.

Le problème : l'interface d'administration de pfSense semble devenir très lente uniquement sur certaines pages. Et notamment lors de l'accès au tableau de bord (c'est-à-dire la page principale, le Dashboard). La page met alors une bonne minute à se charger. Seule cette page serait concernée par ce phénomène de lenteur à l'affichage. Mais, en pratique, d'autres pages sont également concernées lorsque l'on effectue une modification (lorsque l'on fait une modification quelconque depuis la page System > General Setup, par exemple).

La version de pfSense concernée : 2.4.4

Note : il semblerait que le problème ne soit présent que si votre interface WAN est configurée avec une adresse IP fixe.

Note 2 : pour être précis, en fait le problème ne se produit pas lorsque pfSense n'a plus accès à Internet, mais lorsque pfSense n'arrive pas à joindre un serveur hébergé chez Netgate (l'éditeur du logiciel pfSense).

tl;dr : dans la section suivante, nous partageons la méthodologie d'analyse que nous avons suivie pour trouver l'origine du problème. Si vous le souhaitez, vous pouvez vous rendre directement à la dernière section "3. Solution" si vous souhaitez connaître le problème exact et la solution de contournement proposée.



2. Méthodologie d'analyse

Nous avons appliqué une méthodologie visant à cibler la source exacte du problème et avons suivi les étapes ci-dessous :

2.1. Serait-ce un widget qui n'arrive pas à se charger ?

Nous avons d'abord pensé que la source du problème était un widget présent sur la page d'accueil qui faisant une requête vers un serveur web externe qui était inaccessible (la suite nous montrera que nous avions vu juste...).
La première étape de la démarche de recherche a donc consisté à faire le tour des différents widgets présents sur la page d'accueil et à les supprimer les uns après les autres afin de voir si une amélioration était constatée.

Dashboard vide de pfSense - Provya

Difficile d'avoir un dashboard plus épuré...


=> Résultat obtenu : aucune amélioration. Même sans aucun widget sur le dashboard, le problème est toujours présent. Le problème semble donc, à première vue, ne pas venir d'un widget en particulier.


2.2. Serait-ce lié aux serveurs DNS ?

Nous avons ensuite soupçonné un problème de résolution DNS (le délai d'environ une minute avant que la page ne se charge ressemblait fortement à un délai de timeout).
Nous avions toujours dans l'idée que le problème pouvait être lié à un serveur web externe inaccessible.
Nous avons donc essayé de modifier ou de supprimer les serveur DNS renseignés sur l'interface d'administration du pfSense (menu System > General Setup). Peut-être étaient-ils à l'origine de cette lenteur.

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

Même sans serveur DNS de configuré, le résultat est toujours le même


=> Résultat obtenu : aucune amélioration.


2.3. Désactivons l'interface WAN !

Nous avons alors essayé de désactiver l'interface WAN. Nous nous rendons pour cela dans le menu Interfaces > Wan, et nous décochons la case "Enable interface".

Désactiver l'interface WAN sous pfSense - Provya



=> Résultat obtenu : ça marche ! Il n'y a plus aucune lenteur !

Il semble donc que ce soit lié au fait que l'interface WAN soit active, mais déconnectée, ou tout du moins que le problème se produit lorsque l'interface WAN est active et n'arrive pas à joindre un serveur web externe. À noter, pour être exact, que la suite de nos tests nous a permis de constater que c'est précisément lorsque l'interface WAN est à l'état "UP" que le problème peut survenir.

À ce stade nous avons compris (au moins partiellement) quelle était la configuration à l'origine du problème. Problème qui devient donc maintenant reproductible.
En revanche, nous ne savons toujours pas quelle est la cause. Que se passe-t-il exactement ? Pourquoi le fait de perdre son accès à Internet entraîne une lenteur uniquement sur la page principale (Dashboard) ?
Dégainons notre meilleure arme pour essayer de comprendre ce qu'il se passe : faire une capture réseau et analyser !


2.4. Lançons un tcpdump sur l'interface WAN

Nous réactivons l'interface WAN et nous laçons une commande tcpdump sur celle-ci. Cette commande peut être exécutée depuis le menu Diagnostics > Packet Capture.

Nous utilisons Wireshark pour analyser nos paquets capturés.

Extrait capture tcpdump depuis wireshark - bug pfSense - Provya

Requête DNS pour l'enregistrement ews.netgate.com


Sur la capture d'écran, nous constatons qu'il y a une requête DNS pour un domaine particulier : ews.netgate.com

Pour les plus curieux, la série de requêtes ICMP visible sur la capture d'écran correspond à la supervision de sa passerelle par défaut (10.10.10.1) par pfSense (10.10.10.10).

Nous avons alors ajouté une entrée DNS statique sur pfSense afin que le domaine ews.netgate.com soit résolu par une adresse IP locale (127.0.0.1 ou 0.0.0.0) et, bingo plus aucune lenteur ! (Nous expliquons dans le dernier paragraphe comment reproduire cette solution).

À ce stade, nous avons l'élément à l'origine du problème de lenteur. Il reste à déterminer pourquoi pfSense demande à son serveur DNS de résoudre le domaine ews.netgate.com et pourquoi lorsque cette résolution n'aboutit pas ou que le serveur ews.netgate.com est injoignable, le chargement du tableau de bord est ralenti.

Bonne nouvelle, pfSense est open-source ! Nous allons donc pouvoir étudier le code source pour comprendre quelles pages font appel à ce domaine et que cherchent-elles à récupérer sur ce domaine.


2.5. Analyse du code source

Le code source de pfSense est accessible sur le site GitHub : https://github.com/pfsense/pfsense.

Une recherche sur le nom de domaine ews.netgate.com sur le dépôt pfSense nous permet de comprendre pourquoi une requête est effectuée vers ce nom de domaine :

Recherche bug pfSense sous GitHub - Provya


Lorsque l'on charge la page d'accueil (index.php), si le fichier copyright n'existe pas où qu'il n'a pas été mis à jour depuis au moins 24 heures, pfSense cherche à le télécharger via https://ews.negate.com/copyright.

Le code est ainsi fait (requête cURL en PHP) que cette requête est bloquante pour le chargement du reste de la page.

Un rapport de bug a été rédigé. Il est consultable ici : https://redmine.pfsense.org/issues/8987. La solution n'est pas triviale. Si vous avez une idée de solution et que vous souhaitez contribuer, vous savez ce qu'il vous reste à faire... ;-)



3. Solution

Pour résumer, le problème est le suivant : depuis pfSense 2.4.4, lorsque l'on charge la page d'accueil (index.php), si le fichier copyright n'existe pas où qu'il a pas été mis à jour depuis plus de 24 heures, pfSense cherche à le télécharger via https://ews.negate.com/copyright.

Si lors de cette mise à jour, pfSense n'arrive pas à joindre le serveur ews.netgate.com, alors le chargement de la page est bloquée jusqu'au timeout DNS (d'environ 60 secondes) de la requête de résolution de nom.

Un rapport de bug a été rédigé. Il est consultable ici : https://redmine.pfsense.org/issues/8987. La solution n'est pas triviale. Si vous avez une idée de solution et que vous souhaitez contribuer, vous savez ce qu'il vous reste à faire... ;-)

Le nom de domaine ews.netgate.com est utilisé pour trois choses :

  • télécharger la licence applicable à pfSense
  • télécharger les informations liées au Support
  • rechercher les mises à jour disponibles

Aussi, une solution de contournement que nous proposons (nous en proposons également deux autres en fin d'article) est d'ajouter une entrée DNS pour le domaine ews.netgate.com sur le résolveur de pfSense afin qu'il pointe vers son adresse IP de localhost.

Pour cela, se rendre dans le menu Services > DNS Resolver :

Menu Services > DNS Resolver sous pfSense - Provya


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

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


Les champs à compléter sont les suivants :

  • Host : le nom de l'hôte, sans la partie domaine. Soit, dans notre cas : ews
  • Domain : le domaine parent de l'hôte. Soit, dans notre cas : netgate.com
  • IP Address : l'adresse IP correspondante. Dans notre cas : 127.0.0.1
  • Description : une description facultative

Exemple de résultat obtenu :

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


Nous cliquons sur "Save", puis "Apply Changes" pour valider nos changements.

Attention : comme le fait très justement remarqué Albirew en commentaire, en procédant ainsi, nous bloquons également les recherches de mises à jour par pfSense. En effet, pfSense recherche les mises à jour en effectuant une requête vers https://ews.netgate.com/pfupdate.

La solution proposée est donc bien une solution de contournement temporaire. Ce n'est pas une solution idéale.

Deux autres solutions moins impactantes sont également possibles :

1. Modifier le code source du fichier index.php pour supprimer la recherche liée à la licence (il suffit de commenter la ligne « require_once("copyget.inc"); » (ligne 469) du fichier « /usr/local/www/index.php »).

2. Ajouter une tâche cron mettant à jour le fichier « /cf/conf/copyright » (ex : « touch /cf/conf/copyright ») exécutée toutes les 20 heures, par exemple. Merci à Albirew pour cette proposition.


Voilà, vous ne devriez plus rencontrer ce problème de lenteur lors du chargement du tableau de bord de pfSense lorsque le serveur ews.netgate.com est inaccessible !



Pour aller plus loin

[pfSense] Troubleshooting / Dépannage de ses règles de filtrage
[pfSense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense
[pfSense] Gardez son firewall toujours à l'heure avec une puce GPS


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

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


           

store.provya.fr

icon Tags de l'article :

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

icon 19/11/2019 - 4 commentaires

Comprendre l'ordre dans lequel les règles de NAT et de filtrage sont appliquées est important lorsque l'on configure son firewall.

Dans cet article nous détaillons l'ordre dans lequel pfSense applique ses règles de filtrage, de translation de port et de NAT et l'impact que cela a sur l'écriture de nos règles.



1. L'ordre de traitement - schéma global

Un bon schéma étant souvent plus parlant qu'un long texte, l'ordre de traitement des paquets réseaux par pfSense peut se résumer par le schéma suivant :

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


Ce schéma de fonctionnement présente le cheminement suivi pour le trafic sortant (quittant le réseau local à destination d'Internet) et pour le trafic entrant (depuis Internet vers le réseau local ou une DMZ). Le cheminement est exactement le même dans les deux sens.

Pour chacune des étapes, si aucune règle n'existe, alors celle-ci sera simplement ignorée et pfSense passera à la suivante.

Prenons le cas d'un paquet réseau quittant le LAN à destination d'Internet. En suivant les numéros présents sur notre schéma, l'ordre de traitement détaillé est le suivant :

  1. tcpdump : réalisé sur l'interface LAN (accessible via l'outil "Packet Capture" du menu "Diagnostics" de pfSense). Lorsque la capture est effectuée sur l'interface LAN (pour un paquet quittant le LAN à destination d'Internet), aucun traitement n'a encore été effectué par pfSense (NAT, filtrage, routage, etc.). Nous capturons donc le paquet "brut" tel qu'il est émis par l'ordinateur. Le détail du fonctionnement de l'outil Packet Capture fera l'objet d'un prochain article.
  2. Port forward ou 1:1 NAT configurés sur l'interface LAN. On configure rarement des règles de redirection de ports (port forward) ou de NAT 1 pour 1 (1:1 NAT) sur l'interface LAN, mais nous rencontrerons des règles de NAT équivalentes lorsque nous utilisons un proxy ou des redirecteurs DNS. Dans ces cas-là, on parle également de "DNAT" pour Destination NAT ; c'est-à-dire des règles de NAT qui s'appliquent par rapport à l'adresse IP de destination.
  3. Règles de filtrage configurées pour l'interface LAN. Les règles de filtrage sont appliquées dans l'ordre suivant : règles de floating, règles de groupe d'interfaces, puis finalement les règles de l'interface elle-même.
  4. 1:1 NAT ou règles d'Outbound NAT configurés sur l'interface WAN. Dans ce cas-là, on parle de "SNAT" pour Source NAT ; c'est-à-dire des règles de NAT qui s'appliquent par rapport à l'adresse IP source. C'est à cette étape que le paquet réseau prend comme adresse IP source l'adresse IP de l'interface WAN de pfSense.
  5. Règles de filtrage de type floating dans le sens "out" pour l'interface WAN. C'est un cas très spécifique. Pour un usage de base, c'est rarement utilisé. Ces règles de floating peuvent être très utiles lorsque l'on souhaite configurer de la priorisation de trafic sur un environnement multi-VLAN. Il faut garder en tête qu'à cette étape, le NAT sortant (Outbound NAT) a déjà été appliqué et que les adresses IP source des paquets ne sont donc plus les adresses IP privées du LAN, mais l'adresse IP de l'interface WAN (ou celle qui a été configurée dans les règles d'Outbound NAT).
  6. tcpdump : réalisé sur l'interface WAN. À ce stade, tous les traitements ont été effectués par pfSense (NAT, filtrage, routage, etc.). Nous capturons donc le paquet tel qu'il est transmis vers Internet (ou vers le routeur de l'opérateur, par exemple)

L'outil tcpdump est toujours le premier et le dernier à voir le trafic, en fonction de l'interface sur laquelle il est effectué et de la direction du trafic.
Ainsi, dans le cas d'un trafic du LAN vers le WAN, un tcpdump exécuté sur l'interface LAN verra les paquets réseaux tel qu'ils sont émis par l'ordinateur
Un tcpdump exécuté sur l'interface WAN verra les paquets modifiés par pfSense tel qu'ils sont transmis en sortie de pfSense.
Il s'agit donc d'un outil de diagnostique très pratique dans le suivi de l'acheminement et du traitement des paquets réseaux.

Nous avons pris dans notre exemple le cas d'une architecture simple avec une interface LAN et une interface WAN. Le principe de fonctionnement est exactement le même sur une architecture disposant d'un plus grand nombre d'interfaces réseaux. Les étapes suivies seront toujours les mêmes.



2. Impact sur la configuration de ses règles

Ainsi, pour une interface donnée, les règles de NAT s'appliquent toujours avant les règles de filtrage. C'est la raison pour laquelle il faut adapter ses règles de filtrage avec les bonnes adresses IP sources/destinations.

Prenons un exemple : nous souhaitons rediriger le trafic arrivant sur le port 80 de l'adresse IP publique de notre firewall vers le port 80 d'un serveur local. Le schéma réseau ressemble à celui-ci :

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


Dans cet exemple, nous allons créer une règle de redirection de port (port forward) depuis le menu Firewall > NAT, puis onglet Port Forward (onglet par défaut) :

Menu Firewall > NAT - Port Forward - pfSense - Provya


Nous cliquons sur le bouton "Add" ; les champs à compléter sont les suivants :

  • Disabled : permet de désactiver la règle sans la supprimer. Nous laissons cette case décochée.
  • No RDR (NOT) : permet de désactiver la redirection pour le trafic correspondant à cette règle. Cette option sera très peu utilisée dans la pratique. On préférera filtrer/affiner nos règles de redirection via des règles de filtrage.
  • Interface : l'interface d'arrivée des paquets. Dans notre exemple, il s'agit de l'interface WAN.
  • Protocol : le protocole concerné. Dans notre exemple, nous choisissons TCP.
  • Source : il est rarement nécessaire de préciser la source sur une redirection de port pour du trafic entrant. Nous laissons ces champs vides.
  • Destination : l'adresse IP de destination sur laquelle le trafic externe arrive. Soit, dans notre cas, l'adresse IP de notre WAN. Nous choisissons donc "WAN Address".
  • Destination port range : le port réseau de destination. Dans notre cas, nous souhaitons rediriger le trafic arrivant sur le port 80. Nous pouvons ainsi choisir "HTTP" dans la liste déroulante ou choisir "Other" et indiquer 80 dans le champ Custom.
  • Redirect target IP : il s'agit de l'adresse IP privée vers laquelle nous souhaitons rediriger le trafic. Dans notre exemple : 192.168.1.10.
  • Redirect target port : le port d'écoute de la machine locale. Il s'agit généralement du même port que celui indiqué précédemment. Dans notre cas "HTTP".
  • Description : un champs purement informatif.
  • No XMLRPC Sync : cocher cette case pour ne pas synchroniser cette règle vers les autres membres CARP.
  • NAT reflection : il s'agit d'un mode avancé permettant à un client interne d'accéder à une ressource interne en passant par son adresse IP externe. Notre exemple ne porte pas sur cet usage, nous laissons la valeur par défaut, "Use system default", ce qui revient à choisir "Disable".
  • Filter rule association : cette option permet de laisser pfSense générer la règle de filtrage nécessaire pour le fonctionnement de notre redirection de port. Pour un utilisateur avancé, nous recommandons de choisir "None" et de configurer par soi-même la règle de filtrage afin d'être certains de la positionner là où on le souhaite parmi nos autres règles et de pouvoir la personnaliser si nécessaire. Par simplicité, pour notre exemple, nous laissons le choix par défaut "Add associated filter rule".

Exemple de résultat obtenu :

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


Sur notre interface WAN, une règle a été créée (si nous avons choisi "None" pour l'option Filter rule association, alors il faut créer soi-même cette règle) :

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


Nous constatons que l'adresse IP Destination de notre règle de filtrage est l'adresse IP privée (ici, 192.168.1.10). La raison est que le NAT est appliqué avant le filtrage. Ainsi, l'adresse IP de destination du paquet réseau a été modifiée par le firewall et correspond à ce stade à l'adresse IP privée de destination. Le filtrage doit donc bien porter sur l'adresse IP privée de destination.

Il nous reste à penser à cliquer sur "Apply Changes" aussi bien sur la page de gestion des règles de filtrage que sur celle de gestion des règles de NAT.
La redirection de port est en place.

Voila, vous savez maintenant parfaitement l'ordre que suit pfSense pour le traitement des paquets réseaux (NAT, filtrage, routage, etc.).
Nous verrons dans un prochain article la puissante de l'outil "packet capture" intégré à pfSense et la méthodologie d'utilisation que nous proposons pour faire ses analyses réseau.



Pour aller plus loin

[pfSense] Troubleshooting / Dépannage de ses règles de filtrage
Best practices / Recommandations pour la configuration de votre firewall
[pfSense] Gardez son firewall toujours à l'heure avec une puce GPS


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

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


           

store.provya.fr

icon Tags de l'article :

[pfSense] Tout comprendre aux alias

icon 05/11/2019 - Aucun commentaire

Sous pfSense, et sous la plupart des firewall modernes, il est possible de définir des alias. Ces alias nous seront utiles dans l'implémentation de nos règles de filtrage, de NAT, de redirection de ports, etc.
C'est un outil pratique qui permet de gagner en lisibilité sur nos règles.



Qu'est-ce qu'un alias ?

Sous pfSense, un alias permet de définir un groupe de ports réseaux, d'hôtes ou de sous-réseaux.
Ces alias peuvent ensuite être utilisés dans les règles de filtrage, les règles de redirection de ports, les règles de NAT, etc. Utiliser des alias est une bonne pratique pour disposer de règles claires, courtes, simples et lisibles sur notre firewall.

Il est à noter que certains firewall obligent en la création d'alias pour l'écriture des règles de filtrage (il est impossible de spécifier une adresse IP, il faut avoir préalablement créé un alias contenant cette adresse IP). pfSense n'impose pas ce mode de fonctionnement strict.



Les différents types d'alias

Les alias sont configurables depuis le menu Firewall > Aliases :

Menu Firewall > Aliases - pfSense - Provya


Il existe cinq catégories d'alias.


Host

Ce type d'alias peut contenir des adresses IP seules et des noms d'hôtes (hostname). Ces alias s'ajoutent depuis l'onglet "IP".

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


Lorsque l'on renseigne un nom de domaine, pfSense va le résoudre à intervalle régulier. Par défaut, la fréquence de mise à jour est de 5 minutes. Il est possible de modifier cette fréquence depuis le menu System > Advanced, onglet Firewall & NAT. Il faut personnaliser la valeur du champ "Aliases Hostnames Resolve Interval" :

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




Network

Ce type d'alias peut contenir des sous-réseaux en notation CIDR, des noms d'hôtes, des plages d'adresses IP ou des adresses IP seules.
Il est également possible de renseigner un intervalle d'adresses IP. Par exemple : 192.168.0.10-192.168.0.30. Il faut laisser le masque sur /32.
Cet intervalle sera traduit en autant de sous-réseaux nécessaires au format CIDR.

Par exemple, si l'on renseigne l'intervalle 10.3.0.100-10.3.0.200 :

Exemple intervalle adresses IP alias - pfSense - Provya


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

Exemple intervalle adresses IP alias - pfSense - Provya




Port

Ce type d'alias peut contenir une liste de ports réseaux ou une plage de ports réseaux pour TCP et UDP.

Le protocole (TCP, UDP) n'est pas renseigné dans l'alias. Il faudra le préciser (TCP, UDP ou les deux) dans les règles de filtrage ou de NAT qui feront appel à cet alias.



URL

Cet alias est construit à partir du fichier fourni par l'URL indiquée. Attention, ce fichier n'est lu qu'une seule fois lors de la création de l'alias. Il n'est ensuite pas mis à jour automatiquement.
Le fichier doit être au format txt et contenir une information par ligne (une adresse IP par ligne, par exemple).

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


Chaque URL peut pointer vers un fichier disposant de 3 000 entrées maximum.



URL Table

Cet alias est construit à partir du fichier fourni par l'URL indiquée. Cet alias est mis à jour automatiquement en retournant chercher le fichier fourni par l'URL indiquée. La fréquence de mise à jour se défini en nombre de jours.

Contrairement aux alias de type "URL", il n'y a pas de limite au nombre d'entrées pour chaque fichier (il peut en contenir plusieurs dizaines de milliers).

Techniquement, le package pfBlocker utilise ce type d'alias pour la gestion de ses listes d'adresses IP par pays, par exemple.

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


Sur la capture d'écran ci-dessus, l'alias est configuré pour être mis à jour tous les 3 jours.



Fonctionnalités avancées sur les alias

Imbrication d'alias

Il est possible d'imbriquer un alias dans un autre alias à condition que les deux alias soient du même type.

Par exemple, si l'on créé un alias "web_server" contenant l'adresse de notre serveur web, un alias "smtp_server" contenant l'adresse de notre serveur SMTP, il est possible de créer un troisième alias contenant les deux alias précédents :

Imbrication d'alias sous pfSense - Provya


Sur la capture d'écran ci-dessus, l'alias "all_servers" contient les deux alias "web_server" et "smtp_server".



Utilisation des noms d'hôtes dans des alias

Des noms d'hôtes peuvent être utilisés dans des alias. Chaque nom d'hôte sera résolu périodiquement par pfSense pour vérifier son adresse IP correspondante. Si un nom d'hôte dispose de plusieurs adresses IP, alors toutes les adresses IP seront ajoutées à l'alias.

Attention, cette option n'est pas efficace si nous cherchons à autoriser ou interdire l'accès à un site web en particulier (comme par exemple facebook.com). Ces gros sites web disposent bien souvent de mécanismes de répartition de charge par round-robin DNS, ce qui ne permet pas de garantir que pfSense disposera de la totalité des adresses IP associées au nom de domaine concerné.
Cette solution peut donc fonctionner pour des petits sites web, mais pas pour les plus gros.


Alias et IPv6

pfSense supporte pleinement IPv6. Il en est logiquement de même pour les alias.
Il est également possible de mixer la présence d'adresses IPv4 et IPv6 au sein d'un même alias.



Taille maximale des alias

Il n'existe pas de taille maximale théorique. Il faut simplement s'assurer de deux éléments :
1. Être sûrs que la taille des alias n'excède pas la moitié du nombre maximum d'entrées dans la table du firewall (qui est de 200 000, par défaut).
2. Disposer de suffisamment de mémoire-vive sur son firewall. Grosso-modo, en prenant de la marge, il faut compter 1K par entrée.



Utilisation des alias

Les alias peuvent s'utiliser dans les règles de filtrage et de NAT. Ils peuvent être saisis à la place d'une adresse IP ou d'un nom d'hôte.

Par exemple, dans la création de votre règle de filtrage, choisir, pour source ou destination, "Single host or alias" et renseigner le nom de l'alias :

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


On peut voir sur la capture d'écran ci-dessus que pfSense propose une aide à la saisie par auto-complétion.

Une fois la règle de filtrage saisie, il est possible de visualiser le contenu de l'alias en positionnant le curseur de la souris dessus :

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



Voilà ! Vous connaissez tout ce qu'il faut savoir sur la gestion des alias sous pfSense.



Pour aller plus loin

Best practices / Recommandations pour la configuration de votre firewall


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

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


           

store.provya.fr

icon Tags de l'article :