Fait avec la version v 2.7.0 , avec un vault avec 4 ports ethernet.

Pour reset, si on accès à l’interface web : Diagnostic -> Factory defaults

Config initiale

Wizard

Pour se connecter :
192.168.1.1
admin / pfsense

On suit le wizard.
Pas l’obligation de définir des DNS

Si l’interface WAN est connectée à un réseau local (et non directement à internet), ET qu’on souhaite accéder

Config réseau basique

La config réseau est prévue pour être faite depuis le port LAN ; c’est la seule qui a des règles de pare-feu qui laissent passer le trafic arrivant sur ce port.
Elle a aussi une règle “Anti-lockout” qui autorise la connexion http(s) et SSH vers le pare-feu.

Par défaut, sans configuration, OPT1 et OPT2 n’ont aucune règle et le trafic est donc bloqué.

Interfaces -> Assignement
pour créer une interface (configuration réseau) associé à un port. Le port peut être un port physique, ou un bridge (défini dans l’onglet Bridges) Il crée par défaut WAN -> LAN -> OPT1 -> OPT2 -> OPT3 mais on peut changer les noms

Interface -> Iface_name
pour configurer le réseau de l’interface :

• DHCP, IP statique, PPP, L2TP etc…
• adresse IP et netmask
  Penser à cocher la case au tout début “Enable interface”

DNS

https://docs.netgate.com/pfsense/en/latest/services/dns/resolver.html

PfSense viens avec unbound, un resolver DNS qui peut aussi agir comme forwarder DNS.
il vient aussi avec dnsmasq, un forwarder DNS.

À l’installation, unbound est actif par défaut en tant que resolver. Cela signifie qu’il va contacter directement les serveurs DNS racines pour obtenir les correspondances domaine -> IP.

En mode forward, il transmet la requête au(x) serveur(s) défini(s) dans System > General Setup. Ces serveurs peuvent être remplacés par ceux fournis par le DHCP, si l’option correspondante est activée (cas par défaut).
La doc PfSense indique que ce mode peut être + adapté pour les connexions multi-WAN.

Config

Services -> DNS Resolver ou Services -> DNS Forwarder

Le resolver est activé par défaut sur toutes les interfaces ; mais si on ajoute une interface, il faut “Save” puis “Apply changes” (même sans aucune modification) pour que la résolution DNS se fasse sur la nouvelle interface.

DHCP

Il me semble qu’il n’y a pas besoin de créer des règles spécifiques pour autoriser le DHCP. Soit PfSense le fait de manière transparente lorsque le DHCP est activé sur une interface, soit le DHCP utilise l’adresse de broadcast. Mais ça n’est pas nécessaire de l’autoriser explicitement.

IPv4

Services -> DHCP Server
Le serveur DHCP peut être activé, indépendemment, pour chaque interface ayant une adresse IP.

IPv6

Je souhaite le désactiver.

Services -> DHCPv6 Server & RA

pour désactiver le serveur DHCP en IPv6 sur l’interface LAN désactiver aussi Router Advertisement

Bridges

https://docs.netgate.com/pfsense/en/latest/bridges/index.html
https://provya.net/?d=2019/10/01/09/26/04-pfsense-faire-un-pont-reseau-bridging-entre-deux-interfaces

Permet de créer un pont (switch) entre 2/plusieurs interfaces. Il faut s’attendre à des performances + faibles que celles d’un switch.
Peut poser problème pour certaines fonctionnalités, comme les portails captifs.

Pour les gérer, Interfaces -> Assignments puis onglet Bridges

Ordre de création :

• Assigner chaque port (igbX) à 1 interface (avec des noms par défaut comme WAN, LAN, OPT1, OPT2) ; penser à cocher la case “Enable interface” ; choisir “None” en configuration IP
• créer le bridge en y assignant 1 ou plusieurs des interfaces précédemment créées -> BRIDGE0
• assigner BRIDGE0 à une nouvelle interface (par défaut OPT3, mais je l’appelle ici BRLAN)
• configurer BRLAN en “Enabled” et avec une configuration IP

