Opnsense on slash-root.fr

OPNsense : Serveur WireGuard et client KDE en split tunnel

Wed, 22 Jul 2026 00:00:00 +0000

L’objectif est simple : pouvoir depuis mon laptop KDE joindre les machines du LAN derrière un OPNsense via WireGuard, sans pour autant envoyer tout mon trafic internet dans le tunnel. Autrement dit, un split tunnel propre : seul le réseau derrière le pare-feu passe par le VPN, le reste reste sur ma connexion classique.

Depuis OPNsense 24.1, WireGuard est intégré au core. Plus besoin de jouer avec le plugin os-wireguard, c’est déjà ça de gagné. La procédure reste assez directe, mais quelques points de routage sont à surveiller pour ne pas finir avec tout le trafic déporté sur le VPN.

Voici le plan utilisé dans cet article :

LAN derrière OPNsense : 192.168.1.0/24
Réseau du tunnel : 10.10.10.0/24
OPNsense (interface WireGuard, IP au sein du tunnel VPN) : 10.10.10.1/24
Client KDE (IP au sein du tunnel VPN) : 10.10.10.2/32
Port UDP : 51820

Note : cet article traite uniquement l’IPv4. L’IPv6 n’est pas abordé ici.

Let’s go !!!

Prérequis

OPNsense accessible depuis Internet : IP publique sur son interface WAN, ou redirection du port UDP 51820 depuis le routeur amont.
Le client KDE dispose de wireguard-tools et d’un NetworkManager gérant nativement WireGuard (à partir de la v1.16, ça marche out of the box sur la plupart des distros récentes).

Partie 1 : OPNsense, le serveur WireGuard

Création de l’instance

On commence par générer le serveur :

Aller dans VPN > WireGuard > Instances.
Cliquer sur +.
Remplir comme suit :

Enabled : Coché
Name : HomeWireGuard
Public Key : Générer via la roue crantée
Private Key : Générer en même temps
Listen Port : 51820
MTU : 1420 (1412 si PPPoE)
Tunnel Address : 10.10.10.1/24
Peers : Laisser vide pour l'instant
Disable Routes : Décoché

Le MTU de 1420 tient compte de l’overhead d’encapsulation WireGuard (en-têtes IP/UDP/WireGuard, soit environ 60 à 80 octets). Ainsi, le paquet final reste sous les 1500 octets d’un lien Ethernet standard. En PPPoE, le MTU physique est souvent 1492, d’où la valeur 1412.

Note : si on active le mode avancé, laissez le champ DNS Server vide. Sinon WireGuard écrase la config DNS d’OPNsense et c’est la galère.

Sauvegarder, rouvrir l’instance et copier la clé publique générée. Elle servira à configurer le client KDE.

Création du peer client

Il faut maintenant déclarer le client. Pour ça, il faut sa clé publique. On peut la générer directement sur le client KDE (voir partie 2) et la copier ici, ou utiliser le Peer Generator intégré à OPNsense. Moi je préfère générer les clés sur le client pour ne pas stocker la privée ailleurs.

Aller dans VPN > WireGuard > Peers.
Cliquer sur +.

Enabled : Coché
Name : MonPC_KDE
Public Key : <clé publique du client KDE>
Allowed IPs : 10.10.10.2/32
Keepalive : 25

Le Keepalive à 25 secondes, c’est utile quand le client est derrière un NAT ou un pare-feu qui ferme les states trop vite.

Sauvegarder, puis retourner dans VPN > WireGuard > Instances, éditer HomeWireGuard et sélectionner le peer MonPC_KDE. Apply.

Méthode alternative : le Peer Generator

Si vous devez créer plusieurs clients, ou si vous voulez générer directement le fichier de config sans taper de clés à la main, OPNsense intègre un Peer Generator sous VPN > WireGuard > Peer generator.

Sélectionner l’instance HomeWireGuard.
Remplir les champs :

Name : MonPC_KDE
Endpoint Address: <ip_publique_ou_domaine_opnsense>
Endpoint Port : 51820
Allowed IPs : 10.10.10.2/32
DNS : laisser vide, ou 10.10.10.1 si vous voulez utiliser le DNS d'OPNsense

Cliquer sur Generate. Le générateur crée :
- la paire de clés du client
- le peer côté OPNsense (seule la clé publique est stockée)
- une config prête à copier/coller ou à scanner en QR code

Attention : la config générée met souvent AllowedIPs = 0.0.0.0/0, ::/0 côté client. Si vous voulez du split tunnel, il faut remplacer cette ligne par AllowedIPs = 10.10.10.0/24, 192.168.1.0/24 dans le fichier récupéré avant de l’importer dans NetworkManager. Sinon tout le trafic partira dans le tunnel.

Cliquer sur Store and generate next pour valider le peer dans OPNsense, puis Apply dans VPN > WireGuard > Peers.
La clé privée n’est pas conservée sur le firewall : copiez-la dans /etc/wireguard/wg0.conf sur le client, ou scannez le QR code depuis un téléphone.

C’est nettement plus rapide quand il y a plusieurs road warriors à déployer.

Activation de WireGuard

VPN > WireGuard > General.
Cocher Enable, puis Apply.
Si besoin, redémarrer WireGuard en le décochant/re-cochant.

Assigner une interface (recommandé)

Ce n’est pas strictement obligatoire pour un split tunnel, mais ça simplifie les règles firewall et ça crée l’alias HomeWireGuard net.

Interfaces > Assignments.
Sélectionner le device wg1 (ou wg0 selon l’installation) et l’ajouter.
Description : HomeWireGuard.
Éditer l’interface :

Enable : Coché
Description : HomeWireGuard
IPv4 Configuration Type : None
IPv6 Configuration Type : None

Save puis Apply changes. Redémarrer WireGuard si l’interface ne remonte pas proprement.

