Firewall-Whitelist

Inhalt

Überblick

IoT-Geräte (Gateways, Zähler, Sensoren) bauen ausschließlich ausgehende Verbindungen zur niotix-Plattform auf – eine eingehende Verbindung zum Gerät ist nicht erforderlich. Diese Seite listet die Zieladressen und Ports auf, die dafür freigegeben werden müssen – aufgeteilt nach Anbindungsart (MQTT-Broker, LwM2M, LoRaWAN, Webhook).

Ein solches Whitelisting ist insbesondere erforderlich bei:

  • M2M-SIM-Karten mit privatem APN: Der Mobilfunktarif erlaubt nur ausgehenden Traffic zu explizit freigegebenen Zieladressen.
  • Firmen-Firewalls und geschlossenen Netzen: Ausgehende Verbindungen sind auf eine Whitelist beschränkt.

Allgemeine Hinweise

  • Domain statt IP-Adresse whitelisten: Wo möglich, sollte die Freigabe über den Domain-Namen erfolgen. Änderungen der IP-Adressen bleiben vorbehalten.
  • DNS-Auflösung: Die Namensauflösung der genannten Domains muss aus dem Netz bzw. APN heraus funktionieren; der DNS-Server muss erreichbar sein (UDP/TCP-Port 53).
  • Zeitsynchronisation (NTP): Das Gerät muss seine Uhrzeit per NTP synchronisieren können – bei privatem APN oder restriktiver Firewall daher zusätzlich UDP-Port 123 ausgehend freigeben. Mit falscher Uhrzeit schlägt die TLS-Zertifikatsprüfung fehl.
  • IP-Konfiguration: Per DHCP erhält das Gerät IP-Adresse, Default-Gateway und DNS-Server automatisch; bei statischer IP-Adresse müssen alle drei manuell korrekt eingetragen sein. Ohne korrektes Default-Gateway erreicht das Gerät das Internet nicht.

Alle hier genannten Endpunkte gelten für die öffentliche niotix-SaaS-Instanz (niotix.io). Für private SaaS-Instanzen oder On-Premise-Installationen gelten abweichende Adressen – diese teilt Ihnen Ihr Ansprechpartner mit.

Firewall-Regeln

