OPNsense est un pare-feu et une plateforme de routage libre qui protége les ordinateurs et autres appareils connectés au réseau privé contre les accès non autorisés et autres menaces potentielles provenant de réseaux externes ou de l'Internet. Ce logiciel, qui est dérivé de pfSense, est basé sur FreeBSD connu pour sa stabilité, sa sécurité et ses performances exceptionnelles. Le pare-feu est un serveur sans interface graphique interactive classique, mais sa configuration se fait à l'aide d'une interface Web intuitive sans nécessiter de connaissances techniques avancées.

Ce billet détaille le processus d’obtention d'OPNsense, son installation sur un mini pc, sa configuration de base et quelques aspects de son utilisation. L'objectif est de créer un réseau local (LAN local area network) protégé par un pare-feu qui contrôle strictement les échanges avec le réseau étendu (WAN wide area network). Seuls certains types de connexions issus du LAN pourront transiter vers l'extérieur : HTTP et HTTPS (accès web), ICMP (messages erreur réseaux et ping), NTP (horodatage) et DNS (résolution d'adresses). En revanche, le pare-feu empêche toute communication non nécessaire entrant du WAN limitant les risques d'intrusion.

La lecture de l'Introduction à OPNsense : comment installer ce firewall ? de Florian Burnel (2024-09-12) est fortement recommandée. On peut aussi consulter Comment configurer OpnSense pour avoir une solution large de Pare-Feu dans son infra ? de Steve Pouru (2025-01-10).

Table des matières

Obtenir OPNsense

Le code source d'OPNsense se trouve dans un référentiel public sur GitHub. Cependant, il n'est pas nécessaire de compiler soi-même cette source si l'on installe le pare-feu sur un ordinateur avec un processeur Intel ou AMD 64 bits. L'image de l'installeur d'OPNsense peut être téléchargée depuis opnsense.org/download.

Pour faire une installation à partir d'une clé USB, il faut choisir l'image pour l'architecture amd64 (seule possibilité) et le type vga. Le terme vga est un peu déroutant, car l'installeur d'OPNsense fonctionnera avec tout appareil muni d'une carte graphique, qu'un connecteur vga soit présent ou non. En activant le bouton [Download OPNsense] on télécharge un fichier compressé nommé OPNsense-xx.y-vga-amd64.img.bz2 (où xx.y est la version courante, soit 25.7 le 13 octobre 2025).

Pour copier l'image vers un clé USB on peut utiliser rufus ou balenaEtcher si l'on a un ordinateur Windows. Pour ceux qui préfèrent Linux, on peut se servir de balenaEtcher, mais les dernières versions ne fonctionnaient pas très bien. Le problème est-il réglé ? En revanche, USBImager est très léger, fonctionne bien et est relativement vite si on ajuste la taille des mémoires tampons à 8M ou plus. Il n'est pas nécessaire d'extraire l'image du fichier compressé. Certaines distributions de Linux contiennent un utilitaire encore plus élémentaire; dans Linux Mint il se nomme Créateur de clé USB (mintstick). Je n'ai pas vérifié si ce dernier fonctionnait bien.

Lancement de l'installeur d'OPNsense

Voici le matériel nécessaire pour installer et configurer OPNsense sur un ordinateur x86_64 qui répond au moins aux exigences minimums.

Une clé USB contenant l'image de l'installeur d'OPNsense.
Un clavier USB.
Un moniteur.
Un ordinateur supplémentaire avec un port Ethernet.
Un câble Ethernet entre les deux ordinateurs.

Avant de mettre le mini PC sous tension, branchez le moniteur, la clé USB et le clavier USB au mini PC. Il n'est pas nécessaire ni même utile de connecter les deux ordinateurs avec le câble Ethernet à cette étape. De même, je préfère ne pas brancher le mini PC au réseau local pendant l'installation. Ce qu'il faut, c'est que le mini PC ignore son système d'exploitation déjà installé et démarre en chargeant le système d'exploitation sur la clé USB. Typiquement, on doit interrompre l'amorçage normal en appuyant sur une touche spécifique du clavier au bon moment pour avoir accès à un menu de sélection du lecteur où se trouve le système d'exploitation désiré ou au BIOS d'où on peut aussi faire une sélection. Les touches sont différentes selon le fabricant de l'ordinateur et même selon le modèle d'un même fabricant. Ci-dessous on trouve les instructions pour le Beelink EQ12.

Accédez au menu de sélection du lecteur de démarrage du mini PC en appuyant de façon répétée sur la touche F7 pendant le démarrage de l'appareil. On pourrait aussi passer par le menu du BIOS avec la touche Del.
Choisissez le lecteur USB comme lecteur d'amorçage.
Au début, l'installeur affiche le contenu suivant à l'écran pendant quelques secondes.

Ne faites rien d'autre que regarder les messages à l'écran pendant le chargement en mémoire de l'installeur.
Même quand Press any key to start configuration importer est affiché, ne faites rien. À moins que vous sachiez ce qu'est le script importer, auquel cas pourquoi lisez-vous ces notes ?
Parmi la longue suite de messages affichés pendant l'opération, on verra le suivant ou quelque chose qui lui ressemble.
WAN -> igc1 LAN -> igcO

Ce message rappelle que le pare-feu est un appareil périphérique connecté (edge device) inséré entre deux réseaux : le réseau étendu (alias le réseau public, le réseau externet ou l'Internet) et le réseau local (alias réseau privé, réseau domestique ou l'interface_wireless_internal) nommés WAN et LAN respectivement .

Le logiciel suppose que le réseau WAN est connecté au port physique nommé igc1 et que le réseau LAN est connecté au port nommé igc0. On ne sait pas d'emblée lequel des ports Ethernet du mini PC est igc0 et lequel est igc1.

Si l'ordinateur a des cartes réseau de Realtek plutôt que d'Intel, les ports sont nommés re0 et re1. Les noms des cartes réseau dans FreeBSD correspondent au nom du pilote suivi d'un nombre indiquant l'ordre de détection de la carte.
On aura l'impression que l'installation est bloquée après l'affichage du message Configuring WAN interface... Le délai, qui vient du fait que le mini PC n'est pas encore branché aux réseaux, peut s'étirer sur plusieurs secondes. Il faut patienter.
Enfin on aboutit au message suivant.
*** OPNsense.internal: OPNsense 25.7 (amd64) *** LAN (igcO) -> v4: 192.168.1.1/24 WAN (igc1) -> [...] Welcome! OPNsense is running in live mode from install media. Please login as 'root' to continue in live mode, or as 'installer' to start the installation. Use the default or previously-imported root password for both accounts. Remote login via SSH is also enabled. FreeBSD/amd64 (OPNsense.internal) (ttyv0) login:

Comme dit dans le message de bienvenue, on peut compléter l'installation à partir de la console (le clavier et l'écran) ou l'on peut procéder à l'installation depuis une session SSH lancée d'un ordinateur branché sur le réseau LAN du mini PC. J'ai choisi cette seconde option parce qu'il est facile de faire des captures d'écran pour illustrer le reste de l'installation ci-dessous. De toute façon, cet ordinateur additionnel sera nécessaire pour configurer OPNsense après son installation.

Voici comment un portable avec Linux Mint a été branché au mini PC avec un câble Ethernet.

C'est par expérimentation que le port icg0 a été identifié. Quand le câble Ethernet était branché sur le port le plus près des sorties USB du EQ12, le portable qui est un client DHCP ne pouvait trouver le serveur DHCP de l'installeur. Conséquemment, le portable n'a pu obtenir une adresse IP.

michel@Thinkpad:~$ ip -4 a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever

Quand le câble a été branché sur le port RJ45 à droite vu de l'arrière du EQ12, le portable a obtenu une adresse IP du serveur DHCP du pare-feu.

michel@Thinkpad:~$ ip -4 a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 inet 192.168.1.156/24 brd 192.168.1.255 scope global dynamic noprefixroute enp0s31f6 valid_lft 86396sec preferred_lft 86396sec

On peut voir que l'adresse IP affectée au portable, soit 192.168.1.156, est sur le réseau LAN 192.168.1.0/24 crée par l'installeur d'OPNsense.

Le nom d'utilisateur qui prendra en charge l'installation d'OPNsense est installer et son mot de passe est opnsense. Si on utilise la console alors ces données sont entrées avec le clavier à l'invite login déjà vu ci-dessus. J'ai préféré ouvrir une session SSH.

michel@Thinkpad~$ ssh installer@192.168.1.1 (installer@192.168.1.1) Password: opnsense n'est pas affiché à l'écran

Note: Il se peut fort bien qu'ouvrir la session soit un peu plus complexe s'il y a déjà eu une session SSH avec un autre site avec l'adresse 192.168.1.1. Il faut alors éliminer les clés associées à cette vieille session. Heureusement, le client ssh explique comment faire.

michel@Thinkpad:~$ ssh installer@192.168.1.1 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ED25519 key sent by the remote host is SHA256:hbsfjvMKpcn6mSffYD1Ap5zlNQPLjyv7F24JkvgqoFc. Please contact your system administrator. Add correct host key in /home/michel/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/michel/.ssh/known_hosts:3 remove with: ssh-keygen -f '/home/michel/.ssh/known_hosts' -R '192.168.1.1' Host key for 192.168.1.1 has changed and you have requested strict checking. Host key verification failed. michel@Thinkpad:~$ ssh-keygen -f '/home/michel/.ssh/known_hosts' -R '192.168.1.1' # Host 192.168.1.1 found: line 1 # Host 192.168.1.1 found: line 2 # Host 192.168.1.1 found: line 3 /home/michel/.ssh/known_hosts updated. Original contents retained as /home/michel/.ssh/known_hosts.old michel@Thinkpad:~$ ssh installer@192.168.1.1 The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established. ED25519 key fingerprint is SHA256:hbsfjvMKpcn6mSffYD1Ap5zlNQPLjyv7F24JkvgqoFc. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.1.1' (ED25519) to the list of known hosts. (installer@192.168.1.1) Password: opnsense n'est pas affiché à l'écran

L'installation d'OPNsense

L'assistant d'installation de FreeBDS s'affiche automatiquement à l'écran, qu'importe qu'on utilise la console ou une session SSH.

La première étape consiste à choisir la disposition du clavier. Si le clavier américain (QWERTY) est acceptable continuer en appuyant sur la touche Entrée.

Si l'on désire utiliser une autre disposition, alors utilisez les flèches de curseur ↓ et ↑ pour naviguer vers celle qui est désirée.

Cliquer sur la touche Entrée pour valider le choix.

Cliquer sur la touche Entrée pour continuer avec la disposition choisie (ici la disposition AZERTY). On pourrait aussi tester la disposition choisie avant de continuer.

Pour l'essentiel, la deuxième étape consiste à choisir le système de fichier qui sera créé sur le lecteur du pare-feu.

Il semble que l'un ou l'autre de ZFS et UFS est acceptable, mais ZFS est maintenant recommandé ce qui explique pourquoi ce choix occupe le premier rang.

Note : Si un système de fichiers ZFS existe déjà sur le lecteur du mini PC alors le message suivant est affiché.

Pour continuer en ignorant, c'est-à-dire en effaçant, le vieux système de fichiers, cliquez sur la touche Entrée

Puisqu'il n'y a qu'un seul lecteur, tous ces choix du type de miroir ou de stockage redondant sont sans intérêt. Choisir stripe ici.

Encore une fois, puisqu'il n'y a qu'un seul lecteur sur le mini PC, il n'est pas très difficile de choisir le lecteur sur lequel le système de fichiers doit être installé.

Enfin, il faut confirmer l'installation du système de fichiers puisque cela détruira le contenu actuel du lecteur.

Maintenant il faut être patient pendant que le système est installé sur le lecteur du mini PC. Au moins, il y a une indication du progrès réalisé en temps réel.

Quand cette installation du système de fichiers et du système d'exploitation est terminée on a la possibilité de modifier le mot de passe de root.

C'est très important de changer le mot de passe, mais on peut remettre à plus tard lors de la configuration de OPNsense. Si on choisit d'aller de l'avant ici, il faudra entrer le mot de passe désiré à deux reprises et de s'assurer de pouvoir s'en rappeler plus tard.

Enfin pour terminer, choisir Complete Install.

Il y a un avertissement qu'il faut retirer la clé USB sinon il se peut que le prochain amorçage se fasse depuis celle-ci.

On a le choix entre un redémarrage ou l'arrêt du système.

L'installeur affiche un dernier message sur la console dont voici la traduction.

L'installation s'est terminée avec succès.

Après le démarrage, ouvrez un navigateur web et accédez à https://192.168.1.1 (ou à l'adresse IP du réseau local). La console peut également être utilisée pour définir une autre adresse IP du réseau local.