Règles firewall

1. Autoriser les connexions entrantes sur le WAN

Firewall > Rules > WAN.
Ajouter une règle :

Action : Pass
Quick : Coché
Interface : WAN
Direction : in
Protocol : UDP
Source : any
Destination : WAN address
Destination port: 51820

2. Autoriser le trafic depuis le tunnel vers le LAN

Firewall > Rules > HomeWireGuard (ou WireGuard si vous n’avez pas assigné d’interface).
Ajouter une règle :

Action : Pass
Quick : Coché
Interface : HomeWireGuard
Protocol : any
Source : HomeWireGuard net
Destination : LAN net

C’est cette règle qui autorise le client KDE à joindre les machines du LAN.

Normalisation MSS (optionnel mais fortement recommandé)

Le MSS (Maximum Segment Size) est la taille maximale de la charge utile d’un segment TCP. Comme WireGuard encapsule les paquets (en-têtes UDP/IP/WireGuard), le MTU utile du tunnel est réduit. Les hôtes du LAN peuvent négocier un MSS basé sur l’interface locale (1500 octets), ce qui donnerait des paquets trop gros une fois encapsulés. Le MSS clamping force la valeur négociée à MTU_tunnel - 40 pour IPv4, soit 1380 avec un MTU de 1420. L’IPv6 n’est pas traité ici.

Firewall > Settings > Normalization.
Ajouter une règle sur l’interface WireGuard (Group) :

Direction : Any
Protocol : any
Source : any
Destination : any
Description : WireGuard MSS Clamping IPv4
Max mss : 1380

NAT outbound

Pour un split tunnel pur, pas besoin de NAT outbound. OPNsense sait router le trafic entre HomeWireGuard et LAN car les deux réseaux lui sont directement attachés. Si jamais OPNsense n’est pas la passerelle par défaut du LAN, alors il faudra activer le NAT outbound ou ajouter une route statique sur le routeur intermédiaire.

Partie 2 : KDE, le client WireGuard

Génération des clés

Sur le poste KDE :

wg genkey | tee private.key | wg pubkey > public.key

public.key : à copier dans le peer OPNsense (étape “Création du peer client”).
private.key : reste sur le client, ne jamais la balancer sur un chat.

Fichier de configuration `wg0.conf`

Créer /etc/wireguard/wg0.conf :

[Interface]
PrivateKey = <contenu de private.key>
Address = 10.10.10.2/32
# DNS optionnel, par exemple si vous voulez utiliser le DNS d'OPNsense
# DNS = 10.10.10.1

[Peer]
PublicKey = <clé publique d'OPNsense>
AllowedIPs = 10.10.10.0/24, 192.168.1.0/24
Endpoint = <ip_publique_ou_domaine_opnsense>:51820
PersistentKeepalive = 25

Le point crucial du split tunnel : AllowedIPs ne contient pas 0.0.0.0/0. Seuls les réseaux à atteindre derrière OPNsense (192.168.1.0/24) et le tunnel (10.10.10.0/24) y figurent. Ainsi, seul ce trafic est routé vers wg0 ; le reste (internet) reste sur l’interface classique.

Import dans NetworkManager

En ligne de commande (plus fiable)

sudo nmcli connection import type wireguard file /etc/wireguard/wg0.conf

Puis on s’assure que NetworkManager ne met pas cette connexion en passerelle par défaut :

sudo nmcli connection modify wg0 ipv4.never-default yes

En graphique (KDE Plasma)

Ouvrir Paramètres système > Connexions.
Ajouter une connexion > WireGuard.
Onglet WireGuard :
- Private key : coller la clé privée.
- Peers : ajouter le peer avec la clé publique d’OPNsense, l’endpoint, et Allowed IPs = 10.10.10.0/24, 192.168.1.0/24.
Onglet IPv4 :
- Méthode : Manuel.
- Adresse : 10.10.10.2/32.
- Laisser la passerelle vide.
- Cocher Utiliser cette connexion uniquement pour les ressources de ce réseau.
Sauvegarder et activer.

Si l’option WireGuard n’apparaît pas dans l’interface graphique, vérifier que wireguard-tools est bien installé et que NetworkManager est assez récent.

Vérifications

Sur le client KDE, une fois connecté :

ip route show

On doit voir quelque chose comme :

default via 192.168.0.1 dev eth0 proto dhcp metric 100
10.10.10.0/24 dev wg0 proto static scope link
192.168.1.0/24 dev wg0 proto static scope link

L’important : la route default pointe toujours vers l’interface locale. Les routes 10.10.10.0/24 et 192.168.1.0/24 pointent vers wg0.

Tests basiques :

ping 10.10.10.1
ping 192.168.1.x

Vérifier que l’IP publique vue depuis le navigateur n’a pas changé (le trafic internet ne passe pas par le VPN) :

curl -4 ifconfig.me

Côté OPNsense, on peut surveiller l’état dans VPN > WireGuard > Status. On doit voir le peer MonPC_KDE avec un handshake récent et du trafic RX/TX.

Conclusion

OPNsense : instance HomeWireGuard (10.10.10.1/24), peer MonPC_KDE (10.10.10.2/32), firewall WAN UDP 51820 + règle HomeWireGuard net → LAN net.
Client KDE : AllowedIPs = 10.10.10.0/24, 192.168.1.0/24, ipv4.never-default yes.
Résultat : les machines du LAN derrière OPNsense sont accessibles, mais internet continue de sortir par la connexion locale. Pas de fuites, pas de ralentissements inutiles.

Et si un jour vous voulez forcer tout le trafic par le VPN, il suffit de remplacer AllowedIPs par 0.0.0.0/0 côté client et d’ajouter le NAT outbound sur OPNsense. Mais ce n’est pas le sujet d’aujourd’hui.