Il faut suivre l’ordre inverse si on souhaite supprimer le bridge.

Vérifier l’adresse MAC du bridge, notamment après redémarrage ? Il est possible qu’elle soit aléatoire. Ceci peut empêcher Windows de se rendre compte qu’il s’agit du même réseau, et donc demander à définir si c’est un réseau privé, public etc.
Pour éviter ceci, on peut définir manuellement cette adresse MAC.

Il faut penser à cocher “Enable interface” pour le bridge, mais aussi pour chaque port/interface inclus dans le bridge.

Par défaut, les appareils connectés à deux ports différents d’un bridge ne peuvent pas communiquer ensemble. Pour autoriser cette connexion, il faut aller dans :
System -> Advanced puis onglet “System Tunables” et trouver (créer si elle n’existe pas) l’option
net.link.bridge.pfil_member
et la passer à 0.
Après “Apply changes”, les appareils devraient pouvoir communiquer ensemble.
Une autre méthode qui fonctionne pour autoriser cette connexion, mais qui n’est probablement pas conseillé, est de rajouter une règle firewall, sur au moins 1 des interfaces sous-jacente, autorisant la connexion depuis “BRLAN net”.

Pour autoriser la communication de ces 2 clients avec le routeur et les autres réseaux, il faut aussi ajouter au moins une règle de pare-feu dans l’onglet “BRLAN”, avec “BRLAN net” en IP source.

Interfaces group ??

LAN vs WAN

Si une “IPv4 Upstream gateway” est définie dans le menu Interfaces -> nom_de_l’interface , alors le réseau est considéré come WAN.
Sinon, il est considéré comme LAN.

https://docs.netgate.com/pfsense/en/latest/interfaces/wanvslan.html

La sélection de cette passerelle ne définit pas la capacité réelle au trafic de sortir par une passerelle ; il y a une passerelle par défaut définie dans System -> Routing, et on peut aussi y définir une passerelle pour une interface spécifique, sans qu’elle ne soit forcément considérée comme WAN.

Firewall

https://docs.netgate.com/pfsense/en/latest/firewall/fundamentals.html

Le filtrage s’applique uniquement aux paquets entrants.
La présence d’une table d’état permet aux appareils de répondre à une requête entrante, même s’ils n’auraient pas eu l’autorisation d’initier cette communication spontanément.

Règles

L’onglet correspondant à chacune des interfaces contient des règles qui s’appliquent aux paquets qui entrent par cette interface.
La vérification s’arrête à la première règle qui correspond.
Une absence de règle entraîne un blocage.

Pour une interface LAN, si on veut autoriser la connexion aux autres réseaux et internet, sans aucun filtrage, il faut au minimum une règle :

• Pass
• IPv4 (ou IPv6)
• Protocol : any
• Source : “LAN net” (ou “any”)
• Destination : any

Faire ça sur les différentes interfaces permet une communication entre les réseaux.
Si le trafic semble bloqué malgré une règle “Pass”, penser à vérifier le pare-feu sur le poste client.

Pour les bridges, il est nécessaire de configurer les règles sur l’interface du bridge, mais les ports/interfaces sous-jacents n’ont pas besoin de règles de pare-feu (sauf pour communication inter-clients sur des ports différents, voir paragraphe “Bridges)”.

États (states) et désactivation d’une règle

Lorsqu’une connexion est établie entre 2 hôtes, le firewall enregistre l’état de cette connexion dans une table d’état. On peut la consulter dans Diagnostics -> States (ou States Summary).

Lorsqu’un blocage est demandé (par ajout de règle Block ou suppression de règle Pass), cette connexion (état) pré-existante est maintenue, même après appui sur “Apply changes” !

Pour réellement actualiser le filtrage, il est nécessaire de supprimer les états préexistants. Pour ceci, sur la règle de firewall, la croix tout à droite permet de supprimer les états liés à cette règle.
On peut également reset l’ensemble des états dans Diagnostics -> States -> Reset States ; si on fait ça, il faut faire Ctrl - F5 pour retrouver l’interface webadmin.

