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.

KDE : double-clic sur un ISO pour le monter

Tue, 23 Jun 2026 00:00:00 +0000

Sous KDE, double-cliquer sur un .iso ouvre Ark. C’est le comportement par défaut, et c’est chiant quand on veut juste monter l’image pour parcourir son contenu.

Le problème vient de l’association MIME. On peut le confirmer :

xdg-mime query default application/x-iso9660-image

Ça retourne org.kde.ark.desktop. Ark est déclaré handler par défaut au niveau système pour ce type MIME, et KDE suit ça à la lettre.

La solution

L’idée, c’est de créer un .desktop qui monte l’ISO via udisksctl et ouvre Dolphin sur le point de montage, puis de l’enregistrer comme handler MIME. Avec NoDisplay=true, il ne remonte pas dans le menu des applications, il n’existe que pour ça.

Créer : ~/.local/share/applications/iso-mount.desktop

[Desktop Entry]
Type=Application
Name=Monter l'image ISO
Exec=bash -c 'DEV=$(udisksctl loop-setup -f "%f" | grep -oP "/dev/loop\d+"); sleep 0.5; udisksctl mount -b "$DEV"; dolphin /run/media/$USER/'
Icon=media-optical
MimeType=application/x-iso9660-image;application/x-cd-image;
NoDisplay=true
Terminal=false

Ensuite on enregistre l’association :

update-desktop-database ~/.local/share/applications/
xdg-mime default iso-mount.desktop application/x-iso9660-image
xdg-mime default iso-mount.desktop application/x-cd-image

Sous KDE 6, xdg-mime peut cracher un qtpaths: commande introuvable. C’est un bug connu, ça n’empêche pas l’association d’être écrite correctement dans ~/.config/mimeapps.list.

On vérifie :

grep -i iso ~/.config/mimeapps.list

application/x-iso9660-image=iso-mount.desktop
application/x-cd-image=iso-mount.desktop

À partir de là, un double-clic sur un .iso dans Dolphin monte l’image et ouvre le répertoire directement. Pour démonter, clic droit sur le périphérique dans le panneau latéral → Démonter.

slash-root.fr