OPNsense : Configuration du NAT Reflection

Sat, 08 Feb 2025 16:23:40 +0100

Lors de la mise en place de services web ou d'applications sur son réseau local, on se retrouve souvent confronté à un problème courant : comment accéder à ces services depuis l'intérieur du réseau en utilisant la même adresse que les utilisateurs externes ? C'est là qu'intervient le NAT Reflection dans OPNsense, une fonctionnalité puissante mais parfois mal comprise.

Dans cet article, nous allons voir comment configurer correctement les options du NAT Reflection pour permettre un accès transparent à vos services, que ce soit depuis l'extérieur ou l'intérieur de votre réseau.

Configuration des options du NAT Reflection

Pour configurer le NAT Reflection dans OPNsense, suivez ces étapes :

Se rendre dans Firewall (1), Settings (2), puis Advanced (3)
Faire défiler jusqu'à la section Network Address Translation

Deux options importantes sont à configurer :

Reflection for port forwards : Cette option permet aux clients du réseau local d'accéder aux services redirigés via l'adresse IP publique du pare-feu.
Automatic outbound NAT for Reflection : Cette option configure automatiquement les règles NAT sortantes nécessaires pour le NAT Reflection.

Cas d’utilisation

Le NAT Reflection est particulièrement utile dans plusieurs scénarios :

Hébergement d'un serveur web accessible via un nom de domaine
Services internes nécessitant une URL cohérente (interne/externe)
Applications utilisant des redirections de ports

Par exemple, si vous hébergez un site web monsite.com qui pointe vers votre IP publique, le NAT Reflection permettra aux utilisateurs internes d'accéder au site via monsite.com au lieu d'utiliser une adresse IP locale.

Points d’attention

Quelques points importants à garder à l'esprit :

Le NAT Reflection peut légèrement impacter les performances du pare-feu
Activez ces options uniquement si nécessaire
Vérifiez régulièrement les logs pour détecter d'éventuelles anomalies
Utilisez des règles de pare-feu strictes pour contrôler l'accès

Application des changements

Une fois les options configurées :

Cliquer sur Save en bas de la page
Appliquer les changements en cliquant sur Apply
Tester l'accès à vos services depuis le réseau local

Conclusion

Le NAT Reflection est une fonctionnalité essentielle d'OPNsense qui, une fois correctement configurée, permet une gestion transparente des services hébergés. Les deux options présentées ici simplifient grandement sa mise en œuvre tout en maintenant la sécurité du réseau.

N'hésitez pas à activer ces options si vous avez besoin d'accéder à vos services hébergés via l'adresse IP publique depuis votre réseau local. Cependant, gardez toujours à l'esprit l'impact potentiel sur la sécurité et surveillez régulièrement votre configuration.

OPNsense : Block malicious IPs

Thu, 21 Mar 2024 10:08:02 +0100

Un jour, j'ai décidé d'ajouter des blocklists à mes instances Crowdsec. Tout fier, j'en informe mon copain BoB sur Discord. C'est à ce moment là, qu'il me répond : "Hey, rajoute cette liste comportant + de 200k IP !"

Cette fameuse liste est disponible sur ce dépôt git : https://github.com/duggytuxy/Intelligence_IPv4_Blocklist

En complément : Un clin dœil à Romain Marcoux pour ses travaux open source liés autour de la CTI : https://github.com/romainmarcoux

La communauté BE.CYBER a même découpé cette liste pour bypass la limitation des équipements Fortinet. Pour ici, pas besoin de la découper puisque je vais présenter comment la mettre en place sur OPNsense et la mettre à jour automatiquement.

Allez, c'est parti !

Mise en place d’un alias

Pour la mise en place de la liste, il faudra créer un alias. C'est également grâce à cet alias qua liste se mettra à jour automatiquement.

Tout d'abord, se rendre dans Firewall (1), Aliases (2). Puis, ajouter un nouvel alias (3).

5 champs à remplir :
- Name (1) : Le nom qui permettra d'utiliser cet alias dans les règles du firewall.
- Type (2) : Sélectionner URL Table (IPs). Cela va permettre d'indiquer une fréquence de mise à jour.
- Refresh Frequency (3) : Indiquer la fréquence de mise à jour de la liste. Ici, tous les jours.
- Content (4) : La fameuse liste au format raw.
- Description (5) : Le nom de ce champs parle de lui-même.

Lien de la liste : [Update 13/09/2025] https://raw.githubusercontent.com/duggytuxy/Data-Shield_IPv4_Blocklist/refs/heads/main/prod_data-shield_ipv4_blocklist.txt

Valider en cliquant sur Save, puis Apply.

La liste est mise en place avec 8309 entrées à ce jour (1) à travers ce nouvel alias. De plus, on peut constater que le firewall d'OPNsense peut comporter jusqu'à 1 millions d'entrées par défaut (2).

Augmenter le nombre d’entrées

Si cette limite d'un million d'entrées dans le système n'est pas suffisante, il est possible de l'augmenter.

Se rendre dans Firewall (1), Settings (2), Advanced (3), et indiquer le nombre désiré (4).

Valider en cliquant sur Save.

Configuration des règles du firewall

Pour bloquer ces IPs malicieuses en entrées comme en sorties du firewall, il est nécessaire de créer 2 nouvelles règles. Pour réaliser ça, les définir dans Floating est intéressant. Ainsi ces règles vont s'appliquer sur toutes les interfaces en priorité.

Se rendre dans Firewall (1), Rules (2), Floating (3). Puis ajouter une nouvelle règle (4).

4 champs importants :
- Action (1) : Par défaut, ce champs sera sur Pass. Le modifier pour Block
- Direction (2) : Peu importe la direction, on bloque ! Donc, any.
- Source (3) : Sélectionner l'alias créé précédemment.
- Destination (4) : Peu importe la destination ! Donc, any.

