• Sécurité
• Gestion des VLANs
• Remplacer les edge comme points d'entrée vers le réseau privé de Neutrinet. Les edges doivent seulement être des routeurs pour faire le lien avec Verixi (routage, informations BGP).

  NB : Avant la mise en place des pfSense : les edge servent de routeurs mais sont aussi le point d'entrée pour accéder au proxmox et aux iLO. Cela ne devrait pas être le cas sur ces routeurs car ils sont trop exposés.

• Facilité de gestion via une interface web (plus facile / accessible que du nftable/iptable)
• Possibilité d'ordonner les règles du pare-feu avec des séparateurs pour rendre la configuration plus lisible
• Possibilité d'avoir des alias (pour représenter des réseaux IP, des ports, des réseaux uniques ou encore des URL). Les alias permettent de regrouper des éléments, d'éviter de recopier plusieurs fois les mêmes données et de mieux qualifier les éléments (le texte est plus compréhensible qu'une IP)
• En cas de conflit d'IP dû au reste d'une ancienne configuration, on a un message de pfSense qui prévient de modifier d'abord l'ancienne configuration pour éviter les problèmes.
• PfSense fonctionne bien dans Proxmox

Pourquoi pfSense plutôt qu'OPNsense ?

OPNsense est basé sur un fork de FreeBSD (HardenedBSD) et dispose d'un framework plus à jour mais qui est mal supporté par Proxmox. Par ailleurs, Tharyrok relève aussi avoir déjà observé des comportements étranges qu'il n'a jamais observés sur pfSense, par exemple un résolveur DNS qui plantait à intervalles réguliers en Ipv6.

D'un point de vue personnel de Tharyrok, l'interface web est moins intuitive aussi.

Par convention, les machines virtuelles du Proxmox qui sont numérotées entre 100 et 199 ne peuvent pas être migrées d'un serveur physique à un autre : ce sont des machines qui cassent la configuraiton réseau si elles étaient déplacées car elles sont liées à une interface réseau physique de la machine (dans l'infra de Neutrinet, c'est le cas des edge et des futurs pfSense).

Les VM seront numérotées 121 et 122, pour indiquer une différence d'équipement avec les machines edges qui ont les numéros 111 et 112.

Elles porteront comme nom de domaine : pfsense-01.blue.neutri.net et pfsense-02.blue.neutri.net

Résumé de la config des machines :

• OS : other (pour du BSD)
• 4 coeurs - (c'est déjà beaucoup, mais les proxmox ont 32 coeurs)
• 2 GB RAM
• 10 GB HDD - en local, pas sur le CEPH
• openvswitch pour utiliser les VLANS (pas de précision pour le moment sur les VLAN pour que pfSense ait accès à toute l'interface)
• VirtlO pour un accès direct au matériel

Pour récupérer l'ISO de pfSense, on peut le charger depuis notre ordinateur dans Proxmox mais il est préférable (rapidité) de récupérer le lien de téléchargement de l'ISO sur le site de pfSense puis de se rendre dans /var/lib/vz/templates/iso de pfSense (le dossier par défaut pour les ISO) pour y télécharger directement l'ISO avec wget puis le décompresser avec gzip.

On boot la VM sur l'ISO et on choisit l'installation normale (en cas de réinstallation, possbilité de récupérer une confg existante, voir ci-dessous).

• Choix du clavier : clavier belge car il est nécessaire de taper quelques commandes même si tout se fait par la suite par l'interface graphique.
• Pour le partitionnement, Tharyrok préfère utiliser ZFS car il a déjà eu des problèmes avec UFS (dans certains cas où le pfSense avait mal été éteint, les fichiers étaient corrompus).
• On choisit mode Stripe (pas de RAID).
• On débute l'installation.

A la fin de l'installation, ne pas oublier de retirer l'ISO.

Lorsque pfSense se lance, on accepte les VLANs.

Au moment de l'installation le 28 novembre 2020, on a travaillé avec 4 VLANs :

• Le VLAN 10 “ Management ” : VLAN qui contient temporairement les Proxmox, Ceph, les iLo et les Edge.
• Le VLAN 20 “Patata” : VLAN sur lequel se connecteront les machines virtuelles.
• Le VLAN 25 “Interco” : VLAN spécifique entre les pfSense pour leur synchronisation et la HA (voir ci-dessous)
• Le VLAN 40 “Neutrinet” : VLAN avec les IP publiques de Neutrinet

La première chose à faire est d'assigner les VLANs aux différentes interfaces.

On a plusieurs possibilités, soit configurer tous les VLANs en ligne de commande, soit renseigner en ligne de commande le VLAN dont on a besoin pour accéder à l'interface du proxmox et assigner les autres VLAN depuis l'interface web.

Ajout de VLAN sur l'interface vtnet0 :

VLAN Capable interfaces :
vtnet0 [adresse mac] (up)
Enter the parent interface name for the new VLAN (or nothing if finish) : vtnet0
Enter the VLAN tag (1-4094) :10

Une fois tous les VLAN souhaités créés, on assigne les interfaces :

Enter the WAN interface name or "a" for auto-detection (vtnet0, vtnet0.10, vtnet0.20, vtnet0.25, vtnet0.40 or a) : vtnet0.10

Une fois l'assignation des VLANs effectuées, cela prend un peu de temps car pfSense tente de faire du DHCP sur chaque interface. On attend. Proxmox renvoit le menu lorsque c'est fait.

Accessible via l'adresse IP de la machine.

Les accès pour l'interface web sont par défaut admin et pfsense (en SSH c'est root et pfsense).

On va dans Interfaces → VLAN → Edit (pour créer les VLANs).

Puis dans Interfaces → Interface Assignement.

En assignant les VLAN via l'interface web, on peut leurs donner des descriptions. C'est important de bien le faire pour qu'en cas de problème et de moments de stress on voie bien quoi corresponde à quoi.

PfSense prévoit quelques règles pré-configurées pour les interfaces WAN et LAN. Pour le WAN, ça n'est pas un problème mais pour le LAN, on préfère être sûr de bien savoir quelles règles on applique. On fait donc le choix d'assigner l'interface LAN au VLAN 25 qui va servir à la synchronisation des pfSense et les interfaces supplémentaires Opt1 et Opt2 aux VLAN 20 et 10. Ces noms pourront changer par la suite.

Pour la seconde machine pfSense, il est nécessaire de faire également cette configuration. Ensuite, les deux machines pourront être synchronisées et toute règle ajoutée dans la première machine sera répliquée sur la seconde.

Une difficulté en assignant les VLAN est de ne pas perdre l'accès au pfSense.

Par exemple, le 28 novembre 2020, Tharyrok a d'abord pu se connecter à l'interface web via le VLAN 10 (management). Puis, pour ajouter le VLAN40 (Neutrinet) sur l'interface WAN, la stratégie adoptée a été de configurer pfSense pour disposer d'un accès au niveau du VLAN20 (assigner le VLAN 20, donner une IP à l'interface et autoriser l'accès depuis tout le réseau patata au pfSense dans le pare-feu). Ensuite, on a temporairement rajouté une seconde interface réseau à la VM web connectée par ailleurs sur le VLAN 10 pour qu'elle puisse communiquer avec le pfSense via le VLAN 20. Grâce à cet accès, Tharyrok a pu accéder à l'interface web du pfSense le temps de configurer les autres VLANs. Ce type de contournement n'a plus été nécessaire pour configurer pfSense-02.

On peut aussi se faire bannir et devoir réaliser l'assignation des interfaces en cli (voir ci-dessus).

Pour éviter les down time, les machines doivent être en haute disponibilité (High Aviability, HA), c'est à dire que la seconde machine pfSense doit pouvoir remplacer la première en cas d'interruption de celle-ci (panne ou maintenance).

Dans le pfSense-01, dans Users, on ajoute un utilisateur pour la synchronisation appelé “synch” avec un mot de passe fort. On donne à cet utilisateur un droit particulier : “system, HA node, synchro”. On crée le même utilisateur dans le pfSense-02 avec le même mot de passe (pour plus de simplicité car une machine sera maître, l'autre esclave et le jour où il faut changer, on devrait alors rechanger partout).

Dans l'interface web de proxmox, dans System → High Aviability Sync, on coche “pfsense transfers state insertion, update and deletion between firewalls”. On choisit l'interface de synchronisation (ici interco).

Dans pfSense-02, on coche tout dans la liste des choses à synchroniser.

A partir de là, toutes les règles écrites seront alors synchronisées sur la seconde machine. Il en est de même des utilisateurs. il n'y a que les paquets en plus qui doivent être ajoutés manuellement sur les deux machines.

PfSense synchronise aussi les états des connexions entre les deux pfSense. De cette façon, si pfSense-01 tombe en panne alors qu'une session tcp est ouverte, pfSense-02 prend le relais sans que la connexion soit interrompue. Du côté de l'utilisateur, cela revient par exemple à ce que le téléchargement en cours continue.

Le fichier configuration de référence pour les deux pfSense est celui du premier pfSense. Ce pfSense est considéré comme maître.

Pour cela, quand les machines sont synchronisées, toute configuration doit se faire sur la première machine car c'est elle qui est la machine dont la configuraiton xmlrpc écrase l'autre.

En cas de panne de la première machine, il faut éviter d'édicter de nouvelles règles sur la seconde machine en fonctionnement car celles-ci seront écrasées au retour de la machine master (voir ci-dessous)

Dans la rubrique Virtual IP, on rajoute une IP de type CARP et son masque : 80.67.181.6/28

• On doit générer un mot de passe qui a des contraintes (nombre de caractères, pas de caractères spéciaux)
• L'option VHID permet d'ajouter plusieurs adresses. Nous on en a qu'une alors on laisse par défaut.
• On valide.

On utilise CARP plutôt que VRRP parce que pfSense ne gère que CARP et il fonctionne bien. La différence est que VRRP est plus flexible par l'ajout de script perso mais comme on utilise CARP via pfSense, cela n'importe pas.

Dans les status de CARP, on peut alors voir que pfSense1 est “master” et pfSense2 en “backup”. Cela veut dire que pfSense 1 a l'IP virtuelle pour le moment.

Pour rendre cette IP flottante accessible de l'extérieur, on ajoute une règle dans le pare-feu pour l'interface Neutrinet : source “any”, destination, “single host” ou l'alias de l'IP flottante (on ne met pas “Neutrinet address” car alors cela sélectionnerait l'IP assignée à l'interface).

Après cette manipulation, on peut tester la HA avec un ping vers l'IP flottante. Si on désactive le premier pfSense, on constate une petite interruption dans le ping le temps que le pfSense 2 prenne le relais et puis le ping continue. Si on réactive pfSense1, on a à nouveau une petite interruption le temps que pfSense1 se re-proclame master et récupère l'IP.

NB : Entre l'installation de pfsense et le moment où on a configuré le NAT pour le réseau patata, le réseau a un peu changé. On a ajouté le réseau routing qui contient les edge, les pfsense, et la vm vpn. Voir : https://wiki.neutrinet.be/fr/infra/network/vlan

Voir aussi ce shéma du réseau :

interco = OPT3 ou routing ?? je suis plus sûre ??

Le NAT est le procédé par lequel on peut convertir une IP privée en une IP publique pour accéder à internet. La machine envoie des paquets à Pfsense à destination de l'internet avec son IP privée. Pfsense attribue un port à la machine et transmet le paquet plus loin en lui attribuant son IP publique. Quand un paquet lui revient à destination de ce port, il sait qu'il doit l'envoyer à la machine.

Le réseau patata sera le réseau sur lequel seront les différentes VM qui seront créées dans le cadre de la refonte de l'infra. Ces VM disposeront d'IPv4 privées pour éviter d'utiliser des IPv4 publiques de Neutrinet — comme c'est le cas actuellement —, et donc économiser des IPv4. Pour pouvoir accéder à internet, ces machines devront donc être nattées derrière une IP publique de Neutrinet. Pour l'IPv6, comme n'importe quelle adresse peut être routée, ce mécanisme n'existe pas. Néanmoins, on va utiliser des règles de Forward pour éviter que nos machines ne soient joignables directement sur internet.

Préalablement, pour mettre en place le réseau patata, on a configuré des règles Firewall :

• Des règles IPv4 et IPv6 vers les IP de l'interface de pfsense et l'IP flottante (CARP) qui permettront aux machines de patata d'accéder à Pfsense pour bénéficier d'un résolveur DNS (protocole TCP/UDP) et de faire un ping de la Gateway (protocole ICMP)

• Des règles OUT en Ipv4 et IPv6 pour sortir vers l'internet (tout l'internet sauf les bogons, exprimés par !bogon_v4 et !bogon_v6)

Avec ces règles, les paquets sont autorisés à sortir sur internet, mais sans autre manipulation, seule la partie IPv6 fonctionnera. Pour la partie IPv4, le NAT intervient.

Il y a plusieurs manières de faire du NAT.

• Le Port forwarding permet de dire que l'IP des Pfsense va correspondre au port d'une VM et lui forwarder les paquets. Typiquement, le port 80 sera redirigé vers le proxy http ou le port 25 sur le serveur mail.
• Le 1 à 1 fait correspondre l'IP a une machine (tous ports confondus). C'est alors à la machine de jouer le rôle du Firewall.
• Le Outbound NAT permet aux machines disposant d'adresses privées d'un réseau du Pfsense de sortir en utilisant son adresse IP publique.

Dans le cas de notre réseau patata, pour faire du Outbound NAT, on choisit l'interface Routing car c'est celle-ci qui va permettre de sortir. Dans le cas de l'architecture de Neutrinet, il y a une subtilité car les IP publiques sont dans le Vlan Neutrinet et non dans le Vlan Routing. En ajoutant la règle NAT, il faut donc modifier dans la rubrique “Translation” le champ “Interface Address” pour spécifier l'IP publique du Pfsense au lieu de l'adresse de l'interface qui est une adresse privée. Pour cela, on choisit Autre.

• On a aussi mis une règle NAT pour que le Pfsense puisse lui-même se connecter à internet (adresse source 127.0.0.0/. ?? pas bien compris si c'était pour la démo où si c'était vraiment à faire pour le réseau patata ??

Notre réseau patata contiendra les machines virtuelles de différents services de Neutrinet (site web, wiki, pad…). Pour que ceux-ci soient accessibles, il faut que les requêtes qui arrivent de l'internet parviennent aux machines qui sont sur le réseau privé. Les machines ne sont pas encore installées mais on a fait un exemple avec une machine de test.

Le port fowarding se fait sur l'interface de Routing, avec comme source toutes les adresses qui ne sont pas des bogons, vers un “single host” (on donne l'IP de notre machine de test). La redirection se fait entre l'adresse CARP sur son port 80 et le port 80 de notre machine de test. De cette manière, on autorise les paquets provenant de l'internet à accéder à la machine de test par http (vérification avec une installation de nginx).

Pour chaque règle NAT ajoutée dans Pfsense, une règle Firewall correspondante est automatiquement ajoutée pour laisser passer les paquets.

Pour l'IPv6, une redirection de port n'est pas nécessaire mais pour protéger nos machines et qu'elles ne soient pas directement joignables depuis l'internet, il est nécessaire d'ajouter des règles Firewall pour bloquer les requêtes qui leur sont destinées.

Par exemple, sans règle supplémentaire, on peut constater que la machine web du réseau Neutrinet parvient à pinguer la machine test qu'on a créé dans patata. Or, le réseau Neutrinet, c'est déjà de l'internet puisque ce sont les IP publiques de Neutrinet.

Pour éviter cela, on doit placer une règle sur l'interface Neutrinet qui bloque les paquets en direction de Patata avant de laisser sortir tous les paquets vers l'internet sauf les bogons. Pour chaque réseau qu'on gère, on doit faire cette opération. On fait donc la même chose pour Management et Routing.

Une autre manière de faire est d'ajouter les adresses des réseaux qu'on gère aux bogons, mais c'est moins visuel dans Pfsense, on préfère donc la première méthode.

Pour chaque VM installée dans Proxmox, on va créer une entrée dans les services du DNS Resolver et donner à cet endroit l'IP et le nom d'hôte de la machine (Services > DNS resolver > General Setting > Add host). Cela permet qu'à l'installation la machine reçoive automatiquement son nom d'hôte lorsqu'on installe Debian (par une requête reverse IP). Cela permet de vérifier qu'on ne s'est pas trompé et que Pfsense connaisse la machine sous son nom d'hôte. C'est un nom d'hôte qui n'est connu que de Pfsense, pas de l'internet.

On a choisit une convention pour les noms d'hôtes des machines : machine.cluster.dc.neutri.net.

En cas de problème (fichiers système du pfsense corrompus par exemple) l'option “Recover config.xml from a previous install” permet de sauvegarder le fichier de configuration de pfSense temporairement avant une réinstallation.

Lorsqu'on utilise cette option, l'installation se fait tout à fait normalement et c'est lorsque le nouveau pfSense est installé que les configurations vont être ré-appliquées. Quand on s'y connecte, tout est repris : VLAN, interfaces, règles…

Tharyrok recommande d'utiliser cette méthode pour les mises à jour, au moins pour les mises à jour de version. Les mises à jour peuvent aussi se faire via l'interface web ou la cli mais il y a parfois des problèmes de mises à jour via l'interface web. Avec l'ISO, c'est sûr et facile.

En cas de panne de la première machine, il faut éviter d'édicter de nouvelles règles sur la seconde machine en fonctionnement car lorsque la première sera à nouveau disponible, les modifications faites seront écrasées.

Si ce cas devait apparaître, la solution est de supprimer complètement pfSense-01, de faire de pfSense-02 la machine master et alors de re-synchroniser les règles dans pfSense-01.

To-Do : Tharyrok doit nous apprendre à les diagnostiquer.

Cela se fait dans la partie utilisateur : on ajoute l'utilisateur avec son nom et sa clé SSH. On ne met pas les utilisateurs dans le groupe admin. (NB : le SSH doit être configuré sur les pfSense)

Il faut autoriser l'accès à Neutrinet via le port 22 (Neutrinet, allow port 22)

On peut laisser le port par défaut car ceux qui tenteraient une attaque sont immédiatement bannis. Les IP des attaquants sont repris dans la table SSHgard.

Si l'interface VNC est nécessaire pour l'installation de la VM, on peut par la suite changer pour un terminal en serial, ce qui permet d'avoir un curseur de souris pour sélectionner du texte dans le terminal.

Le changement se fait dans les paramètres de la VM dans “Display” et dans l'interface web de pfSense : en cochant “enable serial terminal” et en cochant “disable hardware cheksum ofload” et les autres options hardware dans la rubrique hardware (sinon les performances réseau sont réduites).

Pas d'accès à internet après avoir configuré un nouveau réseau dans Pfsense, et pas de réponse ping ?

• Vérifier que le réseau est bien annoncé par Pfsense aux machines Edge au niveau du BGP. Si ça n'est pas le cas, le paquet part bien vers internet mais quand il revient, les machines edge ne savent pas où l'envoyer.

Ca ne marche pas et on ne comprend vraiment pas pourquoi ?

• Pfsense ne se met pas toujours complètement à jour immédiatement et il faut parfois recharger les filtres manuellement par un filter reload.