Votre navigateur peut signaler que le certificat HTTPS n'est pas fiable et vous demander de l'accepter. Ceci est normal, car le certificat par défaut est autosigné et ne peut pas être validé par une autorité racine externe.

Configuration de base d'OPNsense

Comme intimé à la fin de l'installation, Firefox indique qu'il y a un risque de sécurité chaque fois que l'on ouvre la page Web d'OPNsense.

Il faut passez outre à cet avertissement en cliquant sur le bouton Avancé puis en cliquant sur Accepter le risque et poursuivre quand l'encadré est affiché. La procédure est sensiblement la même lorsqu'un autre navigateur est utilisé.

Il faut saisir le nom de l'utilisateur soit root puis son mot de passe qui sera opnsense ou celui spécifié à la fin de l'installation. Une fois ces informations saisies, cliquez sur le bouton [Login] pour accéder au gestionnaire Web d'OPNsense.

Après un message de bienvenue, dont l'affichage est tellement court qu'une capture d'écran n'a pas été possible, l'assistant pour la configuration du système démarre.

Cliquer sur le bouton [Next] pour entamer la configuration de base avec l'aide de l'assistant.

Aucun serveur DNS n'est spécifié dans le champ DSN Servers, car Unbound est activé par défaut(Enable Rseolver est coché). Ce service prend en charge la résolution des noms de domaine. Comme on peut voir ci-dessus,

le nom de l'hôte a été modifié,
le fuseau horaire a été spécifié, et
le support DNSSEC dans Unbound a été activé. Pourquoi ? Je n'en sais rien, mais tous le recommande.

Selon RFC 1035 - 2.3.1 Preferred name syntax un nom d'hôte ou un domaine devrait commencer avec une lettre (une de 52 lettres A à Z sans distinction entre majuscules ou minuscules), finir avec une lettre ou un chiffre (0 à 9) et ne contenir que des lettres, des chiffres, ou le tiret -. Depuis RFC 1123, un nom peut commencer avec un chiffre. L'ajout de noms de domaine internationalisés qui remonte à 2003 a été actualisé en 2008 RFC 5890, mais n'est pas encore universellement adopté. On ne peut pas enregistré un domaine contenant des lettres accentuées auprès de CIRA qui est l'autorité canadienne pour le domaine de premier niveau .ca. De plus, j'ai rencontré des problèmes avec des noms d'hôte de dispositifs domotique avec des lettres accentuées. Pour ces raisons, j'évite les noms d'hôte contenant des caractères qui ne font pas partie du jeu de 63 caractères ASCII défini initialement par ARPANET.

En principe, la concaténation du nom d'hôte et du domaine séparés d'un point, ici routeur.internal, devrait constitué un nom de domaine complet pouvant être traité par le système de noms de domaine (DNS). L'aide de OPNsense au sujet du domaine dit Do not use 'local' as your internal domain name. It is reserved for and will interfere with mDNS (avahi, bonjour, etc.). Instead, use the special-use domain internal or home.arpa, also to avoid DNSSEC validation issues. e.g. internal, name.internal. Alors que internal n'est pas parmi les domaines spéciaux (RFC 6761), home.arpa s'y trouve (voir RFC 8375 aussi). Je n'ai ni l'expérience ni les connaissances me permettant de faire une recommandation au sujet du domaine. Tant que internal n'est pas un domaine de premier niveau, il ne devrait pas y avoir de problèmes avec ce domaine proposé par défaut. Il a été très facile de passer du domaine internal au domaine home.arpa plus tard après la configuration initiale à la page de configuration System: Settings: General.

Il serait plus logique de sélectionner le français comme langue de l'interface Web. Toutefois cette option n'aura aucun effet pendant l'utilisation de l'assistant de configuration. Si l'on désire fonctionner en français on peut modifier directement la langue dans System: Settings: General puis cliquer sur le bouton [Save] au bas de cette page. Quand le message Les modifications ont été appliquées avec succès. est affiché, on peut redémarrer l'assistant de configuration Système: Configuration: Assistant. Dès lors les dialogues seront principalement en français contrairement à ce qui sera affiché ci-dessous.
J'admet qu'il y a ici une incohérence, mais j'ai l'habitude de faire fonctionner les serveurs en anglais tout simplement parce qu'il y a plus d'information dans cette langue. C'est quelque chose à revoir dans une prochaine révision de ce billet.

Cliquer sur le bouton [Next] pour voir l'onglet suivant intitulé Network [WAN].

Rien n'a été changé ci-dessus. On peut toujours retrouver ces paramètres dans la page de configuration Interface: [WAN] plus tard. Cliquer sur le bouton [Next] pour voir l'onglet suivant intitulé Network [LAN].

Ici on peut modifier l'adresse IP du réseau local (LAN) qui sera créé par le pare-feu. Il faut faire attention, car le réseau par défaut de plusieurs routeurs et de commutateurs est souvent 192.168.1.0/24. Lors d'une installation d'OPNsense, j'avais branché le port WAN à un réseau local dont l'adresse était 192.168.1.0/24 et dont le serveur DHCP avait l'adresse 192.168.1.1. Avec 2 serveurs à la même adresse, il fut impossible d'ouvrir la page Web d'OPNsense. Voilà pourquoi j'ai recommandé de ne pas brancher le mini PC aux réseaux local et extérieur initialement. Donc, il est fortement conseillé de changer l'adresse IP s'il y a la moindre possibilité d'un conflit. Ceci étant dit, il faut choisir une plage d'adressage IP définie par la RFC 1918 Address Allocation for Private Internets pour les réseaux privés; toute adresse publique étant proscrite. On pourra modifier l'adresse IP du réseau local plus tard dans la page de configuration Interfaces: [LAN].

Si on ne coche pas Configure DHCP server, aucun serveur DHCP ne sera créé ce qui serait dans la plupart des cas une grave erreur. Par contre, l'assistant ne dit pas quel serveur DHCP sera créé et n'offre pas de choix à cet égard. En fait, OPNsense peut activer l'un d'au moins trois services DHCP : ISC DHCP, Kea DHCP ou Dnsmasq. Dans la version 25.7, c'est Dnsmasq qui est créé par défaut. Ultérieurement, on pourra modifier ce choix dans la page de configuration Services:.

Cliquer sur le bouton [Next] pour voir l'avant dernier onglet de configuration intitulé Set initial password qu'on ne voit pas dans la capture d'écran ci-dessous.