Valider en cliquant sur Save.
Créer une seconde règle identique à la première mais en inversant Source et Destination.
Ne pas oublier de cliquer sur Apply pour valider l'ajout de ces 2 règles.

Voilà, c'est mis en place !

Bien évidemment, il est possible d'activer les logs sur ces 2 règles afin d'en mesurer l'impact et/ou pouvoir les remonter dans un SIEM par exemple.

OPNsense : Déploiement d’une instance sur OVHcloud [Partie 2/2]

Fri, 18 Nov 2022 15:17:42 +0100

Cet article fait suite à mon précédent OPNsense : Déploiement d'une instance sur OVHcloud [Partie 1/2] afin d'avoir un routeur opensource exploitable.

Configuration IP

1er démarrage

Lors du 1er démarrage de l'instance OPNsense, un écran similaire à celui-ci est affiché :

L'adressage IP des différentes interfaces réseaux est à paramétrer.

Attention à la dénomination de LAN et de WAN. A ce stade, l'attribution du LAN et du WAN fait par l'installateur est incorrect. En réalite :

vtnet0 = Adresse IP publique soit le WAN pour l'instance

vtnet1 = Adresse IP du vRack soit le LAN pour l'instance

Se connecter

Pour réaliser la configuration IP nécessaire, il faut tout d'abord se connecter dans la console.

Login : root
Password : opnsense

Le menu d'administration de la console est maintenant disponible :

Assignation des interfaces

Comme évoqué précédemment, l'attribution des interfaces faites par l'installeur est erronée. Il faut donc refaire l'assignation des 2 interfaces.

Faire le choix 1 : Assign interfaces
- Do you want to configure LAGGS now ? : N
- Do you want to configure VLANs now ? : N
- Enter the WAN interface name : vtnet0
- Enter the LAN interface name : vtnet1
- Enter the Optional interface 1 name : Press Enter

Le récapitulatif suivant doit être affiché :

The interfaces will be assigned as follows :
WAN -> vtnet0
LAN -> vtnet1

Appliquer les modifications
- Do you want to proceed ? : Y

A présent, les interfaces sont correctement assignées. L'adresse IP publique est récupérée par le DHCP d'OVH sur l'interface WAN.

Paramétrage IP

Avant d'aller plus loin, il va falloir récupérer quelques informations sur l'instance :

L'adresse IP publique et sa passerelle : Ces informations sont disponibles dans le tableau de bord de l'instance.
L'adresse IP sur le vRack : Cette information est disponible dans la liste des instances (colonne IP privée).

Attention au masque de sous-réseau :

IP publique = Masque de sous-réseau en 32 bits

IP privée vRack = Masque de sous-réseau en 16 bits

Puis passer au paramétrage des adresses IP sur OPNsense dans la console VNC :

Faire le choix 2 : Set interface IP address

Available interfaces :
1 - LAN (vtnet1 - static, track6)
2 - WAN (vtnet0 - dhcp, dhcp6)

