Fernverwaltung von LoRaWAN Gateways

Beim Einstieg in die LoRaWAN-Welt (Was ist LoRaWAN) hat man, wenn überhaupt, ein Gateway zu Hause. In der Regel muss man da auch nicht oft dran und wenn doch, geht das über das lokale Netzwerk. Wer allerdings mehrere Gateways betreibt, die in verschiedenen Netzten stehen oder sogar sogar über Mobilfunk/LTE verbunden sind, dann steht man vor einem größeren Problem.

Spätestens seit der Einführung vom The Things Network Stack in Version 3 steht fest, dass dieses Jahr noch alle Gateways von Version 2 auf Version 3 umgestellt werden müssen. Hierfür bedarf es zwar nur einer kleiner Änderung in der URL des LNS (LoRaWAN Network Server) aber wenn man nicht „mal eben“ an das Gateway kommt steht man vor einem massiven Problem. Zeitgleich bietet es nun die Möglichkeit das Thema Fernwartung mal anzupacken.

Das Problem

Die Kommunikationswege sind in der Regel so aufgebaut, dass die Gateways in einem LAN mit dem DSL-Router verbunden sind. Dieser stellt dann die Verbindung in das Internet her. In den meisten Fällen geht eine Kommunikation im Heimbereich von den Geräten in das Internet. Die Firewall im Router sorgt dafür, dass die Geräte von außen nicht erreicht werden dürfen. Des weiteren sorgt das NAT bei IPv4 dafür, dass man die Geräte im LAN von außen nicht andressiert bekommt. Durch Port-Weiterleitung (port forwarding) und Firewall-Freischaltung kann man Interne Netzwerkgeräte von außen zugänglich machen.

Diese Freischaltung birgt jedoch auch viele Risiken. Da die Geräte aus dem gesamten Internet erreichbar werden kann eine Sicherheitslücke viel weitreichendere Folgen haben. Gerade bei IoT-Geräten gilt der Merksatz: „Das S in IoT steht für Security!“. Des weiteren ist der Zugriff einzig über das Kennwort geschützt. So stehen zahlreiche Kameras, Netzwerkspeicher und viele weitere Geräte nahezu ungeschützt im Internet.

Des weiteren gibt es das Problem, dass einige Betreiber ein Carrier Grade NAT verwenden und man somit zumindest nicht via IPv4 auf das Gerät kommt. IPv6 wird zur Zeit noch nicht von allen Anbietern unterstützt.

Erschwert wird das ganze dadurch, dass die meisten Anschlüsse (sowohl DSL, Kabel als auch LTE) keine festen IP-Adressen verwenden. in dem Fall muss das Gerät einer weitern Stelle die aktuelle IP-Adresse mitteilen (DynDNS).

Diese Variante hat also zahlreiche Nachteile:

• Port-Weiterleitung nötig
• Firewall-Freischaltung nötig
• Zugriff auf die Router nötig
• Sicherheitsrisiko durch weltweiten Zugriff
• Erhöhter aufwand durch dynamische IP-Adressen
• Bei LTE werden Anfragen aus dem Internet blockiert

Der Aufwand steigt hier proportional zur Anzahl der Gateways, da bei jedem Gateway die gesamte Freischaltung neu gemacht werden muss. Bei Firmen wird das ggf. (zurecht) durch die IT unterbunden.

Wer schon in der Firma oder zu Hause über ein VPN auf das Netzwerk zugreifen kann, kann dies auch für die Fernwartung der Gateways nutzten. Hier muss jedoch unter umständen für jedes Gateway eine separate Zugriffsart verwendet werden. In der Praxis ist das bei der Verwaltung mehrerer Gateways so auch keine wirkliche Lösung.

Bei Gateways mit LTE-Anbindung gibt es die Möglichkeit eine Karte mit einem eigenen APN zu nutzten. Dadurch kann man das Gateway über eine feste, interne IP durch einen Tunnel im Mobilfunknetz erreichen. Dies Ist jedoch aufwendig, kostenintensiv und lässt sich auch eben nur für Gateways nutzen die über Mobilfunk angebunden sind.

Die Lösung

Die Lösung für das Problem ist eine zentrale Stelle zu denen die Gateways eine Verbindung aufbauen. Ich habe mich hierbei für die freie Firewall-Distribution OPNsense entschieden.

Der Server ist hierbei für alle Geräte die „Anlaufstelle“. Alle Geräte können eine Verbindung zum Server aufbauen, da die Geräte den „üblichen Weg“ ins Internet durch die Router und Firewalls nutzen können. Natürlich gilt dies auch für Geräte, die über das Mobilfunknetz angebunden werden.