Le mot de passe a déjà été modifié lors de l'installation d'OPNsense. On peut le modifier de nouveau ici. Plus tard, le mot de passe peut être modifié sans passer par l'assistant de configuration depuis la page Lobby: Password

Cliquer sur le bouton [Next] une dernière fois pour arriver à l'onglet nommé Finish.

Il y a des exceptions, mais très souvent une modification de la configuration du pare-feu ne sera faite qu'après avoir appuyer sur un bouton [Apply] comme on le voit ci-dessus. Après l'activation de ce bouton, l'assistant de configuration effectue les changements spécifiés.

Le message annonçant la fin de la configuration confirme partiellement que celle-ci est déjà appliquée puisque le nom d'hôte du pare-feu est maintenant routeur tel que précisé au tout début du processus.

On peut redémarrer l'assistant de configuration en tout moment depuis la page System: Configuration: Wizard, mais on devrait probablement éviter tout recours additionnel à l'assistant de configuration. Cette procédure modifie certains paramètres un peu à notre insu. Plus concrètement, j'ai fait la gaffe d'utiliser l'assistant pour réactiver Unbound après l'avoir désactivé en récupérant une ancienne configuration. Je n'avais pas anticipé que la configuration du service DHCP serait toute chambardée aussi.

Configuration du routeur du fournisseur d'accès à Internet

Puisque la configuration de base d'OPNsense est complétée, vérifions son fonctionnement. Il est donc temps de brancher l'interface WAN du pare-feu au routeur du FAI qui devrait être en mode pont (voir Qu’est-ce que le mode bridge sur un routeur et pourquoi l’utiliser ? de Flavien Roux). Quand le port WAN du mini PC et le modem/routeur de FAI en mode pont sont connectés, l'adresse IP de l'interface WAN du pare-feu sera une adresse IP publique attribuée par le FAI. Une adresse IP publique est, par définition, accessible depuis tout dispositif branché à l'Internet.

Il est impossible de présenter ici une démarche générale pour activer le mode pont. Typiquement cela est fait dans l'interface de gestion du routeur dont l'adresse IP est affichée sur une étiquette collée sur l'appareil probablement avec le nom d'utilisateur et le mot de passe par défaut. En revanche, la configuration spécifique pour activer le mode pont varie considérablement selon les fabricants. D'ailleurs le terme « mode pont » n'est pas nécessairement utilisé. De plus, l'interface Web du routeur n'est pas toujours bien documentée.

Il se peut fort bien qu'il ne soit même pas possible d'activer le mode pont. C'est le cas pour la version du HomeHub 3000 provenant de notre FAI, Bell Aliant. Heureusement, il a été possible d'établir une connection DMZ évoluée avec le mini pc hôte d'OPNsense. Ce n'est pas optimal, mais le fonctionnement est acceptable la plupart du temps. Un billet intitulé Configuration du HomeHub 3000, pas encore disponible, contiendra plus de détails.

Premiers tests

Pour contrôler le fonctionnement de la configuration de base du pare-feu, vérifions, en premier, que l'ordinateur portable a une adresse IP sur le réseau local sur le segment 192.168.1.0/24 par défaut.

michel@M7:~$ ip -4 a ... 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 inet 192.168.1.110/24 brd 192.168.1.255 scope global dynamic noprefixroute enp1s0 valid_lft 6219sec preferred_lft 6219sec ...

Maintenant, vérifions que le routeur OPNsense est atteignable depuis un ordinateur branché sur le réseau local, puis que les sites sur le réseau étendue à l'extérieur du réseau local sont aussi atteignables.

michel@M7:~$ ping -c 2 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.162 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.200 ms --- 192.168.1.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1026ms rtt min/avg/max/mdev = 0.162/0.181/0.200/0.019 ms michel@M7:~$ ping -c 2 9.9.9.9 PING 9.9.9.9 (9.9.9.9) 56(84) bytes of data. 64 bytes from 9.9.9.9: icmp_seq=1 ttl=55 time=37.5 ms 64 bytes from 9.9.9.9: icmp_seq=2 ttl=55 time=34.5 ms --- 9.9.9.9 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 34.500/35.998/37.496/1.498 ms

Le serveur principal de Quad9 situé sur le réseau étendu est donc atteignable. Il reste à voir si la résolution des noms de domaine se fait correctement. La première commande révèle que le serveur DNS est en bien Unbound sur le routeur OPNsense. La seconde teste que le résolveur Unbound est capable de traduire un nom de domaine (bing.com) en une adresse IP.

michel@M7:~$ resolvectl status ... Link 2 (enp1s0) Current Scopes: DNS Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 192.168.1.1 DNS Servers: 192.168.1.1 DNS Domain: home.arpa michel@M7:~$ ping -c 2 bing.com PING bing.com (150.171.27.10) 56(84) bytes of data. 64 bytes from 150.171.27.10: icmp_seq=1 ttl=112 time=26.7 ms 64 bytes from 150.171.27.10: icmp_seq=2 ttl=112 time=24.6 ms --- bing.com ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 24.586/25.638/26.691/1.052 ms

Mise à jour

Si les tests ont été réussis, on peut et on devrait mettre à jour OPNsense. Voici comment procéder.

Quand on active le bouton [Check for updates], la liste des paquets à mettre à jour sera récupérée par FreeBSD et sera affichée dans l'onglet Updates.

Après quelques secondes, cette capture des messages du programme pkg est remplacée par un tableau affichant les nouvelles versions des paquets à mettre à jour.

On peut voir ci-dessus le bouton pour lancer la mise à jour, [✔ Update] ainsi que l'avertissement que le pare-feu sera redémarré. Toutefois, s'il s'agit d'une mise à jour importante, le tableau sera masqué par des notes plus détaillées au sujet de la mise à jour.

Cliquer sur le bouton Close pour fermer cette fenêtre. Puis cliquer sur le bouton [✔ Update] dans l'onglet Updates pour lancer l'opération de mise à jour.

Il faut cliquer sur le bouton [OK] en acceptant que le pare-feu soit redémarré. La mise à jour vers la version 25.7.5 prend environ deux minutes

OPNsense annonce que le redémarrage est en cours après la fin de la mise à jour.

Quand il n'y a pas de mise à jour on a le résultat suivant dans l'onglet Updates.

Si l'avertissement suivant est affiché c'est qu'on a un problème.

Cela est une indication que la résolution des noms de domaine ne fonctionne pas. Comme on peut voir en arrière plan, le pare-feu n'arrive pas à rejoindre pkg.opnsense.org.