Paramétrer d'abord l'interface WAN
- Enter the number of the interface to configure : 2
- Configure IPv4 address WAN interface via DHCP ? : N
- Enter the new WAN IPv4 address : Adresse IP publique relevée précédement
- Enter the new WAN IPv4 subnet bit count : 32
- Enter the new WAN IPv4 upstream gateway address : Adresse passerelle / gateway relevé précédement
- Do you want to use the gateway as the IPv4 name server, too ? : N
- Enter the IPv4 name server : 213.186.33.99 (DNS OVH)
- Configure IPv6 address WAN interface via DHCP6 ? : N
- Enter the new WAN IPv6 address : Press Enter
- Do you want to change the web GUI protocol from HTTPS to HTTP ? : N (Un certificat SSL Let's Encrypt sera appliqué plus bas)
- Do you want to generate a new self-signed web GUI certificate ? : N
- Restore web GUI access defaults ? : N

L'interface WAN est paramétrée.

Maintenant, passer au paramétrage de l'interface LAN:

Refaire le choix 2 : Set interface IP address
- Enter the number of the interface to configure : 1
- Configure IPv4 address LAN interface via DHCP ? : N
- Enter the new LAN IPv4 address : Adresse IP privée du vRack relevée précédement
- Enter the new LAN IPv4 subnet bit count : 16
- Enter the new LAN IPv4 upstream gateway address : Press Enter
- Configure IPv6 address LAN interface via DHCP6 ? : N
- Enter the new LAN IPv6 address : Press Enter
- Do you want to enable the DHCP server on LAN ? : N
- Do you want to change the web GUI protocol from HTTPS to HTTP ? : N
- Do you want to generate a new self-signed web GUI certificate ? : N
- Restore web GUI access defaults ? : N

L'interface LAN est paramétrée.

Interface web

1ère connexion

Par défaut, pour se connecter à l'interface web d'administration de la solution OPNsense, il faut s'y connecter à travers l'interface LAN.

Dans le cas présent, il n'y a pas d'autre machine présente sur ce contexte réseau. Il faut donc s'y connecter à travers l'interface WAN.

Pour se faire, dans la console VNC de l'instance :

Faire le choix 8 : Shell
- Désactiver le pare-feu :

pfctl -d

Attention, à chaque rechargement de la configuration d'OPNsense, le pare-feu sera réactivé. Une règle autorisant l'administration à distance par le WAN sera définie plus bas.

Il est maintenant possible de se connecter à l'interface web d'administration d'OPNsense à travers l'interface WAN.

Se rendre sur l'adresse https://IP_PUBLIC
Accepter le certificat auto-signé
Renseigner les credentials
- Username : root
- Password : opnsense

Un assistant de configuration est proposé lors de la 1ère connexion, celui-ci peut être by-passé en cliquant sur le logo OPNsense en haut à gauche.

Filtrage

Pour accéder à la page d'administration d'OPNsense, le pare-feu a été désactivé pour effectuer la 1ère connexion.

Rappel : A chaque rechargement de configuration, le pare-feu sera réactivé automatiquement.

Idéalement, il faut définir une seule adresse IP (ou plusieurs) qui sera autorisée à y accéder.

Tout d'abord, créer un alias afin de mieux identifier l'hôte qui sera autorisé à se connecter à l'interface web d'administration.

Se rendre dans Firewall (1), Aliases (2)
Ajouter un nouvel alias (3)

Voici un exemple d'alias pour une adresse IP donnée. Bien penser à valider le Content en appuyant sur Enter, puis Save en bas à droite :

Ne pas valider tout de suite les modifications avec le bouton Apply figurant en bas sur la page des Aliases. Sinon, le pare-feu se réactivera et la connexion sera perdue. Si cela se produit, revenir dans la console VNC de l'instance et refaire la commande pfcl -d.

Ensuite, ajouter une règle sur l'interface WAN du pare-feu.

Se rendre dans Firewall (1), Rules (2), WAN (3)
Ajouter une nouvelle règle (4)

La partie Source de la règle :

La partie Destination de la règle :

Enregistrer avec le bouton Save
Valider toutes les modifications de configuration en cliquant sur Apply changes en haut à droite de la page

L'alias créé ainsi que la règle ajoutée dans l'interface WAN du pare-feu vont être appliqué. Le pare-feu sera également réactivé automatiquement.

Pour être sûr et certain que le pare-feu soit bien actif :

Se rendre dans la console VNC de l'instance et exécuter la commande :

pfctl -e

Le shell doit renvoyer :

pfctl: pf already enabled

Mot de passe root

Maintenant que l'accès externe à l'interface web d'administration est filtré, il est important de changer le mot de passe root.

Se rendre dans Lobby (1), Password (2)

La modification de ce mot passe entraine également la modification du mot de passe dans la console VNC et/ou par SSH si cet accès est activé.

Hostname, Timezone…

Il peut être intéressant de modifier le nom d'hôte, le domaine, ou bien la timezone d'OPNsense.

Se rendre dans System (1), Settings (2), General (3)

Sécurité

Sujet très vaste !

Je vais m'attarder sur 2 points principaux :

La mise à jour d'OPNsense
La mise en place d'un certificat SSL avec Let's Encrypt

Mise à jour

Il est important de mettre régulièrement à jour la solution.

Se rendre dans System (1), Firmware (2), Status (3)
Puis Check for updates (4)

Si des mises à jour sont disponibles, la liste des packages concernés sera affichée dans l'onglet Updates.

En bas de cette page, un bouton Update sera disponible. Il sera également indiqué si un redémarrage d'OPNsense est requis.

Certificat SSL Let’s Encrypt

Installation du client

La 1ère étape à réaliser est l'installation du client acme.

Se rendre dans System (1), Firmware (2), Plugins (3)
Installer le client acme (4)

Activation du plugin

Une fois ce plugin installé, forcer un rafraichissement de l'interface web (CTRL+SHiFT+R) pour avoir le service ACME Client de disponible.

Se rendre dans Services (1), ACME Client (2), Settings (3)
Activer le plugin (4)

Valider avec le bouton Apply

Une tâche cron est générée afin de renouveler automatiquement le certificat. Celle-ci est définie dans l'onglet Update Schedule.

Création du compte Let’s Encrypt

Ensuite, un compte doit être créé et enregistré pour la génération du certificat chez Let's Encrypt.

Se rendre dans Accounts (1)
Créer un compte (2)

Compléter les champs requis

Valider avec le bouton Save
Enregistrer le compte

Le status du compte passe en OK (registred).

Enregistrement DNS

Avant de passer à la suite, il est impératif de créer un enregistrement de type A dans la zone DNS publique adéquate pointant vers l'adresse IP publique d'OPNsense.

Par exemple :

opnsense-demo.example.com. IN A xxx.xxx.xxx.237

xxx.xxx.xxx.237 = IP publique de l'interface WAN d'OPNsense

Bien vérifier que cet enregistrement a été répercuté sur les serveurs DNS de Google (Let's Encrypt s'appuie dessus).

Dans votre terminal GNU/Linux :

dig opnsense-demo.example.com @8.8.8.8

Il est également est possible de vérifier l'enregistrement à cette adresse : https://dns.google

Paramétrage du challenge

Une fois cet enregistrement fait et vérifié, paramétrer un type de challenge :

Se rendre dans Challenge Types (1)
Créer un nouveau type de challenge (2)

Choisir un challenge de type HTTP-01

Dans le champ IP Addresses bien valider l'adresse IP publique de l'interface WAN en appuyant sur Enter

Valider avec le bouton Save

Automatisation

Avant de passer à la génération du certificat, il est recommandé d'ajouter une tâche d'automatisation. Celle-ci sera effectuée à chaque fois que le certificat sera renouvelé.

Se rendre dans Automations (1)
Créer une tâche d'automatisation (2)

Sélectionner la tâche de redémarrage de la Web UI d'OPNsense

Cette partie d'automatisation est optionelle mais recommandée.

Génération du certificat

Maintenant, un certificat peut être généré :

Se rendre dans Certificates (1)
Créer un nouveau certificat (2)

Dans le champ Common Name, bien renseigner l'URL d'accès qui permettra d'accéder à l'interface web d'administration d'OPNsense en correspondance avec l'enregistrement de type A faites dans la zone DNS au préalable.

Bien spécifier la tâche d'automatisation dans le champ Automations.

Valider avec le bouton Save
Générer le certificat avec le bouton Issue/Renew All Certificates

Vérification

Vérifier l'ajout de l'autorité de certification :
- Se rendre dans System (1), Trust (2), Authorities (3)
- L'authorité de certification Let's Encrypt doit être présente

Vérifier la présence du certificat préalablement généré :
- Se rendre dans Certificates (1)
- Le certificat préalablement généré doit être présent

Application du certificat

A ce stade, ce nouveau certificat Let's Encrypt peut être appliqué pour la connexion à l'interface d'administration d'OPNsense (en lieu et place du certificat auto-signé).

Se rendre dans System (1), Settings (2), Administration (3)

Je recommande de modifier le port d'administration HTTPS et d'adapter la règle de filtrage (vu dans le chapitre Interface web / Filtrage de cet article).

Valider avec le bouton Save

Et voilà !

Il est désormais possible d'accéder de façon sécurisée à l'admimistration d'un OPNsense hébergé chez OVHcloud avec un certificat SSL reconnu.

En suivant l'exemple donné ici, l'accès se fera sur l'URL : https://opnsense-demo.example.com (Adresse fictive pour l'article !).