Es werden nur ausgehende Regeln benötigt. Alle Verbindungen baut das Gerät selbst auf. Für jeden Eintrag dieser Seite genügt deshalb eine Regel nach dem Muster Gerät → Zieladresse:Port. Eingehende Freigaben zum Gerät (etwa „Port 443 eingehend") sind weder nötig noch sinnvoll.

Ob die Antworten (z. B. Downlinks) zurückkommen, hängt vom Firewall-Typ ab:

  • Stateful Firewall (Standardfall bei Firmen-Firewalls, Routern und NAT): Die Firewall merkt sich jede ausgehende Verbindung und lässt die zugehörigen Antworten automatisch durch. Weitere Regeln sind nicht nötig.
  • Stateless Paketfilter (z. B. einfache Router-ACLs, manche APN-Filter): Die Firewall prüft jedes Paket einzeln und kennt keine Verbindungen. Der Rückweg muss zusätzlich erlaubt werden: Pakete von der Zieladresse mit dem jeweiligen Quellport (z. B. 443 oder 1700) zum Gerät, Zielport beliebig.
  • Besonderheit UDP (Semtech UDP Packet Forwarder, LwM2M/CoAP): UDP kennt keinen Verbindungsauf- und -abbau. Auch eine stateful Firewall hält den Rückweg deshalb nur eine begrenzte Zeit offen (UDP-Timeout, je nach Gerät oft 30 bis 180 Sekunden). Sendet das Gerät in dieser Zeit nichts, wird der Rückweg geschlossen und Antworten gehen verloren. Das Gerät muss daher häufiger senden, als der UDP-Timeout abläuft (z. B. über das Keepalive des Packet Forwarders). Typisches Symptom: Uplinks kommen an, Downlinks wie Join Accepts gehen sporadisch verloren.

Verbindung testen: Wie sich Namensauflösung und Ports prüfen lassen, beschreibt die Seite Fehlerbehebung: Verbindung testen.

MQTT-Broker

Gilt für Geräte und Clients, die über den von niotix gehosteten MQTT-Broker angebunden sind (siehe Konnektor mqttbroker).

Zieladresse Port Protokoll
consumers.mq.iot-hub.com 8883 MQTTS (TLS über TCP)

Der Broker verwendet eine dynamische IP-Adresse. Ein Whitelisting ist daher ausschließlich über den Domain-Namen möglich, nicht über eine feste IP-Adresse.

LwM2M

Gilt für LwM2M-Geräte, die sich mit dem niotix LwM2M Server verbinden. Empfohlen wird der Security Mode Pre-Shared Key (PSK) mit DTLS-Verschlüsselung:

Zweck DTLS-Endpunkt Transport IP-Adresse
Bootstrap Server coaps://lwm2m.niotix.io:5694 UDP (DTLS) 35.204.45.127
Management Server coaps://lwm2m.niotix.io:5684 UDP (DTLS) 35.204.45.127
Firmware Updates coaps://lwm2m.niotix.io:5674 UDP (DTLS) 35.204.45.127
Firmware Updates (Elvaco)¹ coap://35.204.45.127:5673 UDP (CoAP) 35.204.45.127

¹ Elvaco-Module (z. B. CMi6110, Elvaco Edge) laden Firmware-Updates derzeit ausschließlich unverschlüsselt per CoAP über UDP-Port 5673 und über eine IP-basierte Adresse, da die Geräte keine DNS-Auflösung unterstützen. Das Firmware-Image selbst ist verschlüsselt und signiert. Bei privatem APN oder restriktiver Firewall muss für Elvaco-Geräte daher zusätzlich UDP 5673 freigegeben werden.

Die obige Tabelle gilt für Verbindungen vom Gerät zum LwM2M-Server.

Hinweis für On-Premise-niotix-Installationen: Zwischen dem LwM2M-Server und einer On-Premise-niotix-Installation müssen beide Richtungen freigegeben werden:

Richtung IP-Adresse Port Zweck
LwM2M-Server → niotix (ausgehend) 34.147.58.107 (Quell-IP) 443 (HTTPS) Datenübertragung per Webhook (HTTP POST)
niotix → LwM2M-Server (eingehend) 35.204.45.127 (Ziel-IP) 443 (HTTPS) Geräteregistrierung

Der unverschlüsselte Modus (Security Mode: NoSec, coap:// über die UDP-Ports 5693 für Bootstrap und 5683 für Management) sollte ausschließlich zu Testzwecken verwendet werden. Für den Produktiveinsatz wird die verschlüsselte Verbindung (PSK/DTLS) empfohlen.

LoRaWAN-Gateways (Firefly)

Gilt für LoRaWAN-Gateways, die an den Netzwerkserver Firefly angebunden werden:

Zieladresse Port Protokoll Anbindungsart
fireflyiot.com 1700 UDP Semtech UDP Packet Forwarder
ns.fireflyiot.com 443 TCP (TLS, WebSockets) Basic Station

Alternativ ist ein Whitelisting über die statische IP-Adresse 52.59.18.61 möglich; Änderungen der IP-Adresse bleiben jedoch vorbehalten – empfohlen wird die Freigabe per Domain-Name.

Die genannten Hosts gelten für den Frequenzplan EU868. Für andere Regionen gelten abweichende Hosts (z. B. us1.ns.fireflyiot.com) – siehe Frequenzpläne und Netzwerkserver-Adressen.

Weitere Details zu NAT, Timeouts und TLS finden sich in der Checkliste Firewall und Ports.

Webhook (HTTP-POST)

Gilt für Geräte und Systeme, die Daten per HTTP POST an einen Webhook (Incoming)-Konnektor senden:

Zieladresse Port Protokoll
niotix.io 443 HTTPS

Verwandte Themen