Quelques ajustements

Même si je ne devais que décrire la configuration de base d'OPNsense, voici quelques réglages supplémentaires qui sont utiles. En premier, j'ai activé le serveur SSH.

Activation du serveur SSH

La gestion du pare-feu doit se faire avec l'interface de gestion Web d'OPNsense. En principe, pouvoir ouvrir une session à distance avec le protocole SSH n'ajoute rien alors qu'activer le service SSH augmente la surface d'attaque du pare-feu. Cependant, j'ai ajouté ce service pour deux raisons. Premièrement pour assouvir ma curiosité. Parce que je connais mal FreeBSD, je trouve intéressant de voir un peu comment ce système d'exploitation fonctionne. Deuxièmement, pouvoir accéder au pare-feu si jamais l'interface Web devait devenir inaccessible est réconfortant. En activant le serveur SSH du pare-feu dans la section Secure Shell de la page System: Settings: Administration on obtient cette possibilité.

Comme on peut voir j'ai choisi la configuration la plus simple pour ce qui est de l'autorisation. Seuls les utilisateurs ayant un compte sur le pare-feu pourront se connecter avec un mot de passe. Notez qu'ils doivent se connecter depuis un ordinateur sur le réseau local (l'interface LAN ). L'utilisateur root n'a pas la permission de se connecter par SSH comme c'est généralement recommandé.

Ajout d'un utilisateur

Cela ne donne rien d'activer le serveur SSH s'il n'y a pas d'utilisateur qui puisse accéder à ce serveur. Ajoutons un utilisateur en cliquant sur le bouton [+] dans la page de configuration System: Access: Users.

Un dialogue s'affiche et on peut voir que l'UID (numéro d'identité de l'utilisateur) pour le premier utilisateur ajouté après root est 2000 alors que typiquement il est 1000 dans Linux. Pour le peu de choses que j'ai fait en tant que l'utilisateur 2000, cette différence n'a pas eu de conséquences.

Pour le reste, il faut saisir le nom de l'utilisateur, son mot de passe et son abonnement au groupe admins qui est le seul choix disponible. Enfin il ne faut pas oublier de cliquer sur le bouton [Save]. Dès lors, l'utilisateur peut ouvrir une session sur le pare-feu.

michel@M7:~$ ssh michel@192.168.1.1 (michel@192.168.1.1) Password: ******** n'est pas affiché à l'écran Last login: Mon Sep 22 19:18:17 2025 from 192.168.1.110 ------------------------------------------------ | Hello, this is OPNsense 25.7 | :::::::. | | :::::::::. | Website: https://opnsense.org/ | ::: ::: | Handbook: https://docs.opnsense.org/ | ::: ::: | Forums: https://forum.opnsense.org/ | ::: ::: | Code: https://github.com/opnsense | `::::::::: | Reddit: https://reddit.com/r/opnsense | `::::::: ------------------------------------------------

FreeBSD n'est pas Linux mais ces systèmes d'exploitation ont une racine commune. Plusieurs des programmes qui avaient été créés dans UNIX sont disponibles dans les deux systèmes, dont les utilitaires qui manipulent les fichiers et répertoires: cat, ls, cp, mv, mkdir. D'ailleurs la structure des répertoires est aussi semblable. En revanche l'interpréteur de commande par défaut est sh et non bash comme dans plusieurs distributions Linux et le processus de démarrage est plus près de celui d'UNIX que de Linux. En outre, grub et systemd (ou SysV) sont absents; boot0 et init / rc étant le programme d'amorçage et le système d'initialisation.

La documentation de FreeBSD contient une introduction a ce système d'exploitation pour les personnes qui sont à l'aise dans Linux : FreeBSD Quickstart Guide for Linux® Users. Il y a une traduction, Guide rapide pour débuter avec FreeBSD à l'attention des utilisateurs de Linux qui pourrait ne pas être à jour.

Vérifions l'identité de l'utilisateur.

michel@routeur:~ $ id uid=2000(michel) gid=0(wheel) groups=0(wheel) michel@routeur:~ $ groups wheel michel@routeur:~ $ cat /etc/group | grep admins admins:*:1999:

Paradoxalement, l'utilisateur a été enrôlé dans le groupe wheel, mais ne semble pas être membre du groupe admins qui pourtant existe. D'après une recherche assez sommaire, le groupe wheel est important dans FreeBSD étant plus ou moins l'équivalent du groupe sudoers dans Linux. L'utilisateur peut donc devenir root.

michel@routeur:~ $ sudo su *** routeur.home.arpa: OPNsense 25.7.5 (amd64) *** IOT (vlan02) -> v4: 192.168.0.1/24 LAN (igc0) -> v4: 192.168.1.1/24 WAN (igc1) -> v4/DHCP4: 47.54.54.134/22 HTTPS: sha256 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF SSH: SHA256 abcabcabcabcabcabcabcabcabcabcabcabcabcabca (ECDSA) SSH: SHA256 cbacbacbacbacbacbacbacbacbacbacbacbacbacbac (ED25519) SSH: SHA256 xyzabcxyzabcxyzabcxyzabcxyzabcxyzabcxyzabcx (RSA) 0) Logout 7) Ping host 1) Assign interfaces 8) Shell 2) Set interface IP address 9) pfTop 3) Reset the root password 10) Firewall log 4) Reset to factory defaults 11) Reload all services 5) Power off system 12) Update from console 6) Reboot system 13) Restore a backup Enter an option:

C'est la console d'OPNsense d'où l'on peut mettre à niveau le système, le redémarrer, le restaurer depuis des sauvegardes comme on verra plus loin et ainsi de suite. Si l'option 8) Shell est choisie, on retourne dans l'interpréteur de commande en tant que root.

0) Logout 7) Ping host 1) Assign interfaces 8) Shell 2) Set interface IP address 9) pfTop 3) Reset the root password 10) Firewall log 4) Reset to factory defaults 11) Reload all services 5) Power off system 12) Update from console 6) Reboot system 13) Restore a backup Enter an option: 8 root@routeur:/home/michel # root@routeur:/home/michel # ls / .cshrc COPYRIGHT dev lib net sbin var .probe.for.readonly bin entropy libexec proc sys zroot .profile boot etc media rescue tmp .rnd conf home mnt root usr

La commande exit ferme l'interpréteur de commande et l'on retourne à la console. Puis l'option 0) Logout nous retourne à la session SSH.