OPNsense : Déploiement d’une instance sur OVHcloud [Partie 1/2]

Fri, 23 Sep 2022 08:00:46 +0200

Dans cet article je vais décrire comment installer une instance sous OPNsense au sein d'OVHcloud.

Par défaut, il n'est pas possible de déployer une image OPNsense lors de la commande d'une instance sur OVHcloud.

En effet les distributions disponibles sont :

AlmaLinux
RockyLinux
CentOS
Debian
Fedora
Ubuntu

Pourtant, on peut très bien déployer un système complet OPNsense (FreeBSD) nativement sur une instance OVHcloud.

Un vRack sera déployé pour la partie LAN d'OPNsense.

Préparation de l’instance OVHcloud

Contexte

Voici un schéma simplifié du contexte de déploiement de l'OPNsense :

L'instance qui hébergera OPNsense utilisera l'offre Discovery à 4.99€ HT/mois avec 1 vCPU, 2 Go de RAM, et 25GB de disque SSD.
Un vRack sera déployé pour relier d'autres instances futures derrière l'OPNsense. Par exemple pour héberger un cluster swarm.

Création d’un vRack

En tout premier, il faut créer le vRack auquel sera rataché la future instance OPNsense. Cette opération se réalise dans le panel d'administration (OVH Manager) de vos services Public Cloud chez OVH.

Dans la catégorie Network, se rendre dans la partie Private Network.
Créer un réseau privé.
Définir un ID de VLAN (Recommandé)
Choisir le mode de distribution des adresses (Statique recommandé).

Dans la partie Localisation, il est possible de définir à quelle région sera rattaché ce vRack. Pour cet article tout ce passera à Gravelines.
Définir un nom pour ce vRack (ClusterSwarm dans cet article).

Cela peut prendre un peu de temps à être déployé la 1ère fois. Patience...

Une fois déployé et disponible, ce vRack apparait dans la liste des réseaux privés disponible avec la plage d'adresse attribuée.

Création de l’instance

Maintenant que le vRack est déployé, une nouvelle instance peut être créée.

Dans la partie Instances, créer une nouvelle instance.
Choisir un modèle (Instance D2-2 amplement suffisante).
Choisir une localistation (Gravelines par exemple).
Sélectionner une image. Ici, je suis parti sur une Debian 11 mais peut importe le choix car l'installation d'OPNsense se fera à travers une image rescue.

Ajouter sa clef SSH publique de type RSA ou ECDSA (Les clefs de type ED25519 ne sont pas pris en charge).
Définir un nom pour cette instance (hostname).
Sélectionner le réseau privé à attacher à cette instance (Le vRack préalablement créé doit être disponible).

Sélectionner une période facturation (Mensuel ou horaire).
Créer l'instance.

Cette instance est maintenant disponible. Son adresse IP publique et son IP privée y sont indiquées.

Installation OPNsense

Démarrage en mode rescue

Pour pouvoir installer OPNsense, il est nécessaire de démarrer en mode rescue l'instance préalablement créée.

En mode rescue, le disque principal sera disponible mais non monté. Le système rescue sera chargé en RAM (soit 2 Go avec une instance D2-2).

L'ISO d'OPNsense fait 1,3 Go

Il est donc impératif de sélectionner une image rescue qui prend très d'espace afin d'y loger également l'iso d'OPNsense.

De celle que j'ai testé, c'est la Debian 9 qui est la plus approprié pour la suite des manipulations.

Dans les détails de l'instance, redémarrer en mode rescue.
Sélectionner l'image Debian 9.

Une fois le redémarrage effectué en mode rescue en Debian 9, il est possible de s'y connecter avec la clef SSH qui a été définie lors de la création de l'instance.

Se connecter en SSH à l'instance :

ssh -i ~/.ssh/ma_clef_privee debian@[IP_PUBLIC_INSTANCE]

Adapter selon l'emplacement et le nom de la privée.

[IP_PUBLIC_INSTANCE] = IP publique de l'instance OVHcloud.

Récupération de l’ISO d’OPNsense

Une fois connecté en SSH à l'instance en mode rescue Debian 9, il est important de controler qu'il y aura assez d'espace disque afin de récupérer et décompresser l'ISO d'OPNsense.

Vérifier l'espace disque disponible (Le rescue mode est chargé en RAM) :

df -h | grep -v ^tmpfs

L'espace restant disponible est de 1,9G. Cela sera suffisant pour récupéré l'ISO compressé et la décompresser :

Filesystem Size Used Avail Use% Mounted on
udev 968M 0 968M 0% /dev
/dev/sda1 3.0G 954M 1.9G 34% /

Télécharger la dernière ISO disponible d'OPNsense :

