CCU3 und WireGuard per Speedport

Um von unterwegs aus auf meine Heimautomatisation und die CCU3 zugreifen zu können, nutze ich eine VPN-Verbindung per WireGuard. Der Speedport Smart 4 (wie auch der Smart 3) haben die WireGuard-Verbindung bereits onboard. Mittels der App TinyMatic lässt sich die Steuerung der CCU3 bequem über Android vornehmen.

Seit irgendeinem Update war die CCU3 jedoch nicht mehr über die WireGuard-Vebindung erreichbar. Die Verbindung ins heimische LAN funktionierte einwandfrei und auch der Zugriff von innerhalb des LAN auf die CCU3. Also Firewall-Einstellungen in der CCU3-Systemsteuerung geprüft. Für Homematic XML-RPC API und Remote Homematic-Script API war eingeschränkter Zugriff erlaubt. Als Netzwerke für den eingeschränkten Zugriff sind 192.168.0.0/24 und 10.200.200.0/24 eingetragen.

192.168.0.0/24 ist das heimische LAN. WireGuard-Verbindungen erhalten über den Speedport jedoch eine Adresse aus dem Netz 10.200.200.0/24. Der Speedport routet automatisch zwischen den beiden Netzen.

Um nun dem Problem näher auf die Schliche zu kommen, half nur SSH-Zugriff auf die CCU3. Dazu muss man in den CCU3-Einstellungen unter Sicherheit SSH aktivieren und ein Passwort vergeben (ist für root, also ein sicheres Passwort!).

Auf der Shell angelangt erstmal:

# ip addr show

IPv4-Adresse war sauber vergeben und sogar auch IPv6, obwohl das in der Weboberfläche gar nicht auftaucht. Seltsam war aber diese weitere Adresse:

inet 10.220.242.47 peer 10.220.0.1/32 scope global tun0

Das tun0 scheint ein virtueller Netzwerktunnel zu sein. eq-3, was treibt ihr da?

Also als nächstes Routing geprüft:

# ip route show

default via 192.168.0.1 dev eth0
10.200.0.0/16 via 10.220.0.1 dev tun0
10.220.0.1 dev tun0 scope link src 10.220.242.47
10.251.0.0/16 via 10.220.0.1 dev tun0
192.168.0.0/24 dev eth0 scope link src 192.168.0.19

Oha, alle Pakete für den Adressbereich 10.200.0.0/16 werden via 10.220.0.1 über tun0 geroutet.

Jetzt muss man die CDIR-Schreibweise der Netzwerke verstehen:

10.200.0.0/16  =  10.200.0.0 – 10.200.255.255

10.200.200.0/24 = 10.200.200.0 – 10.200.200.255

10.200.0.0/16 schließt auch den Adressbereich 10.200.200.0/24 der WireGuard-Verbindungen mit ein: /24 ist vollständig in /16 enthalten. Linux nimmt immer die spezifischste Route, aber es gibt keine alternative Route für 10.200.200.0/24 also greift die /16 → tun0

Das bedeutet, die CCU3 die eingehenden Pakete zwar korrekt empfangen und wollte diese auch beantwortet. Der Routingdienst hat diese jedoch nicht wieder über den Netzwerkadapter eth0 rausgeschickt, sondern über den ominösen tun0, wodurch die Antwort der CCU3 irgendwo, aber nicht beim per WireGuard verbundenen Gerät gelandet ist.

Also müssen wir die Routingtabelle um einen spezifischen Eintrag für das WireGuard-Netz erweitern:

# ip route add 10.200.200.0/24 via 192.168.0.1 dev eth0

Zum Testen dann:

# ip route get 10.200.200.5

Ergebnis: via 192.168.0.1 dev eth0
Test mit dem Handy über das Mobildatennetz und eingeschalterer WireGuard-Verbindung: ES GEHT!

Jetzt geht es noch darum die Route reboot-sicher auf der CCU3 zu machen. Aber: Die CCU3 (Buildroot + eQ-3-Magie) hat kein „normales“ /etc/network/interfaces, kein systemd, kein NetworkManager.
Viele klassische Linux-Wege funktionieren nicht oder werden beim Boot gnadenlos überschrieben. Jedoch unterstützt die CCU3 eigene Boot-Skripte. Alles, was dort liegt, wird nach dem Netzwerkstart ausgeführt.

# vi /etc/config/rc.d/S99wg-route

Mit Inhalt:

#!/bin/sh

# WireGuard-Subnetz sauber über LAN routen
ip route add 10.200.200.0/24 via 192.168.0.1 dev eth0 2>/dev/null

Sorry, ich steh aber mit vi auf Kriegsfuß. Und nano ist leider auf der CCU3 nicht vorhanden.

Kurzfassung zur vi-Bedienung: Nach der Eingabe ESC-Taste drücken und :wq eingeben und mit Enter bestätigen: vi speichert und beendet.

Wichtig, das Skript noch ausführbar machen:

# chmod +x /etc/config/rc.d/S99wg-route

Zum Testen die CCU3 einmal rebooted und der Zugriff per WireGuard funktioniert immernoch. Juhu!

Eine Frage bleibt: eQ-3, was habt ihr da für einen Tunnel auf meiner CCU3?

10.200.0.0/16
10.251.0.0/16

Sieht sehr nach eQ-3-internen Adresspools aus.