root@routeur:/home/michel # exit exit *** routeur.home.arpa: OPNsense 25.7.5 (amd64) *** ... 0) Logout 7) Ping host 1) Assign interfaces 8) Shell 2) Set interface IP address 9) pfTop 3) Reset the root password 10) Firewall log 4) Reset to factory defaults 11) Reload all services 5) Power off system 12) Update from console 6) Reboot system 13) Restore a backup Enter an option: 0 michel@routeur:~ $

Enfin, la commande exit termine la session SSH et on se retrouve dans le terminal.

michel@routeur:~ $ exit Connection to routeur.home.arpa closed. michel@M7:~$

Cette section se termine avec un avertissement. Aussi tentant que cela puisse être, il ne faut pas gérer les composants du pare-feu depuis l'interpréteur de commande. De plus, on ne doit même pas s'attendre à ce que FreeBSD fonctionne de façon typique, car OPNsense prend en charge une bonne partie de son fonctionnement. Presque toujours, il faut gérer le système avec l'interface Web du pare-feu.

Réduire l'usure du lecteur NVMe

Les nombreuses entrées du journal du système sont sauvegardées sur le lecteur NVMe ce qui pourrait réduire sa durée de vie. Pour diminuer de façon considérable toutes ces opérations d'écriture sur le disque électronique, OPNsense peut monter le répertoire où sont sauvegardé les journaux ainsi que le répertoire /tmp, qui ne contient que des fichiers temporaires, dans des systèmes de fichiers tmpfs. Rappelons qu'il s'agit de systèmes de fichiers virtuels stockés en mémoire vive uniquement. Une démarche semblable est recommandée pour diminuer l'usure de la carte SD des systèmes monocarte comme les divers modèles du Raspberry . La mise en oeuvre est très simple. Il suffit de cocher deux cases dans la section Disk / Memory Settings de la page de configuration System: Settings: Miscellaneous:.

Quand au premier paramètre de cette rubrique, il me semble qu'il serait contradictoire d'ajouter un fichier d'échange (swap) de 2 Go qui servirait à utiliser une partie du lecteur NVMe comme cache pour augmenter virtuellement la taille de la mémoire vive.

Après avoir sauvegardé les modifications de la configuration et redémarré le pare-feu, on peut examiner l'espace occupé par les système de fichiers virtuels.

michel@routeur:~ $ df -h Filesystem Size Used Avail Capacity Mounted on zroot/ROOT/default 453G 1.3G 451G 0% / devfs 1.0K 0B 1.0K 0% /dev /dev/gpt/efiboot0 260M 1.3M 259M 1% /boot/efi zroot/home 451G 156K 451G 0% /home zroot 451G 96K 451G 0% /zroot zroot/var/audit 451G 96K 451G 0% /var/audit zroot/tmp 451G 96K 451G 0% /tmp zroot/usr/ports 451G 96K 451G 0% /usr/ports zroot/usr/src 451G 96K 451G 0% /usr/src zroot/var/crash 451G 96K 451G 0% /var/crash zroot/var/tmp 451G 100K 451G 0% /var/tmp zroot/var/mail 451G 96K 451G 0% /var/mail zroot/var/log 451G 77M 451G 0% /var/log tmpfs 7.9G 197M 7.7G 2% /var/log tmpfs 7.9G 1.0M 7.9G 0% /tmp tmpfs 7.9G 116K 7.9G 0% /var/lib/php/tmp devfs 1.0K 0B 1.0K 0% /var/dhcpd/dev devfs 1.0K 0B 1.0K 0% /var/unbound/dev /usr/local/lib/python3.11 453G 1.3G 451G 0% /var/unbound/usr/local/lib/python3.11 /lib 453G 1.3G 451G 0% /var/unbound/lib

Après quatre jour d'utilisation consécutive d'OPNsense, les trois tmpf n'occupent que 198 Mo sur 16 Go de mémoire vive du EQ12 et le fichier d'échange swap n'est pas été utilisé.

michel@routeur:~ $ swapinfo Device 1K-blocks Used Avail Capacity /dev/ada0p3 8388608 0 8388608 0%

D'ailleurs le tableau de bord d'OPNsense (Accueil: Tableau de bord) montre clairement que le pare-feu ne grève presque pas les capacités du mini pc.

Sauvegarder les journaux dans un système de fichier tmpfs veut dire que les journaux sont perdus à chaque redémarrage du pare-feu. Pour faciliter le débogage, c'est peut-être préférable d'éviter cette mesure au début pendant la configuration initiale d'OPNsense. Plus tard, si l'on rencontre des problèmes avec une mise à niveau du système, il pourrait être avantageux de suspendre la sauvegarde des journaux dans la mémoire volatile.

Sauvegarder et restaurer la configuration

Toutes les options d'OPNsense paramétrables depuis l'interface d'administration sont consignées dans le fichier XML /conf/config.xml. En voici le début.

<?xml version="1.0"?> <opnsense> <theme>opnsense</theme> <sysctl version="1.0.1" persisted_at="1756094252.07"> <item uuid="11a37c07-c91a-4d94-94c5-dcda3360d50f"> <tunable>vfs.read_max</tunable> <value/> <descr>Increase UFS read-ahead speeds to match the state of hard drives and NCQ.</descr> </item> <item uuid="42831cc9-4f5a-4bf4-901f-cfeab86c3314"> <tunable>net.inet.ip.portrange.first</tunable> <value/> <descr>Set the ephemeral port range to be lower.</descr> </item> <item uuid="2b173971-f418-4493-a5cc-35707ae89279"> <tunable>net.inet.tcp.blackhole</tunable> <value/> <descr>Drop packets to closed TCP ports without returning a RST</descr> </item>

Puisque ce fichier est lu à chaque démarrage du pare-feu, il suffit de le remplacer avec une ancienne version puis d'exécuter un redémarrage (reboot) pour revenir à une configuration antérieure du système. C'est essentiellement comment fonctionne la restauration de la configuration gérée à partir de la page System: Configuration: Backups dans l'interface de configuration d'OPNsense.

Sauvegarde automatique

