Illustration générée par IA — visuel conceptuel.
Dès qu’un projet KNX utilise l’IP (interface KNX/IP, routeur IP, serveur de supervision, GTB/BMS…), on introduit des mécanismes « IT » (adressage, segmentation, multicast, règles firewall, accès distant) qui n’existent pas sur un bus KNX TP isolé. Dans de nombreux projets, les incidents ne viennent pas du KNX lui‑même, mais d’une exposition inutile sur Internet, d’un mauvais placement réseau, ou d’une recette incomplète.
L’objectif de cet article est simple : vous aider à placer correctement les interfaces KNX/IP, segmenter, éviter la redirection de ports, organiser un accès distant via VPN et recetter les modes dégradés, en villa comme en tertiaire.
Pourquoi KNX/IP devient (souvent) le point faible
KNXnet/IP n’est pas « dangereux » en soi. Le problème apparaît quand on traite une interface KNX/IP comme un objet connecté « comme un autre » : même LAN que les utilisateurs, règles firewall permissives, exposition Internet « pour dépanner », etc.
La logique à retenir est la suivante :
- KNX Secure renforce la sécurité des communications KNX, mais ne remplace pas un design réseau : segmentation, firewall, gouvernance des accès et recette restent indispensables. Pour cadrer KNX Secure (Data Secure / IP Secure), voir notre guide KNX Secure.
- Une interface IP exposée dans un LAN non maîtrisé, ou pire via une redirection de port Internet, devient un point d’entrée possible vers des fonctions de bâtiment (éclairage, stores, CVC, scénarios).
Rappels utiles : interface KNX/IP, routeur KNX/IP et KNXnet/IP
Interface KNX/IP vs routeur KNX/IP : ne pas confondre
- Interface KNX/IP : sert principalement à connecter ETS et les outils de maintenance/supervision au bus KNX via KNXnet/IP (souvent en « tunneling »).
- Routeur KNX/IP : ajoute une fonction de « routage » KNXnet/IP (backbone IP) pour relier des segments KNX via Ethernet.
Deux constantes à connaître (et à protéger)
- Port 3671 : port par défaut associé à KNXnet/IP. Selon l’équipement et le mode, les échanges peuvent utiliser UDP et/ou TCP (à confirmer dans ETS et la documentation du produit concerné).
- 224.0.23.12 : adresse multicast associée à KNXnet/IP (référencée pour KNXnet/IP).
Conséquence pratique : « ouvrir ce qu’il faut » dans un firewall (ou pire : sur le routeur Internet) ouvre souvent exactement ce qu’il ne faut pas ouvrir.
Erreurs fréquentes : ce qui cause le plus de risques (et de tickets)
Erreur n°1 — Redirection de port (NAT) vers l’interface KNX/IP
Le scénario classique : une box Internet a une règle NAT vers l’interface KNX/IP « pour que l’intégrateur puisse intervenir ». Une erreur courante consiste à laisser cette règle en place durablement, sans échéance, sans supervision, et sans procédure de fermeture.
Recommandation de projet : éviter l’exposition directe et organiser l’accès distant via un VPN (voir plus bas).
Erreur n°2 — Mettre KNX/IP sur le même LAN que tout le reste (ou sur le Wi‑Fi invités)
Lorsque l’interface KNX/IP partage le réseau des PC utilisateurs, des objets connectés non maîtrisés, des TV, ou du Wi‑Fi invités, on multiplie les surfaces d’attaque potentielles. L’enjeu n’est pas de « cacher » le KNX : c’est de limiter qui peut parler à quoi, et quand.
Pour une méthode simple de séparation par usages (domotique, caméras, invités, admin…), voir VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ?.
Erreur n°3 — Multicast KNXnet/IP : propagation L2 trop large… ou découverte cassée
Deux problèmes opposés existent :
- Propagation trop large : des flux KNXnet/IP (découverte et/ou routage selon l’architecture) se retrouvent visibles sur des segments où ils n’ont aucune raison d’être.
- Fonctionnement cassé : découverte ETS instable, routage KNXnet/IP instable, ou « interfaces invisibles » alors que le bus KNX est sain.
Point technique important pour éviter une mauvaise lecture : l’adresse 224.0.23.12 appartient au bloc 224.0.0.0/24, généralement traité comme un multicast de portée locale (link‑local). Dans un projet, un problème “trop ouvert” concerne donc le plus souvent des situations de propagation au sein d’un même domaine L2/VLAN (erreurs de VLAN/trunk, pontage non voulu, absence d’IGMP snooping entraînant un flood, etc.), plutôt qu’un « routage L3 normal vers n’importe où ».
Recommandation de projet : documenter clairement :
- dans quels VLAN/segments KNXnet/IP doit être visible (périmètre “automation”),
- quels équipements réseau doivent gérer correctement IGMP/multicast sur ces segments,
- et quels segments doivent au contraire rester hermétiques (utilisateurs, invités, IoT non maîtrisé).
Erreur n°4 — Accès distant « bricolé » (comptes partagés, pas de bastion, pas de journalisation)
Un VPN sans gouvernance reste un risque : si « n’importe quel laptop connecté au VPN » peut atteindre l’interface KNX/IP, on élargit inutilement la surface d’attaque et on complique la traçabilité.
Architecture recommandée (villa) : simple, robuste, sans port ouvert
Objectif
- Les fonctions KNX essentielles restent locales (pas dépendantes d’Internet).
- L’accès distant existe, mais uniquement via VPN.
- KNX/IP est segmenté (VLAN/zone dédiée) et filtré.
Schéma logique (principe)
Internet
|
[Routeur / Firewall]
- serveur VPN
- aucun NAT vers KNX
|
+-----------+-----------+
| |
VLAN Admin/IT VLAN Automation (KNX)
(poste ETS / bastion) (KNX/IP, superviseur)
| |
[Bastion ETS] [Serveur supervision]
|
[Interface ou routeur KNX/IP]
|
KNX TP
Ce que cette architecture change concrètement
- Un incident sur le Wi‑Fi invités ne donne pas automatiquement un chemin vers KNX/IP.
- Le support distant est possible, mais « sous contrôle » (VPN + règles).
- La maintenance est plus simple à auditer (on peut vérifier qu’il n’existe pas de port‑forwarding).
Architecture recommandée (tertiaire) : backbone IP maîtrisé, zones OT, interfaces contrôlées
En tertiaire (bureaux, commerces, hôtellerie, multi‑locaux techniques), on retrouve souvent :
- plusieurs segments KNX (par étage/zone),
- un backbone IP,
- des interfaces vers GTB/BMS, CVC, contrôle d’accès, vidéosurveillance, etc.
La règle d’or : traiter le réseau « automation » comme un réseau technique (OT) avec segmentation, filtrage et gouvernance. Pour une vision d’architecture IP convergée côté exploitation (notamment en hôtellerie), voir Architecture réseau IP d’un hôtel : comment faire cohabiter Wi‑Fi, IPTV, VoIP, CCTV et GRMS ?.
Accès distant KNX : ce qu’on recommande (et ce qu’on évite)
À éviter : NAT/port‑forwarding « temporaire »
- Redirection du port KNXnet/IP vers Internet.
- Ouverture large « pour dépanner » sans procédure de fermeture.
À privilégier : VPN + bastion + droits minimaux
- VPN sur firewall/routeur du site, avec comptes individualisés et possibilité de retrait rapide.
- Bastion (poste/VM) dans le VLAN Admin : c’est le seul point depuis lequel ETS et les outils d’exploitation atteignent KNX/IP.
- Fenêtrage des règles : quand c’est possible, activer des règles « maintenance » sur créneau (procédure + journalisation), plutôt qu’un accès permanent.
Pour cadrer la continuité d’accès Internet (et recetter une bascule WAN sans interrompre tous les services), voir Deux connexions Internet : comment assurer le failover d’une entreprise ou d’un hôtel ?.
Règles firewall “types” (squelette à adapter)
Les syntaxes varient selon les firewalls (Fortinet, Cisco, pfSense/OPNsense, etc.). L’objectif ci‑dessous est de donner une logique compréhensible, à valider avec l’IT/RSSI et l’intégrateur.
Règle absolue
- Refuser tout flux entrant depuis Internet (WAN) vers le VLAN/zone KNX (et donc vers le port 3671).
Accès ETS (maintenance)
- Autoriser uniquement depuis le bastion (VLAN Admin) vers l’interface KNX/IP, sur les flux strictement nécessaires (dont le port 3671, en UDP et/ou TCP selon l’équipement et le mode utilisé).
- Refuser le reste (tout autre poste, tout autre VLAN).
Multicast / IGMP (découverte et routage)
- Permettre IGMP/multicast là où c’est nécessaire (périmètre automation), sans « ouvrir » vers les VLAN utilisateurs/Invités.
- Documenter précisément où le multicast est attendu (et donc où une erreur de configuration peut « casser » la découverte ETS) et où il doit au contraire être absent.
- En cas d’instabilité, distinguer explicitement : (a) un sujet de propagation L2 (flood, trunk, VLAN, IGMP snooping) et (b) un sujet de design L3 (si vous cherchez à faire traverser des sous-réseaux à certains flux multicast, ce qui se spécifie et se recete au cas par cas).
Recette : tester les modes dégradés (le vrai différenciant en exploitation)
Une architecture peut être “belle sur plan” et fragile en production si les modes dégradés n’ont jamais été testés. La recette doit distinguer : perte Internet, perte VPN, panne de switch, panne d’un service réseau, problème multicast.
Checklist de recette (exemples de tests concrets)
- Internet coupé (WAN down) : les fonctions KNX locales restent-elles utilisables (commandes murales, scènes, CVC selon architecture) ?
- VPN indisponible : aucune administration extérieure ne doit “tomber” en accès direct ; l’exploitation locale doit rester possible.
- Multicast perturbé (erreur volontaire sur IGMP / VLAN en environnement de test) : quel est le symptôme observé (découverte ETS, stabilité du routage) et comment le diagnostiquer ?
- Redémarrage d’un switch : retour à l’état nominal, cohérence des règles, absence de « fail‑open ».
- Test de segmentation : depuis un VLAN non autorisé (ex. invités), vérifier qu’il est impossible d’atteindre l’interface KNX/IP.
Livrables à exiger (pour sécuriser la maintenabilité)
- Schéma d’architecture IP (VLAN, sous‑réseaux, emplacement des interfaces KNX/IP, chemin d’accès VPN).
- Règles firewall documentées (au moins les principes et les exceptions).
- Procédure d’accès distant (qui a accès, comment on le retire, comment on journalise).
- DOE et sauvegardes : pour cadrer la remise documentaire, voir DOE domotique : quels documents et sauvegardes le client doit-il recevoir ?.
Mini-checklist d’audit “cyber KNX/IP” (lecture rapide)
- Existe‑t‑il une exposition Internet (NAT/port‑forwarding/UPnP) vers KNX/IP ? Si oui : à corriger en priorité.
- L’interface KNX/IP est‑elle dans un VLAN/segment dédié (automation), filtré ?
- L’accès distant passe‑t‑il par un VPN (avec bastion et droits minimaux) ?
- Les flux multicast/IGMP attendus sont‑ils documentés et contenus au bon périmètre ?
- Les modes dégradés (WAN/VPN/switch/multicast) ont‑ils été testés et consignés ?
Pour aller plus loin (maillage utile)
- KNX Secure : comment sécuriser une installation domotique professionnelle ?
- VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ?
- Architecture réseau IP d’un hôtel : cohabitation des services et segmentation
- Failover Internet : concevoir et recetter une bascule WAN
Si vous suspectez une exposition Internet, un réseau insuffisamment segmenté, ou une architecture KNX/IP difficile à maintenir, un audit ciblé (réseau + KNX + accès distant + recette des modes dégradés) permet généralement d’identifier rapidement les corrections prioritaires, puis de planifier une mise à niveau sans perturber l’exploitation. Pour cadrer un projet Smart Home/KNX dès les études (villa), vous pouvez aussi consulter Domotique / Smart Home.