Penser à bien faire cette manip lorsqu’on teste le bon fonctionnement des nouvelles règles.

L’ajout d’une règle autorisant une connexion ou la suppression d’une règle demandant un blocage n’ont pas cette mécanique ; elles sont actives dès le clic sur “Apply changes” car il n’y a pas d’état “connexion bloquée”.

Réseau de destination

https://docs.netgate.com/pfsense/en/latest/bridges/index.html

Si un réseau est sélectionné en “destination” lors de la création d’une règle, cette règle s’appliquera aux paquets dont ce réseau est la destination finale ; si le paquet transite par ce réseau sans chercher à le joindre directement, il ne sea pas bloqué. On peut donc bloquer l’accès au réseau upstream de notre passerelle, sans que cela ne gêne l’accès à internet.

Désactivation complète du pare-feu

En cas de besoin, on peut désactiver complètement le pare-feu via SSH.
Pour ceci, après s’être loggé, on choisit l’option 8 (Shell) et on entre :
pfctl -d
On peut ensuite le réactiver avec
pfctl -e

Isoler un réseau local en laissant l’accès à internet

Une approche pour ça est de bloquer toutes les connexions aux réseaux privés (RFC1918) puis d’autoriser l’accès à tous les réseaux.
Les clients pourront donc communiquer avec les réseaux publics (internet), mais avec aucun autre réseau privé.
Il faut aussi penser à autoriser la connexion au serveur DNS, si nécessaire (typiquement le routeur PfSense lui-même), afin que les clients puissent résoudre les domaines.

Pour ceci, dans Firewall -> Alias, je rajoute un alias de type Network, nommé “RFC1918” et contenant 3 réseaux : 10.0.0.0/8 , 172.16.0.0/12 et 192.168.0.0/16.

Ensuite, dans les règles de filtrage du (V)LAN :

• Pass ; IPv4 UDP ; source “LAN net” port *; dest. “LAN address” port 53
• Block ; IPv4 proto * ; source * port * ; dest “RFC1918” port *
• Pass ; IPv4 proto * ; source “LAN net” port * ; dest * port *

Ainsi les clients peuvent contacter le server DNS sur l’adresse locale du routeur, port 53, mais toutes les autres requêtes vers une IP type réseau local sont refusées. Enfin l’accès au reste des réseaux (donc “internet”) est autorisé.
On peut bien sûr rajouter d’autres règles “Pass” avant la règle “Block” si nécessaire (client NTP etc).
On peut également choisir d’autoriser, en dernière règle, uniquement certains ports (HTTP(S), IMAP, SMTP, SSH etc).

À noter que ces règles ne jouent pas sur la possibilité des clients de ce réseau à communiquer entre eux, car ceci se passe avant le passage dans le routeur ; et ce même si 2 clients sont branchés sur 2 ports différents du routeur configurés ensemble en bridge (voir paragraphe ur les bridges).

SSH

System -> Advanced

Routes

Dans Status -> Routes, on voit la table de routage
Flags (ceux de netcat) :
U = up, route utilisable
H : host ; la route concerne un hôte unique (si absence du flag, ça concerne un réseau)
S : static : ajoutée manuellement
G : gateway, la route requiert une passerelle intermédiaire pour être atteinte

AES-NI

Pour l’activer, aller dans system -> Advanced -> Misc. et activer l’option “Cryptographic Hardware”

https://docs.netgate.com/pfsense/en/latest/hardware/cryptographic-accelerators.html

Privilégier les ciphers aes-gcm ?
https://www.reddit.com/r/PFSENSE/comments/k9h4tg/no_hardware_crypto_acceleration_is_my_only_option/

Divers

System -> General Setup
pour y gérer

• serveur DNS initial
• theme sombre

VLAN

interfaces -> Assignments puis onglet “VLANs”

Port parent ?

L’interface apparaît alors dnas le menu interfaces. on peut la configurer (adresse IP etc)