Comme on peut lire, il y a un cache (en fait c'est le dossier /conf/backup/) qui contient par défaut les 3 plus récentes sauvegardes. J'ai augmenté ce Backup Count à 16. Selon l'avertissement, le cache occupera 1,5 Mo quand il sera plein, ce qui est rien comparé à l'espace libre qui dépasse les 450 Go.

michel@routeur:/conf $ df -h / Filesystem Size Used Avail Capacity Mounted on zroot/ROOT/default 453G 1.4G 452G 0% /

Les actions qui découlent d'un clic sur [Save] après avoir augmenté le nombre de sauvegardes conservées sont les suivantes.

Le message The changes have been applied successfully. est affiché au début de la page.
La configuration modifiée est sauvegardée dans le fichier /conf/config.xml.
Une copie de ce fichier est conservée dans le cache /conf/backup/ avec un nom horodaté
Si le nombre de sauvegardes dans le cache dépasse la limite, les plus vielles sauvegardes sont effacées.

michel@routeur:/ $ ls -l /conf/*xml -rw-r----- 1 wwwonly wheel 70237 Sep 18 20:07 /conf/config.xml michel@routeur:/ $ ls -l /conf/backup total 146 -rw-r----- 1 root wheel 70239 Sep 18 16:22 config-1758223354.3522.xml -rw-r----- 1 root wheel 70238 Sep 18 17:33 config-1758227586.5223.xml -rw-r----- 1 root wheel 70236 Sep 18 17:37 config-1758227853.9664.xml -rw-r----- 1 root wheel 70237 Sep 18 20:07 config-1758236845.4511.xml

Le nombre décimal dans le nom du fichier est son âge mesuré en secondes depuis le 1er janvier 1970, ce qu'on appelle l'heure Unix. Heureusement, quand il est question de choisir une sauvegarde, OPNsense affiche la date et l'heure en temps local explicitement.

Je n'ai pas créé les trois plus vielles configurations dans le cache. OPNsense ajoute automatiquement une sauvegarde dans le cache après chaque modification d'un paramètre de la configuration. Souvent des changements au pare-feu exigent la modification de plusieurs options de configuration. Avec seulement 3 sauvegardes dans le cache, il pourrait être impossible de retourner à une ancienne configuration valide en cas d'erreurs. L'expérience indiquera si 16 est une limite plus appropriée.

Voilà pour la sauvegarde de configurations automatique et intentionnelle dans le cache. Mais comment restaurer la configuration à partir d'une sauvegarde dans le cache ? Il n'y a rien à cet égard dans System: Configuration: Backups. À cause de cette absence, j'ai sous-évalué l'importance du cache de sauvegardes. J'aurais évité des soucis si seulement j'avais lu la documentation sur ce sujet : Restore Configuration via Console ou si j'avais examiné de plus près le menu dans la console VGA et essayé la dernière option.

*** routeur.home.arpa: OPNsense 25.7.3 (amd64) *** ... 0) Logout 7) Ping host 1) Assign interfaces 8) Shell 2) Set interface IP address 9) pfTop 3) Reset the root password 10) Firewall log 4) Reset to factory defaults 11) Reload all services 5) Power off system 12) Update from console 6) Reboot system 13) Restore a backup Enter an option: 13 1. Thu Sep 18 17:37:33 ADT 2025 2. Thu Sep 18 17:33:06 ADT 2025 3. Thu Sep 18 16:22:34 ADT 2025 Select backup to restore or leave blank to exit:

Avec l'option 13) Restore a backup, il suffit de saisir l'index de la sauvegarde à restaurer.

Pour manuellement restaurer une ancienne configuration, on passe par l'option 8 pour avoir un shell qui est un interpréteur de commande qu'on appelle aussi une interface en ligne de commande. Avec des commandes classiques, cd, ls, cp et reboot, on remplace la configuration /conf/config.xml par la copie sauvegardée d'un ancienne configuration dans /conf/backup/. Clairement, l'option 13 du menu est plus facile, mais je ne sais pas si la configuration courante est sauvegardée avant d'être remplacée comme expliqué dans Restore Configuration via Console.

Sauvegarde manuelle sur support externe

La page de gestion System: Configuration: Backups offre un autre mécanisme de sauvegarde et restauration, plus classique si on veut. Si on clique sur le bouton [Download configuration] le système d'exploitation de l'ordinateur depuis lequel la gestion d'OPNsense se fait affichera un dialogue de sauvegarde du fichier XML contenant la configuration courante. Voici ce dialogue dans Mint MATE.

Le dossier sur mon ordinateur de bureau où sont conservées ces sauvegardes manuelles contenait déjà une sauvegarde récente et deux anciennes sauvegardes faites avec l'ancien pare-feu sur le Lenovo.

Pour réaliser l'opération inverse qui consiste à restaurer une ancienne configuration sauvegardée sur l'ordinateur de bureau, on clique sur le bouton [Parcourir] dans la section Restore.

Puis on sélectionne une configuration sauvegardée auparavant dans le dialogue d'ouverture d'un fichier du système d'exploitation. J'ai choisi l'ancienne configuration datant du 4 juillet. En cliquant sur le bouton [Restore configuration] cette dernière a été installée. La plupart du temps, ce mécanisme fonctionne très bien.

Restaurer une configuration en pratique

La restauration de la configuration de 4 juillet a frôlé le désastre. Le réseau local LAN n'existait plus et l'appareil ne se connectait pas au routeur du FAI. Il était impossible de gérer le pare-feu puisque son interface d'administration n'était plus en ligne. Heureusement, la console fonctionnait.

Il est probable qu'il aurait été possible de retourner à la dernière configuration qui fonctionnait avec l'option 13, mais comme expliqué ci-dessus je n'avais pas encore compris sa valeur. J'ai plutôt utilisé le shell (l'option 8) pour examiner le système pour essayer de comprendre ce qui n'allait pas, puis l'option 1 pour réaffecté les interfaces LAN et WAN aux cartes de réseau. De là il a été possible d'accéder à l'interface de gestion d'OPNsense et de restaurer la configuration de base du 29 août faite qu'un ou deux jour auparavant.

En comparant la configuration du 29 août faite depuis le Beelink EQ12 juste après l'installation de base d'OPNsense et celle du 4 juillet pour le Lenovo, je me suis rendu compte de la source du problème. La restauration de la configuration faite depuis le Lenovo vers le Beelink n'a pas fonctionné parce que les noms des cartes de réseaux du Lenovo (re0 et re1) ne correspondaient pas aux noms sur le Beelink (igc0 et egc1).

config-routeur.localdomain-20250704233618.xml (Lenovo)

<interfaces> <wan> <if>re1</if> <descr>WAN</descr> <enable>1</enable> <lock>1</lock> ... </wan> <lan> <if>re0</if> <descr/> <enable>1</enable> <lock>1</lock> ...

config-routeur.internal-20250829215203.xml (Beelink)

<interfaces> <wan> <if>igc1</if> <descr>WAN</descr> <enable>1</enable> <lock>1</lock> ... </wan> <lan> <if>igc0</if> <descr/> <enable>1</enable> <lock>1</lock> ...

Heureusement, re0 n'apparait que deux fois et re0 qu'une seule fois dans la sauvegarde du 4 juillet. Après avoir substitué igc0 et igc1 pour re0 et re1 respectivement, j'ai sauvegardé la configuration modifiée sous un nouveau nom que j'ai ensuite restauré. Le résultat escompté a été obtenu. Il a été possible de connecter le réseau local au Beelink et tout fonctionnait comme avant: le réseau virtuel IOT, le point d'accès, les réservations statiques DHCP, le serveur Wireguard, enfin tout.

Instantanés du système de fichier

Rapellons que le système de fichiers d'OPNsense est ZFS par défaut ou UFS autrement. Dans les deux cas, il est possible de créer des instantanés du système de fichiers. Cependant, OPNsense ne prend en charge cette possibilité qu'avec ZFS. La rubrique Snapshots d'OPNsense étant claire et complète, me semble-t-il, voici que quelques indications sur l'utilisation des instantanés.

On peut créer un instantané et éventuellement restauré le système de fichiers ZFS depuis la page de configuration System: Snapshots.

Il a été suffisant de cliquer sur le bouton [+] pour créer l'instantané du 18 septembre 2025. On aurait pu choisir un nom plus évocateur lors de sa création, mais on peut aussi renommer l'instantané en cliquant sur l'icône d'édition qui affiche l'image d'un crayon.

Pour résumer, on suggère de créer un instantané nommé valide avant d'apporter des modifications importantes au pare-feu. S'il s'avère que le pare-feu fonctionne correctement après que les changements ont été réalisés, on peut éliminer l'instantané valide. Si au contraire le pare-feu ne fonctionne pas on active l'instantané valide pour revenir en arrière. Cela peut se faire depuis la page de configuration des instantanés (cliquer sur l'icône activée, [✔], à la droite de l'instantané) ou depuis le menu de démarrage dans la console VGA. Dès que le système de fichier est restauré, il faut purger la liste en éliminant l'instantané default puis en changeant le nom de l'instantané valide à default.

Clairement, la création d'un instantané n'est pas la même chose que la sauvegarde de la configuration. Un instantané ne peut pas être utilisé pour copier la configuration d'un appareil à un autre. Une sauvegarde de la configuration ne peut pas protéger le système contre une mise à niveau du pare-feu qui contient une régression logiciel. Ces deux mécanismes sont complémentaires. Je me permets de traduire le conseil (tip) à ce propos.

Les instantanés peuvent être conservés pendant un certain temps après une mise à niveau, afin de pouvoir revenir en arrière après quelques jours de test en production. Veuillez noter que toutes les modifications de configuration effectuées pendant cette période seront perdues lors de la restauration. Il peut donc être nécessaire de créer une sauvegarde de la configuration et de l'importer dans l'ancien système de fichiers après sa restauration.

Et voici un autre conseil également utile.

Les instantanés peuvent également servir à se prémunir contre les régressions liées aux modifications de configuration. Si un instantané est activé immédiatement après sa création, le système de fichier sera automatiquement restauré depuis cet instantané au prochain redémarrage du pare-feu.

OPNsense en action

Il est intéressant de voir OPNsense agir comme pare-feu. En examinant la vue en direct de son journal (Firewall: Log Files: Live View) on peut voir les connexions acceptées, rejetées, redirigées et ainsi de suite. En filtrant pour ne voir que les connexions bloquée, j'ai vite repéré de nombreuses tentatives de connexions TCP depuis l'adresse IP 78.128.114.22.

En ajoutant un second filtre spécifiant l'adresse IP comme source et en arrêtant le rafraichissement automatique, j'ai isolé quatre tentatives de connexion en un peu moins de quatre secondes. Les ports TCP ciblés sont dans la plage des ports enregistrés, mais ils ne sont pas actuellement affecté à une utilisation particulière par l'IANA. Alors qu'elle peut être la cible ? Intrigué, j'ai consulté AbuseIPDB pour découvrir que cette adresse est associée à des activités en ligne malveillantes depuis deux ans.

Notre petit réseau local sans intérêt et isolé au bout d'un cul-de-sac d'un demi-kilomètre dans une région rurale d'une province qui ne représente que 2% de la population du Canada est la visée d'acteurs malintentionnés. Qui l'aurait cru ?

Après ?

Cette installation de base d'OPNsense donne un pare-feu qui est supérieur à la borne universelle de notre fournisseur d'accès à Internet (FAI) à certains égards. La facilité avec laquelle on peut sauvegarder et restaurer la configuration d'OPNsense accroit considérablement la fiabilité du réseau. Si le nouveau mini pc hôte du pare-feu devait tomber en panne, on pourrait le remplacer par l'ancien mini pc en quelques minutes.

Nous n'avons qu'effleuré la question, mais OPNsense expose bien plus d'information au sujet de son fonctionnement que la borne du FAI. Éventuellement, ces données pourront être exploitées pour améliorer la sécurité du système.

Cependant, le pare-feu OPNsense avec sa configuration de base présentée ci-dessus ne pouvait remplacer la borne universelle de notre FAI. Il est notoire que FreeBSD ne supporte que très peu d'adaptateurs sans fil (voir l'avertissement dans Interfaces: Wireless Networks (INTERNAL)). Donc un point d'accès pour prendre en charge les connexions sans-fil Wi-Fi relativement nombreuses a été ajouté. Puis des commutateurs Ethernet, dont un qui devait être gérable, ont été ajouté pour qu'il soit possible de répartir les nombreux appareils connectés au réseau local entre des réseaux virtuels indépendants.

En plus des améliorations à l'infrastructure du réseau local, il a été possible d'activer d'autres services d'OPNsense qui rendent le pare-feu plus performant. Parmi les plus importants pour moi, il y a WireGuard qui donne un accès sécuritaire à toutes les ressources du réseau local depuis tout ordinateur relié à l'Internet. Un autre service qui est très utile, c'est le blocage de sites pour diminuer la publicité indésirée, réduire le pistage, éviter les sites malveillants et ainsi de suite.

Notre réseau local est plus sécuritaire, plus résilient et plus cohérent que jamais. J'entends documenter les ajouts de matériel et les améliorations à la configuration d'OPNsense mentionnés ci-dessus dans de futurs billets.