wget -P /tmp https://mirror.vraphim.com/opnsense/releases/22.7/OPNsense-22.7-OpenSSL-dvd-amd64.iso.bz2

Installer bzip2 (Si celui-ci n'est pas disponible) :

sudo apt update
sudo apt install bzip2

Extraire et supprimer l'archive :

cd /tmp
bzip2 -dk OPNsense-22.7-OpenSSL-dvd-amd64.iso.bz2
rm OPNsense-22.7-OpenSSL-dvd-amd64.iso.bz2

Mise en place QEMU/VNC

Afin de pouvoir déclencher l'installation en mode console d'OPNsense à partir de l'ISO récupérée, VNC sera utilisé à travers QEMU.

Afin de pouvoir prendre réaliser cela, il est nécessaire de relancer la connexion SSH à l'instance à l'aide d'un tunnel SSH afin de mapper le port distant 5900 vers un port local.

Se reconnecter à la session SSH de l'instance en rescue :

ssh -i ~/.ssh/ma_clef_privee debian@[IP_PUBLIC_INSTANCE] -L 5900:localhost:5900

Télécharger le package :

wget -qO- /tmp /vkvm.tar.gz | tar xvz -C /tmp

Démarrer QEMU/VNC :

sudo /tmp/qemu-system-x86_64 -net nic -net user,hostfwd=tcp::80-:80,hostfwd=tcp::443-:443 -m 1024M -localtime -enable-kvm -hda /dev/sda -hdb /dev/sdb -vnc 127.0.0.1:0 -cdrom /tmp/OPNsense-22.7-OpenSSL-dvd-amd64.iso -boot d

En mode rescue, /dev/sda correspond à la racine (volume monté en RAM), et /dev/sdb dorrespond au disque principal de votre instance (disponible mais non monté).

Démarrage de l’installation d’OPNsense

A partir de maintenant, il est maintenant possible de se connecter en VNC sur 127.0.0.1:5900.

2 possibilités sont offertes lors du démarrage :

Boot en mode live : Se connecter en root avec le mot de passe opnsense.
Lancement de l'installation : Se connecter en installer avec le mot de passe opnsense .

Le boot en mode live ne présente aucun intérêt dans ce cas de figure. Le compte installer est donc à utiliser pour déclencher l'installation de la solution.

Sélectionner le bon disque pour l'installation (ada1 25GB car instance d2-2) :

vtnet0 = Interface publique

vtnet1 = IP vRack

Une fois l'installation terminée, dans les détails de l'instance sur le manager OVH, sortir du mode rescue :

Après quelques instants votre instance démarrera normalement sur son disque principal avec le chargement d'OPNsense.

Configuration OPNsense

Pour procéder à la 1ère configuration de la solution OPNsense :

Se rendre dans les détails de l'instance.
Puis console VNC dans le 2nd onglet.

Dans un prochain article, je traiterai de la configuration des interfaces avec une IP FailOver, la mise en place d'un certificat SSL avec Let's Encrypt.

OPNsense : Configuration d’un VPN SSL Road Warrior avec PKI

Tue, 12 Jul 2022 23:21:48 +0200

Le but de cette documentation va être de configurer un serveur VPN dit SSL Road Warrior sur OPNsense (Un PFsense en mieux et totalement opensource :P). Les clients VPN pourront accéder à des ressources sur le réseau LAN distant de façon sécurisé.

Le serveur VPN sera OpenVPN et celui-ci sera configuré de façon à accepter les connexions sur le port HTTPS (TCP 443). De cette façon, l'accès pourra se faire de n'importe où car ce port n'est pas (ou très très très rarement) filtré sur une connexion standard à Internet.

Une autorité de certification sera créé pour délivrer un certificat afin de sécuriser les échanges.

Un exemple de configuration d'un client sous Windows 10 est traité à la fin.

Let's go !!!

Contexte

Voici la version utilisée d'OPNsense :

OPNsense 22.1.2_2-amd64
FreeBSD 13.0-STABLE
OpenSSL 1.1.1m 14 Dec 2021

Au niveau des interfaces de paramétrées :

LAN = 192.168.56.254/24
WAN = IP_PUBLIC

Aucune configuration particulière à été apportée après l'installation d'OPNsense à part l'adressage IP des interfaces WAN et LAN.

Tout le paramétrage sera à réaliser à travers l'interface web d'administration d'OPNsense.

PKI

Création de l’authorité de certification

Dans System (1), Trust (2), Authorities (3), cliquer sur + (4) pour ajouter une authorité de certification :
Sélectionner Create an internal Certificate Authority :

Je ne vais pas traiter la partie algorithme ni de type ou de longueur de clef. Je laisse les paramètres par défaut mais dans un contexte de production, il sera important de modifier ces différents paramètres.

Entrer une Descriptive name ainsi que le Common Name et les informations désirées.
Enregistrer la nouvelle authorité de certification :

Génération du certificat serveur

Dans Certificates (1), cliquer sur + (2) pour ajouter un nouveau certificat :
Sélectionner Create an internal Certificate :

Même remarque que précédement concernant la partie algorithme, clef...

Entrer une Descriptive name. Sélectionner le bon Certificate authority et le type Server Certificate.
Les informations provenant de l'authorité de certification doivent être pré-remplies.
Renseigner le Common Name :
Enregistrer le nouveau certificat :

OpenVPN

Dans VPN (1), OpenVPN (2), Servers (3), cliquer sur l'icône du Wizard (4) :

En passant par le wizard, il y aura la possibilité de créer automatiquement les 2 règles nécessaires pour autoriser le flux provenant des clients VPN.Sinon, il faudra les ajouter à la main, ça fonctionne très bien aussi.

Type de serveur d'authentification : Local User Access
Authorité de certification : OPNsense-CA
Certificat : OPNsense-VPN-Cert
Dans la partie General OpenVPN Server Information, renseigner les paramètres suivants :
Les clients se connecteront sur l'interface WAN d'OPNsense par le protocol TCP sur le port 443. Par défaut OpenVPN écoute sur le port 1194 en UDP. Pour que la connexion soit possible depuis n'importe quel réseau Internet, il faut bien modifier ce paramètre. C'est quasiment indétectablement par les pare-feux pour faire la différence avec du flux HTTPS (du stateful inspection permet de faire la différence).
Dans la partie Tunnel Settings, renseigner les paramètres suivants :
Dans IPv4 Tunnel Network, entrer le réseau virtuel qui sera attribué aux clients VPN.
Dans IPv4 Local Network, entrer le réseau LAN qui doit être accessible aux clients VPN.

Le reste des paramètres sont laissés par défaut. Ils pourront être définis si besoin mais ne seront pas traités dans cet article.

Passer à la prochaine étape en cliquant sur Next.
Cocher Firewall Rule et OpenVPN Rule pour générer les 2 règles adéquats dans le pare-feu :
Valider en cliquant sur Next puis Finish pour terminer le paramétrage du serveur VPN.

Utilisateur

Création d’un utilisateur

Dans System (1), Access (2), Users (3), cliquer sur + (4) pour ajouter un nouveau utilisateur :
Renseigner un Username et un Password :
Plus bas, cocher Click to create a user certificate :
Terminer en cliquant sur Save. Cela déclenche la génération d'un certificat.

Génération du certificat utilisateur

Sélectionner Create an internal Certificate :
Entrer une Descriptive name. Sélectionner le bon Certificate authority et le type Client Certificate.
Les informations provenant de l'authorité de certification doivent être pré-remplies.
Renseigner le Common Name.
Enregistrer le nouveau certificat.
Le certificat est maintenant associé à l'utilisateur :
Terminer en cliquant sur Save.

Client Windows

Exportation de la configuration client

Dans VPN (1), OpenVPN (2), Client Export (3), télécharger l'archive contenant la confirmation client d'OpenVPN avec le certificat utilisateur correspondant :

En cochant Windows Certificate System Store, un certificat .crt est récupéré. Malgré le faites de l'inscrire (ou d'inscrire le CA) dans le magasin (des certificats de l'ordinateur) des autorités de certification racines de confiance, celui-ci ne sera pas approuvé.

Le contenu de l'archive récupérée contient les éléments suivant :

OPNsense_VPN_Server_batman_vpn-tls.key
OPNsense_VPN_Server_batman_vpn.ovpn
OPNsense_VPN_Server_batman_vpn.p12

Installation du client

Sur le poste client en Windows 10 :

Télécharger le client OpenVPN Community : https://swupdate.openvpn.org/community/releases/OpenVPN-2.5.7-I602-amd64.msi
Installer le client OpenVPN (Attention, il faudra des droits d'administrateur sur le poste Windows).
Un message d'avertissement indique qu'il n'y a aucun profil de connexion.
Copier le contenu de l'archive préalablement exporter dans le répertoire %USERPROFILE%\OpenVPN\config :
Se connecter :
Un message peut survenir indiquant que l'utilisateur Windows doit faire partie du groupe local de la machine OpenVPN Administrators :

Si contexte de domaine, une GPO peut appliquer ce paramètre automatiquement.

S'identifier avec le compte utilisateur créé précédement dans OPNsense :
La connexion VPN est établie :

Opnsense on slash-root.fr

OPNsense : Serveur WireGuard et client KDE en split tunnel

Prérequis

Partie 1 : OPNsense, le serveur WireGuard

Création de l’instance

Création du peer client

Méthode alternative : le Peer Generator

Activation de WireGuard

Assigner une interface (recommandé)

Règles firewall

1. Autoriser les connexions entrantes sur le WAN

2. Autoriser le trafic depuis le tunnel vers le LAN

Normalisation MSS (optionnel mais fortement recommandé)

NAT outbound

Partie 2 : KDE, le client WireGuard

Génération des clés

Fichier de configuration wg0.conf

Import dans NetworkManager

En ligne de commande (plus fiable)

En graphique (KDE Plasma)

Vérifications

Conclusion

OPNsense : Configuration du NAT Reflection

Configuration des options du NAT Reflection

Cas d’utilisation

Points d’attention

Application des changements

Conclusion

OPNsense : Block malicious IPs

Mise en place d’un alias

Augmenter le nombre d’entrées

Configuration des règles du firewall

OPNsense : Déploiement d’une instance sur OVHcloud [Partie 2/2]

Configuration IP

1er démarrage

Se connecter

Assignation des interfaces

Paramétrage IP

Interface web

1ère connexion

Filtrage

Mot de passe root

Hostname, Timezone…

Sécurité

Mise à jour

Certificat SSL Let’s Encrypt

Installation du client

Activation du plugin

Création du compte Let’s Encrypt

Enregistrement DNS

Paramétrage du challenge

Automatisation

Génération du certificat

Vérification

Application du certificat

OPNsense : Déploiement d’une instance sur OVHcloud [Partie 1/2]

Préparation de l’instance OVHcloud

Contexte

Création d’un vRack

Création de l’instance

Installation OPNsense

Démarrage en mode rescue

Récupération de l’ISO d’OPNsense

Mise en place QEMU/VNC

Démarrage de l’installation d’OPNsense

Configuration OPNsense

OPNsense : Configuration d’un VPN SSL Road Warrior avec PKI

Contexte

PKI

Création de l’authorité de certification

Génération du certificat serveur

OpenVPN

Utilisateur

Création d’un utilisateur

Génération du certificat utilisateur

Client Windows

Exportation de la configuration client

Installation du client

Fichier de configuration `wg0.conf`