Dynamic DNS auf Sophos Firewall einrichten und prüfen

Unter Network > Dynamic DNS > Add verbindet man einen Hostnamen des DDNS-Providers mit dem passenden WAN-Interface. Trägt die Sophos Firewall selbst die öffentliche IPv4, wählt man Use port IP. Steht sie mit einer privaten WAN-Adresse hinter einem Router, ist NATed public IP richtig.

Dynamic DNS aktualisiert nur den DNS-Eintrag. Es öffnet keine Ports und erstellt weder NAT- noch Firewall-Regeln. Soll ein interner Server hinter der Firewall erreichbar sein, müssen deshalb zusätzlich die Schritte unter Server per DNAT veröffentlichen passen.

Der gleiche Hostname kann eine dynamische öffentliche WAN-Adresse auch für eine Sophos DNS Protection Location abbilden. Zuerst muss die unten beschriebene externe A-Abfrage die aktuelle WAN-IPv4 liefern; danach prüft man die standortspezifische Zuordnung wie unter Sophos DNS Protection Locations sicher verwalten beschrieben. Der DDNS-Eintrag allein weist noch keine Filtering Policy zu und ändert den DNS-Pfad der Clients nicht.

Dynamic DNS konfigurieren

Vorher benötigt man beim Provider einen Hostnamen wie vpn.example.net und gültige Update-Zugangsdaten. Die Firewall muss DNS auflösen und das Internet sowie den Provider erreichen können. Dynamic DNS funktioniert deshalb nicht in einer Air-Gap-Umgebung.

Network > Dynamic DNS öffnen und auf Add klicken.
Unter Hostname den beim Provider angelegten Namen eintragen, zum Beispiel vpn.example.net. Dabei die vom Provider verlangte Schreibweise für Domain und Subdomains verwenden; das Format ist nicht bei allen Anbietern gleich. Vor dem Speichern auch dessen Vorgaben für den Anmeldenamen prüfen.
Das zugehörige WAN-Interface wählen, zum Beispiel Port2 - WAN.
Unter IPv4 address Use port IP oder NATed public IP wählen.
Den Service provider auswählen.
Login name und Password beziehungsweise den providerspezifischen Update-Key eintragen.
Mit Save speichern und den Status kontrollieren.

Im aktuellen SFOS-Dialog stehen DynDNS, DynAccess, EasyDNS, ZoneEdit, Google DDNS, Namecheap, DNS-O-Matic, No-IP, FreeDNS und Cloudflare zur Auswahl. Der frühere Sophos-Dienst myfirewall.co ist eingestellt. Die Bezeichnung Password meint je nach Provider nicht das normale Kontopasswort: DynDNS verwendet den Updater Client Key, ZoneEdit und EasyDNS einen Dynamic Token. DynAccess, No-IP, DNS-O-Matic, Google DDNS und Namecheap verwenden Benutzername und Passwort. Wenn ein Provider keinen Benutzernamen verlangt, trägt man laut Sophos die Domain als Login name ein. Bei FreeDNS darf das Passwort in SFOS höchstens 15 Zeichen lang sein; Cloudflare ist der Sonderfall mit E-Mail-Adresse und Global API Key.

Vor Schritt 6 bereitet man Hostname und Update-Zugangsdaten im Providerkonto vor:

DynDNS: Im DynDNS-Konto führt My Services > DynDNS Pro > Add New Hostname zum Anlegen eines Hostnamens mit der gewünschten Providerdomain. Den Update-Schlüssel findet man unter Account Settings > Updater Client Key. Ist das Feld leer, verwendet man Generate Key. Achtung: Ein neu generierter Schlüssel ersetzt die bisherigen Zugangsdaten bestehender DDNS-Update-Clients; diese müssen ebenfalls den neuen Schlüssel erhalten. In SFOS trägt man den DynDNS-Benutzernamen als Login name und den Schlüssel als Password ein, nicht das Kontopasswort.
ZoneEdit: Im ZoneEdit-Kontrollpanel DNS öffnen und das Schraubenschlüssel-Symbol bei DYN RECORDS wählen. HOST und TTL festlegen, bei DYN AUTHENTICATION TOKEN auf ENABLE klicken, mit NEXT fortfahren und die Änderungen bestätigen. In SFOS verwendet man den ZoneEdit-Benutzernamen und den Dynamic Token anstelle des Kontopassworts.
EasyDNS: Im EasyDNS-Kontrollpanel bei der Domain MANAGE > DNS SETTINGS > MODULAR EDITOR öffnen und DYNAMIC RECORDS bearbeiten. Hostname und TTL festlegen, den Dynamic Authenticated Token mit ENABLE erstellen, NEXT wählen und die Änderungen bestätigen. Der gebuchte Dienst muss Dynamic DNS unterstützen. Besteht bereits ein A-Record, bestätigt man dessen Umstellung nur, wenn er tatsächlich dynamisch werden soll. In SFOS verwendet man den EasyDNS-Benutzernamen und den Token statt des Kontopassworts.
FreeDNS: Die benötigten Hostnamen unter FreeDNS-Subdomains prüfen. Für SFOS gelten weiterhin die oben genannten Zugangsdaten und die Passwortgrenze von 15 Zeichen.

Update-Schlüssel und Tokens gehören ebenso wie Passwörter weder in Screenshots noch in Tickets.

Use port IP oder NATed public IP

Use port IP: Das gewählte WAN-Interface besitzt selbst die öffentliche IPv4-Adresse.
NATed public IP: Das WAN-Interface besitzt eine private Adresse und ein vorgeschalteter Router führt NAT aus. Für die Ermittlung der öffentlichen Adresse muss die Firewall zusätzlich checkip.cyberoam.com über TCP 80 erreichen können.

Bridge-Interfaces unterstützen Dynamic DNS nicht. Werden WAN-Interfaces umgebaut oder ersetzt, sollte man die Abhängigkeiten über Object usage und danach den DDNS-Eintrag prüfen. Weitere Interface-Grenzen erklärt Zonen und Interfaces richtig einsetzen.

Cloudflare sicher anbinden

Der integrierte Cloudflare-Provider erwartet die Account-E-Mail und den Global API Key. Ein eingeschränkter API-Token ist in der aktuellen Sophos-Dokumentation nicht als kompatibles Credential aufgeführt.

Cloudflare stuft den Global API Key als Legacy ein: Er hat dieselben Rechte wie der Benutzer und Zugriff auf dessen Ressourcen. Für die SFOS-Integration sollte deshalb ein separater Cloudflare-Benutzer nur auf die benötigte Zone und DNS-Rolle begrenzt werden. Der Key gehört weder in Screenshots noch in Tickets. Wenn ein Global API Key im Sicherheitskonzept nicht zulässig ist, sollte stattdessen ein externer Updater mit eingeschränktem API-Token oder ein anderer unterstützter Provider verwendet werden.

Für VPN und andere Dienste, die Clients direkt mit der öffentlichen Firewall-IP verbinden, muss der Cloudflare-Record auf DNS only stehen. Bei einem bewusst aktivierten Proxy liefert die DNS-Abfrage stattdessen Cloudflare-Anycast-Adressen; dann ist die DDNS-Origin-IP im Cloudflare-Dashboard zu prüfen.

DDNS-Auflösung und Dienst prüfen

SFOS prüft alle fünf Minuten, ob sich die öffentliche IP geändert hat. Nach dem Speichern kontrolliert man unter Network > Dynamic DNS die Spalten Last updated IP, Last updated status, Last updated time und bei einem Fehler Failure reason. Last updated IP ist die zuletzt an den Provider gesendete Adresse; erst die externe DNS-Abfrage zeigt, welche Adresse öffentlich ausgeliefert wird.

Anschliessend wird der Hostname von ausserhalb des eigenen DNS-Caches abgefragt. Unter Linux und macOS:

dig @1.1.1.1 vpn.example.net A +short

Unter Windows:

nslookup vpn.example.net 1.1.1.1

Die Antwort muss der erwarteten öffentlichen IPv4 entsprechen. Direkt nach einem Wechsel kann ein Resolver wegen DNS-TTL und Cache noch die alte Adresse liefern.