Die Gateways bauen über diese Verbindung einen VPN-Tunnel auf und befinden sich somit virtuell einem Netzwerk.

Über dieses Virtuelle Netzwerk (VPN) kann der Administrator nun direkt auf die Gateways zugreifen. Durch Einstellungen in der Firewall des VPN-Servers kann genau bestimmt werden welches Gerät mit welchem Gerät was kommunizieren darf.

Einrichtung

Zunächst muss das Image von OPNsense auf einem Server installiert werden. Natürlich könntet ihr den Server auch zu Hause betreiben. Dort habt ihr in der Regel jedoch keine feste IP-Adresse und müsstet mit DynDNS arbeiten.

Ich empfehle die Verwendung einer kleinen virtuellen Maschine. Ich habe mich hierbei für eine VPS200 von Netcup entschieden. Die VM kostet 2,69 € pro Monat . Mit dem Gutscheincode: 36nc16100496680 bekommt ihr zusätzlich 5 € gut geschrieben. Alternativ kann ich euch auch einen 10% Gutschein zukommen lassen 😉

Installation

Für die Installation muss das Image als Bootmedium hochgeladen werden. In der KVM-Konsole sieht man die Ausgabe des Servers und kann die Installation durchführen.

Nachdem der Server das Image geladen hat muss man sich als „installer“ mit dem Kennwort „opnsense“ anmelden (Sonst kommt man nur in den Live-Modus und die Einstellungen sind nach einem Neustart verloren!)

Nach der Installation hat das System die IP-Adresse 192.168.1.1 was für die VM natürlich nicht funktioniert. Nach dem Login kann man unter „1) Assign Interfaces“ die WAN-Schnittstelle festlegen und mit „2)Set interface IP address“ die IP-Adresse für die WAN-Schnittstelle festlegen. Danach kann man via HTTPS auf die IP-Adresse zugreifen.

Um einen späteren Umzug des Servers zu vereinfachen macht es Sinn auch einen DNS-Eintrag für den Server anzulegen. Ich verwende für diese Demo „demovpn.timo-u.de“.

Einrichtung

Jetzt kann man sich in der Firewall einloggen.

Nach dem Login kommt man auf den Assistent/Wizard in dem grundlegende Einstellungen eingeben kann.

Die WAN-Schnittstelle haben wir ja vorher schon eingestellt. Diese kann jedoch jetzt noch mal überprüft werden.

Die LAN-Schnittstelle ist bei einem Virtuellen Server nicht vorhanden und wird somit übersprungen. Das Kennwort könnt ihr hier noch mal anpassen. Hier sollte unbedingt ein sehr sicheres Kennwort gewählt werden.

Nun ist ein guter Zeitpunkt unter System>Firmware>Aktualisierungen die Software zu auf den neusten Stand zu bringen.

Zunächst sollte man sich Gedanken über die Netzwerkstruktur machen. Dies beginnt zunächst bei den IP-Adressen der VPNs. Als mögliche Netzwerke sollte man nur private Adressbereiche verwenden.

Hier stehen 3 private Adressbereiche zur Verfügung:

• 10.0.0.0/8 (10.0.0.0 bis 10.255.255.255)
• 172.16.0.0/12 (172.16.0.0 bis 172.31.255.255)
• 192.168.0.0/16 (192.168.0.0 bis 192.168.255.255)

Um Überschneidungen mit Heimnetzwerken und Firmennetzwerken zu vermeiden habe ich mich für 172.16.0.0/12 entschieden. (192.168.2.x oder 192.168.178.x wird z.B. gerne in Heimnetzen verwendet)

Des weiteren macht es Sinn Gateways und Administrative Zugänge zu trennen. So kann ein Gateway z.B. nicht auf andere Gateways zugreifen. Der Administrator muss natürlich auf alle Gateways zugreifen können.

Aus diesem Grund definiere ich zunächst 2 Netzwerke:

• 172.16.0.0/24 (Administrator Netzwerk)
• 172.16.1.0/24 (Netzwerk für Gateways)

Zertifikat erstellen

Da das später verwendete OpenVPN auf Zertifikaten basiert muss zunächst eine Zertifizierungsstelle erstellt werden. Hierfür geht man unter System>Sicherheit>Aussteller auf Hinzufügen.

Ich habe mich für ein Zertifikat mit 4096 Bit RSA mit SHA512 entscheiden.

