KNXnet/IP Routing: IP Interfaces vs IP Routers Explained
KNXnet/IP is the standard for connecting KNX TP to IP networks — used for remote programming, visualisation access and large multi-line installations with IP backbones. Two device types do completely different things: IP interface and IP router. Specifying the wrong one for the wrong task is one of the most frequent mistakes in KNX design.
IP Interface vs IP Router: full comparison
Both devices connect KNX TP to the IP network, but their roles in the topology are fundamentally different. An IP interface gives an engineering laptop access to one TP line. An IP router bridges two network segments — it is a structural node in the KNX topology, not just an access point.
| Feature | IP Interface | IP Router | IP Backbone Router |
|---|---|---|---|
| Function | Access to one TP line from IP | Bridge two TP segments | Connect areas via IP backbone |
| Physical address | Yes | Yes | Yes (area coupler PA) |
| Group address filtering | No | Yes | Yes |
| Telegram forwarding | All to connected TP line | Filtered between segments | Filtered via IP multicast |
| Tunneling connections | Yes (1–4 simultaneous) | Yes (up to 4) | Yes (up to 4) |
| IP routing (multicast) | No | Yes | Yes — 224.0.23.12 |
| ETS programming access | Yes | Yes | Yes |
| ETS discovery (UPnP) | Yes | Yes | Yes |
| Line coupler function | No | Yes (TP-to-TP) | Yes (TP-to-IP) |
| Typical cost | Low — €50–100 | Medium — €120–180 | High — €150–250 |
| Example model | Weinzierl KNX IP 730 | MDT SCN-IP001.03 | MDT SCN-IP200.02 |
KNXnet/IP Core: tunneling vs routing
KNXnet/IP Core (specified in IEC 61499 and the ETS standard) defines two distinct communication modes. Understanding these determines which device type the project needs and how ETS discovers and communicates with devices.
Tunneling (unicast)
- • Transport: unicast UDP/TCP to a specific IP address and port
- • Purpose: engineering access — ETS downloads, reads, monitoring
- • One session at a time per tunneling connection (up to 4 simultaneous)
- • ETS discovers tunneling devices via UPnP on the LAN
- • Used by: IP interfaces and IP routers equally
- • Latency: minimal — direct unicast to the IP address
Routing (multicast)
- • Transport: multicast UDP to 224.0.23.12 port 3671 (IANA registered)
- • Purpose: IP backbone — all IP routers receive all multicast telegrams
- • Each IP router filters by its group address table — forwards only relevant telegrams to its TP line
- • Requires managed switch with IGMP snooping and multicast enabled
- • Used by: IP routers only — IP interfaces do not route
- • Latency: <5ms typical on a well-configured LAN
KNXnet/IP multicast address and port
Multicast group: 224.0.23.12 (IANA assigned for KNX) UDP port: 3671 (IANA assigned for KNX) Protocol: UDP — connectionless, low overhead Scope: Link-local multicast — same VLAN only For routing between VLANs: Managed core switch must enable multicast routing between VLAN 10 (KNX backbone) interfaces IGMP snooping must be enabled on all switches to prevent multicast flooding to non-KNX ports
MDT KNX IP Router SCN-IP200.02
The MDT SCN-IP200.02 is the most specified KNXnet/IP router in Europe for commercial and residential installations. It combines line coupler and IP backbone router in a single 2TE DIN rail device.
Technical specification
- • 4 simultaneous tunneling connections (ETS, visualisation, logic)
- • Line coupler + IP router in one device
- • Group address filter table: 1,000 entries
- • Physical address: configurable as 0.0.0 (backbone) or area/line coupler
- • KNXNET/IP Secure (AES-128) supported
- • ETS6 direct configuration — no separate software
- • Power: KNX bus or external 12–24V DC
- • DIN rail 2TE, 35mm rail, standard panel mounting
Physical address assignment
- 0.0.0 (backbone coupler): connects a TP line directly to the IP backbone. Use when this is the only router on that segment.
- X.0.0 (area coupler): connects area X to the backbone. All sub-lines in area X route via this router.
- X.Y.0 (line coupler): connects line Y in area X. Used when the router is embedded within an area line hierarchy.
Weinzierl KNX IP Interface 730
The Weinzierl 730 is a compact IP interface for engineering access. It does not route — it provides a tunneling connection from the IP network to a single KNX TP line.
Specification and use cases
- • 4 tunneling connections — ETS6 programming access
- • No routing capability — does not forward telegrams between segments
- • DIN rail 2TE — minimal panel space
- • ETS6 programming: yes (configures via tunneling)
- • IP address: static or DHCP
- • Power: KNX bus only (no external supply needed)
Use the Weinzierl 730 when:
- • Simple programming access from laptop is the only requirement
- • Small project with a single TP line
- • Remote access via OpenVPN + ETS6
- • Visualisation server (Home Assistant, KNX Vision) is on the same LAN
- • No IP backbone needed — all devices on one line
Remote access via OpenVPN
KNX IP devices must never be exposed directly to the internet. The correct architecture for remote ETS6 access is an OpenVPN tunnel from the engineer's office to the site router, which then provides LAN access to the KNX IP device.
Remote access architecture
Engineer laptop (office)
│
│ OpenVPN tunnel (encrypted)
▼
Site router / firewall
OpenVPN server — assign engineer IP in 10.8.0.x
│
│ LAN — 192.168.1.0/24
▼
KNX IP Interface / Router
IP: 192.168.1.50 (static — always assign static IP)
Port 3671 UDP — KNXnet/IP (LAN only, NOT forwarded externally)
│
│ KNX TP
▼
KNX installation
ETS6 on engineer laptop:
Discovers 192.168.1.50 via UPnP over VPN
Opens tunneling connection on port 3671
Programs devices as if on-siteSecurity rule: Never forward UDP port 3671 from the internet directly to a KNXnet/IP device. KNXnet/IP has no authentication in standard mode — any device on the network can send telegrams and control the entire KNX installation. Use OpenVPN, WireGuard or equivalent. KNX Secure adds AES-128 but VPN is still required.
ETS6 project interface settings
ETS6 discovers KNXnet/IP devices via UPnP on the local network. For reliable operation, always assign a static IP address to every KNX IP device and name it clearly in ETS.
ETS6 interface configuration
- Open ETS6 → Interfaces tab (bottom bar)
- Discovered devices appear automatically via UPnP
- Double-click device → set static IP address
- Set device name (e.g. "Floor 2 IP Router")
- Set tunneling connection password (ETS6 Secure)
- Click "Set as programming interface"
- ETS connects — test with a bus monitor scan
Static IP assignment
- Why static: DHCP lease expiry changes the IP address and ETS loses the device. Always use static IP or DHCP reservation on the router.
- Subnet: all KNX IP devices on the same VLAN/subnet as the engineering laptop during commissioning.
- DNS name: optionally configure a local DNS name (e.g. knx-router-f2.local) for easy identification.
KNX Secure: encrypted communication
KNX Secure (IEC 62386 Part 57 for TP, Part 58 for IP) adds AES-128 encryption to KNX communication — preventing packet sniffing, replay attacks and spoofing. It is the mandatory standard for any KNX installation with cloud or remote access components.
KNX Data Security (TP)
- • AES-128 encryption on the TP bus
- • Per-device keys — configured in ETS6
- • Prevents sniffer devices reading telegrams
- • Requires KNX Secure certified devices
- • MDT, Gira, Weinzierl certified range
KNXnet/IP Secure (IP)
- • AES-128 on IP routing and tunneling
- • Tunneling: password-protected connections
- • Routing: encrypted multicast telegrams
- • Essential for cloud/remote access use cases
- • Configured in ETS6 → Project Settings → Security
Certified device examples
- • MDT SCN-IP200.02 — IP router, Secure certified
- • Gira X1 — IP interface, Secure certified
- • Weinzierl 830 — Secure tunneling interface
- • MDT AKD-0424V.02 — Secure actuator
- • ETS6 Security module required for project
KNX network infrastructure in your panel
We design panels with pre-configured KNXnet/IP routers, IP backbone patch bays and structured cabling termination — tested end-to-end before leaving the factory.
Request a quote →