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.
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" :
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".
Une fois le tunnel créé, nous disposons de toutes les informations nécessaires pour créer notre interface IPv6 sur notre pfSense :
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 :
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 :
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" :
Vérifier que la ligne "Allow IPv6" soit bien cochée, puis cliquer sur "Save".
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 :
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 :
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" :
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 :
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" :
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 :
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 :
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 :
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 :
À ce stade, tout doit fonctionner. On peut tester !
Plusieurs sites permettent de tester sa connectivité. LaFibre.info : ip.lafibre.info/
Test-IPv6.com : test-ipv6.com
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.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : IPv6pfSense
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 :
En cas de connexion réussie :
Connexion TCP réussie
En cas d'échec :
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 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 :
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.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : debugNATpfSense
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.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : mise à jour pfSensepfSense
English version: [pfSense] Local user management
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 :
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é.
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é.
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 :
- Que le groupe existe sur le serveur d'authentification distant.
- Que le même groupe (avec le même nom) existe en local sur le firewall.
- 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.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : pfSense
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 :
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 :
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 :
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" :
Puis pour le champ Schedule, choisir le calendrier créé précédemment :
Exemple de résultat obtenu :
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.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : pfSense
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.
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 :
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 :
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
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 :
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
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.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : openVPNpfSense
English version: pfSense 2.4.5 now available
Jeudi 26 mars 2020 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
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.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : mise à jour pfSensepfSense
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 :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
Extrait des logs pour le répondant :
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 :
Extrait des logs pour le répondant :
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 :
Extrait des logs pour le répondant :
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
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.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : IPsecpfSenseVPN
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 IPsec 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é :
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 :
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 IPsec 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 :
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
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.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : IPsecpfSensesécuritéVPN
English version: [pfSense] Configuring a Site-to-Site IPsec VPN
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 :
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
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 :
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 :
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 :
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 :
Et pour l'interface IPsec, voici un exemple de règles :
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] Monter un VPN IPsec natté (Overlap network)
[pfSense] Les pannes courantes et leurs solutions sur un VPN IPsec
[pfSense] Comprendre et analyser les logs de son VPN IPsec
[pfSense] Monter un accès OpenVPN site-à-site
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.
Retrouvez nos services et firewall pour pfSense
store.provya.fr
Tags de l'article : IPsecpfSensesécuritéVPN
08/09/2020 - 4 commentaires