Bei der Laufzeit des Zertifikats habe ich mich für 10 Jahre entscheiden. Da alle Clients auf diesem Zertifikat basieren ist das vor eingestellte Jahr etwas kurz 🙂

Benutzer erstellen

Für jeden „VPN-Benutzer“ muss in der Firewall ein entsprechender Benutzer angelegt werden.

Hierfür legen wir unter System>Zugang>Benutzer einen neuen Benutzer an. Zunächst legen wir einen Zugang „Admin-User“ an hierbei kann man „Generiere ein zufälliges Passwort, um für diesen Nutzer lokale Zugriffe auf die Datenbank zu verhindern.“ aktivieren, da sich dieser Benutzer nicht am System anmelden muss. Gruppenmitgliedschaften hat dieser Benutzer keine. Bei „Zertifikat“ die Checkbox bei „Klicken Sie hier um ein Benutzerzertifikat zu erstellen.“ aktivieren.

Nach dem Speichern öffnet sich das Fenster zum erstellen eines Zertifikats für diesen Benutzer. Hierbei wählt man bei „Vorgehen“ „Erstelle ein neues internes Zertifikat“ und passt die Sicherheitseinstellungen entsprechend an.

Im nächsten Schritt wird der eigentliche VPN-Server eingerichtet. Hierfür unter VPN>OpenVPN>Server einen Server Hinzufügen.

Zunächst wird ein „Standard“- VPN Server eingerichtet.

• Protokoll: UDP
• Port: 1194
• Zertifikate und Algorithmen entsprechend anpassen
  • SHA512
  • AES256
• IPv4 Tunnelnetzwerk 172.16.0.0/24
• Lokales IPv4-Netzwerk 172.16.0.0/16

Nun kann man unter VPN>OpenVPN>Clientexport die OVPN-Dateien exportieren. Hierfür muss zunächst der Hostname eingegeben werden und dann beim entsprechenden Zertifikat die OVPN-Datei exportiert werden.

Die ovpn-Datei kann nun in den VPN-Client (z.B. OpenVPN GUI) geladen werden.

Bevor man sich jetzt mit dem Server verbinden kann müssen noch die Firewall-Regeln im Server angepasst werden. Hierfür muss man auf Firewall>Regeln>WAN eine neue Regel erstellen.

• Aktion: Erlauben
• Schnittstelle: WAN
• Richtung: in
• TCP/IP-Version: IPv4 (oder IPv4 + IPv6 wenn IPv6 auch unterstützt werden soll)
• Protokoll: UDP
• Zielbereich: anderes 1194 -1194

Des weiteren müssen wir die Kommunikation innerhalb der VPN-Netzwerke erlauben. Zur einfachen Fehlersuche habe ich außerdem ICMP (Ping) innerhalb aller VPN-Netzte aktiviert. Nach der Änderung einer Firewall-Regel muss man auf „Änderung übernehmen“ sonst wird diese Regel nicht angewandt.

Jetzt kann man den VPN Tunnel aufbauen und mit „ping 172.16.0.1“ in der Eingabeaufforderung die Verbindung durch den Tunnel testen.

VPN-Server für MikroTik LoRaWAN-Gateways einrichten

Ziel ist es ja die MikroTik LoRaWAN-Gateways aus der Ferne verwalten zu können. Lieder ist die Einrichtung hier nicht ganz so einfach wie in Windows. Das Gateway benötigt bestimmte Einstellungen. Außerdem wollen wir das „Admin-Netz“ und das „Gateway-Netzwerk“ ja getrennt haben.

Hierfür erstellen wir wieder unter VPN>OpenVPN>Server einen weiteren VPN-Server.

Im Gegensatz zum ersten Server stellen wir hier jetzt allerdings andere Parameter ein:

• Protokoll: TCP4
• Lokaler Port: 17000 (Frei definierbar)
• TLS Authentifikation deaktivieren
• Verschlüsselungsalgorithmus: AES256-CBC
• Authentifizierungs-Digestalgorithmus: SHA1 (160-bit)
• IPv4 Tunnelnetzwerk: 172.16.1.0/24
• Lokales IPv4-Netzwerk: 172.16.0.0/16

Dieser Server muss ebenfalls in der Firewall freigegeben werden:

Außerdem muss für jedes LoRaWAN-Gateway ein weitere Benutzer angelegt werden. (Analog zum Admin-User).

Überlegt euch am besten vorher ein entsprechendes Schema.

