KNX Backbone Security: Network Segmentation, VLAN Design and IP Firewall Rules
KNX IP shares the building Ethernet infrastructure — without dedicated network segmentation, any device on the corporate LAN can reach KNXnet/IP port 3671 and potentially control lighting, blinds, HVAC and door locks. Network segmentation is the first and most effective layer of KNX backbone protection.
Why KNX backbone security matters
KNXnet/IP routing and tunnelling run on standard UDP/TCP over Ethernet using port 3671. Without network segmentation, KNX IP devices are accessible from any host on the building LAN — including employee laptops, guest Wi-Fi devices, and any IoT device connected to the same network. The consequences range from nuisance interference to a serious physical security breach.
| Threat scenario | Attack vector | Mitigation |
|---|---|---|
| Insider occupancy surveillance | Sniff KNXnet/IP multicast on LAN — learn occupancy patterns from motion sensor GAs | KNX IP Secure encryption + VLAN containment of multicast |
| Unauthorised building control | Send KNXnet/IP write telegram from laptop to door lock GA | KNX IP Secure authentication + VLAN isolation + firewall |
| Bus device injection | Physically connect rogue KNX device to TP bus — inject telegrams | KNX Data Secure on sensitive GAs + physical TP bus security |
| Remote exploitation | Expose port 3671 to internet — automated scanning tools find it | No internet exposure; VPN for remote access only |
VLAN design for KNX IP backbone
A dedicated VLAN for all KNX IP devices isolates KNXnet/IP traffic from the corporate LAN and guest networks. Managed switches with VLAN support are required — consumer-grade unmanaged switches cannot implement this separation.
Recommended VLAN structure for commercial building
VLAN 10 — Corporate LAN Employee workstations, printers, VoIP phones DHCP from corporate DHCP server Internet access: full (via firewall) VLAN 20 — Guest Wi-Fi Visitor devices, bring-your-own-device Internet access only, isolated from all other VLANs No access to corporate LAN, KNX VLAN, or IoT VLAN VLAN 30 — IoT Sensors Building sensors (CO2, temperature, occupancy — IP type) No access to KNX VLAN or corporate LAN Data collected to BMS server only (explicit allow rule) VLAN 100 — KNX Automation ← dedicated KNX VLAN All KNX IP routers (by floor and line) All KNX IP tunnelling interfaces HomeServer / ARISTO / Gira X1 visualisation servers DALI gateways with IP connectivity ETS6 commissioning laptop (during commissioning only) Switch port configuration: KNX IP router ports: access mode, VLAN 100 untagged Server ports (HomeServer, X1): trunk mode, VLAN 10 + 100 Commissioning port: access mode, VLAN 100 (remove after handover) Uplink to firewall: trunk mode, all VLANs tagged
IP addressing for KNX devices
All KNX IP devices must use static IP addresses. DHCP-assigned addresses change on lease renewal — a KNX IP router that changes IP address loses its routing table entries and breaks KNXnet/IP routing for the line it serves until manually reconfigured. Static addressing prevents this failure mode.
KNX VLAN IP address plan (example)
Subnet: 192.168.100.0/24 (KNX VLAN 100) Gateway: 192.168.100.254 (firewall inter-VLAN interface) KNX IP routers — by floor and line: .1 — Ground floor, line 1 (KNX area 1.1) .2 — Ground floor, line 2 (KNX area 1.2) .10 — First floor, line 1 (KNX area 2.1) .11 — First floor, line 2 (KNX area 2.2) .20 — Second floor, line 1 (KNX area 3.1) (continue per floor/line combination) Servers and gateways: .100 — Gira HomeServer / ARISTO server .101 — Gira X1 (if separate from HomeServer) .102 — DALI gateway (if IP-connected) .103 — KNX to BACnet / Modbus gateway Commissioning devices (temporary): .200 — ETS6 commissioning laptop (remove after handover) .201 — Thermography camera / test laptop Document IP plan in: Building technical manual (as-installed) Network diagram (Visio or draw.io, stored with O&M documentation) ETS6 project: each IP router properties → IP address field
KNXnet/IP routing multicast and IGMP
KNXnet/IP routing uses IP multicast to broadcast routing telegrams between all IP routers on the backbone. Without IGMP snooping, multicast floods all switch ports — including corporate LAN ports — allowing any host to receive KNX routing telegrams even without VLAN segmentation.
KNXnet/IP multicast configuration
KNXnet/IP routing multicast address: 224.0.23.12 (IANA assigned) UDP port: 3671 All KNX IP routers join and send to this multicast group IGMP snooping — required on KNX VLAN switch: Enable IGMP snooping on VLAN 100 Function: switch tracks which ports have joined multicast group Result: multicast sent only to ports with KNX IP routers Without IGMP snooping: multicast floods ALL ports in VLAN 100 IGMP querier: Enable IGMP querier on the VLAN 100 switch or L3 interface Querier sends periodic IGMP membership queries KNX IP routers respond with IGMP join — switch maintains table Without querier: IGMP snooping table expires → multicast floods Multicast containment to VLAN 100: Firewall / L3 switch: block multicast routing between VLANs 224.0.23.12 should NEVER appear on VLAN 10 (corporate LAN) Verify: Wireshark capture on corporate LAN port → no 224.0.23.12 packets visible Alternative: KNXnet/IP unicast routing (newer installations) ETS6 6.x supports unicast routing between IP routers Avoids multicast entirely — better for strict networks Requires compatible IP routers (check manufacturer support)
Firewall rules for inter-VLAN access
The firewall enforces access control between VLANs. The default policy for KNX VLAN access must be deny-all — only explicitly permitted traffic flows between the corporate LAN and the KNX VLAN. Every permitted rule should be documented with a business justification.
Firewall rule set — KNX VLAN (VLAN 100)
Default policy: DENY ALL (inbound and outbound) ALLOW rules (corporate LAN VLAN 10 → KNX VLAN 100): Source: engineering workstation subnet (192.168.10.50-60) Dest: HomeServer (192.168.100.100) Port: TCP 443 (HTTPS) — visualisation access Log: YES, all connections Source: ETS6 commissioning laptop (192.168.100.200) Dest: all KNX IP routers (192.168.100.1-.30) Port: UDP/TCP 3671 — ETS6 programming Note: commissioning rule only — remove after handover Log: YES, all connections DENY rules (explicit — logged for audit): Source: any VLAN 10 host Dest: KNX VLAN 100 Port: UDP 3671 — all other KNXnet/IP access Action: DENY + LOG ALLOW rules (KNX VLAN 100 → internet/management): Source: HomeServer (192.168.100.100) Dest: NTP server (pool.ntp.org or internal NTP) Port: UDP 123 Source: HomeServer (192.168.100.100) Dest: Gira cloud (for Gira X1 remote feature) Port: TCP 443 (HTTPS outbound only) DENY rules (KNX VLAN → internet, all other): Source: KNX IP routers (192.168.100.1-.30) Dest: any internet Action: DENY (KNX IP routers should not reach internet) Log: YES — alert if any router attempts internet connection
Physical bus security
Physical access to the KNX TP bus allows an attacker to connect a monitoring device or a rogue KNX device. Network segmentation and KNX IP Secure do not protect against physical TP bus attacks — physical access controls are required as a complementary measure.
Physical TP bus access controls
- Cable risers and plant rooms: locked (key or card access)
- Junction boxes in accessible areas: tamper-evident seals or locked enclosures
- KNX programming sockets: key-switch activated or locking RJ45 (only energised for programming sessions)
- Exposed cable trays: secure to prevent clip-on bus monitors
- KNX panels: IP54 rated enclosure, padlock or key lock
Topology change detection
KNX IP routers (MDT SCN-IP100.02, ABB IPS/S) support syslog output including bus topology events. Configure: alert on any new individual address appearing on the bus that is not in the ETS6 programming table.
Scheduled ETS6 topology scan (monthly): compare against last baseline scan. Any new device appearing without a programming event is a potential security incident. Document scan results and changes.
Remote access security
Remote ETS6 programming access is required for maintenance and system updates. This access must never be implemented by opening KNXnet/IP port 3671 to the internet — automated scanning tools find open ports within minutes and KNXnet/IP has no built-in authentication without IP Secure.
Secure remote access design
Recommended: VPN to management VLAN → ETS6 via KNX VLAN VPN gateway options: WireGuard: modern, fast, cryptographically strong (ChaCha20) OpenVPN: established, widely supported, certificate-based IPsec IKEv2: enterprise standard, compatible with Windows/macOS VPN authentication: certificate (client cert) + password (2FA) Never: username + password only (too weak for building access) MFA options: TOTP (Google Authenticator), FIDO2 hardware key Access flow: Engineer → VPN (WireGuard, certificate + TOTP) → Management VLAN gateway → Firewall allow: engineer VPN IP → KNX VLAN 100 port 3671 → ETS6 connects to KNX IP router via IP Secure tunnelling → Programming session (authenticated and encrypted) Log all VPN connections: Source IP, VPN user, connect time, disconnect time Send to SIEM or centralised log server Alert on: off-hours connections, unusual source IPs, multiple failed authentication attempts Alternative (if Gira X1 in design): Gira X1 Remote Access feature: proprietary encrypted tunnel via Gira cloud infrastructure — no VPN gateway required Authentication: Gira account with 2FA Acceptable for ETS6 tunnelling IF X1 already in design
Monitoring and anomaly detection
Active monitoring of KNX IP routers enables detection of security anomalies in near-real time. KNX IP routers with syslog output can feed events into a SIEM platform for correlation and alerting — required for NIS2-regulated buildings and ISO 27001 certified operations.
KNX monitoring and SIEM integration
KNX IP router syslog configuration (MDT SCN-IP100.02):
Enable: syslog output (UDP 514 to log server)
Log events:
- New device individual address on bus (topology change)
- Programming mode activation (ETS6 download started)
- Bus restart / reset events
- IP Secure authentication failures (if IP Secure enabled)
- High telegram rate events (potential bus flooding)
SIEM platforms (forward KNX syslog):
Splunk: KNX IP router syslog source → custom alert rules
Elastic SIEM: Filebeat agent ingests syslog → Kibana alerts
Wazuh (open source): agent-based, lower cost for small buildings
Alert rules for security events:
New KNX individual address on bus (not in programming session):
→ Alert: "Possible rogue KNX device detected"
→ Action: initiate ETS6 topology scan, physical inspection
Programming mode activation outside maintenance window:
→ Alert: "Unscheduled ETS6 download detected"
→ Action: verify with on-site engineer
High telegram rate (> 2× normal baseline for 60 seconds):
→ Alert: "Possible KNX bus flooding attack"
→ Action: check IP Secure log for auth failures
IP Secure authentication failure (> 3 in 10 minutes):
→ Alert: "Repeated IP Secure auth failure — possible brute force"
→ Action: block source IP at firewall pending investigationCompliance documentation
NIS2 Directive (EU) and equivalent national regulations require organisations operating critical infrastructure to maintain documented cyber security measures covering building automation and control systems (BACS). KNX backbone security design must be documented as part of the building’s cyber security management system.
Documentation deliverables
- KNX VLAN diagram (as-installed, with IP addressing)
- Firewall rule set (exported from firewall management interface)
- IP address plan (all KNX IP devices, static assignments)
- Physical security measures (cable riser access control plan)
- Remote access procedure (VPN setup, authorised users)
- SIEM alert rule list and escalation contacts
Annual review requirements
- Verify firewall rules match current design (no ad-hoc changes)
- Verify all KNX IP devices on correct VLAN (network scan vs. IP plan)
- ETS6 topology scan: compare against baseline, investigate new devices
- ETS6 project backup restore test (verify backup integrity)
- VPN authorised user list review (remove ex-employees)
- Provide review findings to client CISO for risk register update
Need a KNX backbone security design for your commercial building?
We design KNX network segmentation with dedicated VLAN, IGMP snooping configuration, inter-VLAN firewall rules, VPN remote access and SIEM monitoring — fully documented for NIS2 and ISO 27001 compliance.
Request a quote →