Vpn 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 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 :