Nun kann der Clientexport für das LoRaWAN-Gateway gemacht werden. Hierfür wählt man den zweiten VPN-Server und als Export Typ „Archiv“.

Das nun heruntergeladene Archiv enthält zwei Dateien. Die OVPN-Datei und die Zertifikate im p12-Container.

Clienteinrichtung im MikroTik Gateway

Hierfür muss man sich zunächst in das Gateway einloggen.

Unter Files kann man die p12-Datei aus dem Archiv hochladen. Diese unterscheidet sich bei jedem Gateway.

Bevor das Zertifikat nun genutzt werden kann muss es erst den Systemzertifikaten hinzugefügt werden. Dies geschieht unter System>Certificates>Import unter Auswahl der hochgeladen Datei.

Nun sind zwei Zertifikate hinzugefügt. Das erste ist das Client-Zertifikat mit Key und das zweite das CA-Zertifikat.

Im letzten Schritt wird der eigentliche VPN-Client eingerichtet. Hierfür geht man unter „PPP“ auf das „+“ und dann auf „OVPN Client“. Im zweiten Reiter „Dial Out“ muss man nun die Verbindungsdaten eingeben:

• Connect To: demovpn.timo-u.de
• Port: 17000
• Mode: IP
• User: root (egal was hier drin steht)
• Profile: default
• Certificate: Euer Zertifikat mit der Endung „.p12_0“
• „Verifiy Server Certificate“ aktivieren
• Auth: sha1
• Cipher: aes256
• Use Peer DNS: no

Nach dem Druck auf „Apply“ verbident sich das Gateway mit dem VPN-Server:

Auf dem VPN-Server kann man sich nun unter VPN>OpenVPN>Verbindungsstatus alle aktiven VPN-Verbindungen mit deren IP-Adresse anzeigen lassen:

Jetzt kann man sich über die IP-Adresse 172.16.1.6 mit dem Gateway verbinden.

Automatischer Neustart

Das Gateway läuft meiner Erfahrung nach absolut stabil. Bisher ist es jedoch einmal vorgekommen, dass sich das Gateway nach einiger Zeit nicht selbständig wieder mit dem VPN-Server verbunden hat. Aus diesem Grund lasse ich die Gateways einmal pro Woche neu starten. Hierfür kann man unter System > Scheduler eine Aufgabe anlegen.

Mit diesen Einstellungen wird im Abstand von 7 Tagen um 4:00 Uhr ein Neustart durchgeführt:

Raspberry basierte Gateways

Für Gateways die auf dem Raspberry PI basieren oder auch stärkere Algorithmen nutzen können würde ich einen 3. VPN-Server einrichten. Hierfür kann man folgende Einstellungen nutzen.

• Protokoll: UDP
• Port: Frei wählbar
• Verschlüsselungsalgorithmus: AES256-CBC
• Authentifizierungs-Digestalgorithmus: SHA512
• IPv4 Tunnelnetzwerk: 172.16.2.0/24
• Lokales IPv4-Netzwerk: 172.16.0.0/16

Danach wie gehabt die Firewall-Freischaltung am WAN-Port vornehmen und den Benutzer anlegen.

Beim exportieren des Zertifikats hier wieder „Nur Datei“ auswählen.

Auf dem Raspberry PI dann folgende Schritte ausführen:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install openvpn

Die vom Server generierte .ovpn Datei ein nennt ihr nun in „VPN.conf“ um und kopieret diese nach /etc/openvpn/VPN.conf

Wenn ihr das mit WinSCP macht müsst ihr die Datei zunächst nach /home/pi/ kopieren und dann mit

sudo  cp /home/pi/VPN.conf /etc/openvpn/

an die richtige Stelle kopieren.

Danach muss man den PI noch dazu bringen die VPN-Verbringung automatisch zu starten. Hierfür die muss mit

sudo nano /etc/default/openvpn

die Konfigurationsdatei geöffnet werden und

AUTOSTART="VPN"

am Ende der Datei hinzugefügt werden. Nun könnt ihr den Dienst starten oder einen Neustart durchführen.

sudo /etc/init.d/openvpn start

oder 

sudo shutdown -r now

Sollten bei der Verbindung Probleme auftreten kann man sich die Verbindung auch live anzeigen lassen.

sudo openvpn --config /etc/openvpn/VPN.conf 

Fertig 🙂

Ich hoffe ich konnte euch hiermit bei der Fernwartung eurer Systeme unterstützen und freue mich auf Feedback und Ergänzungen via Mail oder auf Twitter