Zuletzt testet man den eigentlichen Dienst aus einem fremden Netz, zum Beispiel über Mobilfunk. Die korrekte DNS-Antwort beweist nur die Namensauflösung, nicht die Erreichbarkeit des Dienstes.

Änderung zurücknehmen

Funktioniert der Eintrag nicht wie erwartet, kann man ihn unter Network > Dynamic DNS über Manage bearbeiten und das bisherige Interface, die IP-Auswahl, den Provider und die Zugangsdaten wiederherstellen. Wird DDNS nicht mehr benötigt, löscht man den Eintrag und stellt den gewünschten DNS-Wert beim Provider manuell wieder her. Das Löschen stoppt nur künftige DDNS-Aktualisierungen; es entfernt weder DNAT- noch Firewall-Regeln und setzt den beim Provider veröffentlichten DNS-Eintrag nicht automatisch zurück. Danach werden die externe DNS-Antwort und der Dienst erneut geprüft.

Multi-WAN, HA und CGNAT

Nach einem WAN- oder HA-Failover immer DDNS-Status, externe DNS-Antwort und den Dienst prüfen.

Multi-WAN: Jeder DDNS-Eintrag ist an ein ausgewähltes Interface gebunden. Man sollte nicht annehmen, dass ein einzelner Hostname automatisch dem aktiven Gateway folgt. Für veröffentlichte Dienste pro WAN einen eindeutigen Hostnamen planen.
HA: Troubleshooting-Logs werden zwischen den Knoten nicht synchronisiert. Den vollständigen Failover-Test erklärt Sophos Firewall High Availability einrichten.
CGNAT: NATed public IP kann die gemeinsam genutzte Provideradresse veröffentlichen, macht die Firewall aber nicht eingehend erreichbar. Dafür benötigt man beispielsweise eine echte öffentliche IPv4, einen separat gepflegten AAAA-Record mit passender IPv6-Firewall- und Dienstkonfiguration oder eine ausgehend aufgebaute Tunnel- beziehungsweise Relay-Lösung. Das hier beschriebene SFOS-DDNS aktualisiert nur IPv4.

Fehler beheben

Im Log Viewer Events und System auswählen und nach der Komponente DDNS suchen. Die technischen Feldwerte lauten log_type=Event, log_subtype=System und log_component=DDNS; entscheidend sind Status, Message und Failure reason. Die letzten Einträge zeigt auch Option 4 Device Console:

show logs ddc.log lines 100

Für eine Live-Analyse kann man im SSH-Menü unter Device Management > Advanced Shell folgenden Befehl verwenden und danach mit Ctrl+C beenden:

tail -f /log/ddc.log

Die Befehle und die Zuordnung zu ddc.log sind für SFOS 22 dokumentiert, wurden hier aber nicht gegen eine Kundenfirewall ausgeführt. Weitere Logdateien und Zugriffswege stehen unter Sophos Firewall Service-Logs.

Invalid Configuration or bad authorization: Hostname, Provider und Zugangsdaten prüfen. Bei Cloudflare sind Account-E-Mail und Global API Key erforderlich.
Invalid IP: Interface und die Auswahl Use port IP beziehungsweise NATed public IP kontrollieren.
DNS Error oder Connect Failed: DNS, Default Route, Internet- und Provider-Erreichbarkeit prüfen. Bei NATed public IP zusätzlich die oben genannte Check-IP-Erreichbarkeit kontrollieren.
Invalid Response oder Reported Abuse: Providerstatus, Konto, Sperren und Limits beim Provider prüfen.
Success, aber falsche IP: Provider-Dashboard, ausgewähltes Interface, IP-Option und die externe DNS-Antwort vergleichen.
FQDN stimmt, Dienst ist nicht erreichbar: Vorgeschaltete Portweiterleitung, DNAT, Firewall-Regel und die jeweilige VPN- oder Dienstkonfiguration prüfen.

Wenn Cloudflare-DDNS erst seit dem Upgrade auf SFOS 22.0 MR1 ausfällt, auf SFOS 22.0 MR2 Build 546 oder neuer aktualisieren und erneut testen. Sophos behebt damit NC-180219; die Details stehen im SFOS-22-MR2-Artikel.