Unifi Controller Migration

[deslout!]

Hei zusammen

Ich nutze aktuell einen Unifi Controller auf meinem Windows PC mit 2 Unifi AP AC-Pros.
Nun habe ich eine Controller VM auf meinem Server installiert. Mein Standort und der Server sind mit einem s2s verbunden.

Gerne wollte ich nun die APs migrieren. Dafür habe ich sie zurückgesetzt und mit set-inform die Controller IP eingepflegt:

Wie auf dem Screenshot ersichtlich, erhalte ich nun einen "server reject" error.

Auf dem Controller sehe ich beide APs, kann sie aber nicht übernehmen:

Vielleicht hat jemand eine Idee. Auf dem bestehenden Controller (win) kann ich die APs problemlos übernehmen.

Die TCP Verbindung scheint aber nicht das Problem zu sein:

Danke im Voraus.

 

[madmax2010]

sind die 10.17 adressen im selben subnetz, wie der DHCP Server im neuen Netz?

 

[honky-tonk]

würde auch vermuten, dass da netzintern was mit broadcast geschickt wird und da das site to site keine direkte IP im AP netz hat, das dann fehl schlägt...aber alles nur vermutung

 

[MetalForLive]

Der neue Controller ist blank aufgesetzt oder hast du ein Backup eingespielt ?
Hast du die APs komplett auf factory default zurück gesetzt ? Also nicht nur im alten Controller "forget" drücken sondern den physikalischen reset button am AP 10 Sekunden drücken bis die LEDs anders blinken.
Die APs bekommen aber nicht per DHCP (option 43 z.B.) oder DNS Eintrag noch die IP vom alten Controller ?
Ich würde den alten Controller mal komplett abschalten.

Edit: Layer 3 passt alles ?
Also du kannst den neuen Controller pingen und da sind auch keine Firewallregeln oder so dazwischen ?

 

[Gelöscht 875920]

Du musst die APs erst zurücksetzen, dann set-inform und dann adopten

set-inform ist in vielen Umgebungen aber gar nicht mehr nötig.

 

[Raijin]

set-inform sollte man wie alle direkten Eingriffe in die APs vermeiden. Das ist bestenfalls eine Notmaßnahme.

Standardmäßig suchen Unifi-Geräte den Controller unter dem Hostnamen "unifi" oder über die DHCP Option 43. Letzteres ist eine Option von DHCP-Servern, die beliebige herstellerspezifische Informationen halten kann, wie zB die IP des Unifi-Controllers. Sowas sucht man allerdings bei Fritzboxxen, Speedports und sonstigen Consumer-Routern vergeblich und ist in der Regel nur bei fortgeschrittenen Systemen verfügbar (MikroTik, EdgeRouter, *Sense, Sophos, etc).


Die grundsätzliche Vorgehensweise wäre daher, zum einen den alten Controller zum neuen via Backup & Restore zu migrieren und im Netzwerk der APs im DHCP-Server dafür zu sorgen, dass der Hostname "unifi" auf die korrekte IP-Adresse aufgelöst wird. Liegt der Controller in einem anderen Subnetz, muss eben diese IP im DHCP eingetragen werden.
Von diesem Moment an sollten sich die APs spätestens nach einem Neustart mit dem neuen Controller verbinden. Vor dem Reboot daran denken, den alten Controller abzuschalten damit es nicht 2x "unifi" gibt.

Aber: Natürlich muss auch sichergestellt sein, dass der Controller im neuen Subnetz grundsätzlich auch erreichbar ist. Das Routing muss also stimmen und die Firewall muss den Traffic zulassen. Zum Test kann man den Controller im Netz der APs im Browser aufrufen. Klappt das, sollten die APs den neuen Controller auch sehen.

 

[deslout!]

sind die 10.17 adressen im selben subnetz, wie der DHCP Server im neuen Netz?

Die Netzte 10.10.10.0/24 und 10.17.17.0/24 haben jeweils eigene DHCP Server.

Der neue Controller ist blank aufgesetzt oder hast du ein Backup eingespielt ?
Hast du die APs komplett auf factory default zurück gesetzt ? Also nicht nur im alten Controller "forget" drücken sondern den physikalischen reset button am AP 10 Sekunden drücken bis die LEDs anders blinken.
Die APs bekommen aber nicht per DHCP (option 43 z.B.) oder DNS Eintrag noch die IP vom alten Controller ?
Ich würde den alten Controller mal komplett abschalten.

Edit: Layer 3 passt alles ?
Also du kannst den neuen Controller pingen und da sind auch keine Firewallregeln oder so dazwischen ?

Ja die APs habe ich komplett zurückgesetzt mit dem reset Button.
Den alten Controller habe ich ebenfalls bereits ausgestellt.

set-inform sollte man wie alle direkten Eingriffe in die APs vermeiden. Das ist bestenfalls eine Notmaßnahme.

Standardmäßig suchen Unifi-Geräte den Controller unter dem Hostnamen "unifi" oder über die DHCP Option 43. Letzteres ist eine Option von DHCP-Servern, die beliebige herstellerspezifische Informationen halten kann, wie zB die IP des Unifi-Controllers. Sowas sucht man allerdings bei Fritzboxxen, Speedports und sonstigen Consumer-Routern vergeblich und ist in der Regel nur bei fortgeschrittenen Systemen verfügbar (MikroTik, EdgeRouter, *Sense, Sophos, etc).


Die grundsätzliche Vorgehensweise wäre daher, zum einen den alten Controller zum neuen via Backup & Restore zu migrieren und im Netzwerk der APs im DHCP-Server dafür zu sorgen, dass der Hostname "unifi" auf die korrekte IP-Adresse aufgelöst wird. Liegt der Controller in einem anderen Subnetz, muss eben diese IP im DHCP eingetragen werden.
Von diesem Moment an sollten sich die APs spätestens nach einem Neustart mit dem neuen Controller verbinden. Vor dem Reboot daran denken, den alten Controller abzuschalten damit es nicht 2x "unifi" gibt.

Aber: Natürlich muss auch sichergestellt sein, dass der Controller im neuen Subnetz grundsätzlich auch erreichbar ist. Das Routing muss also stimmen und die Firewall muss den Traffic zulassen. Zum Test kann man den Controller im Netz der APs im Browser aufrufen. Klappt das, sollten die APs den neuen Controller auch sehen.

Option 43 ist bei meinem Forti Modell anscheinend gar nicht verfügbar. Daher habe ich auch den Eingriff mit set-inform versucht. Ein Ping auf unifi bekomme ich leider nicht zum laufen auch nicht mit statischen Eintrag im AdGuard DNS.

Ich habe die Konfig vom alten Controller mit Backup und Restore auf den neuen Controller versucht. Daher werden die APs auch angezeigt aber wie im Screenshot ersichtlich nur ausgegraut mit Status "Orange"

Ping auf Controller IP aus dem Netz der APs funktioniert aber problemlos.

 

[MetalForLive]

Hier schreibt einer was, dass man die Mac Adresse des Geräts mal aus der Datenbank des Controllers löschen soll.
Versuch das mal.
Ansonsten würde ich ein Clean install machen und es mal so testen. Wenn es nur zwei APs sind, sollte sich der Konfigurationsaufwand ja in Grenzen halten oder ?

 

[Raijin]

Option 43 ist bei meinem Forti Modell anscheinend gar nicht verfügbar.

Wenn du damit ein FortiGate/FortiNet meinst, wird hier beschrieben wie das klappen soll: Klick!


Die Sache ist nämlich die: Was genau in Option 43 steht ist herstellerspezifisch und nicht standardisiert. Bei einem EdgeRouter, der ebenfalls von Ubiquiti stammt wie die Unifi-Serie, ist das im DHCP daher ganz einfach als "Unifi-Controller" in der GUi angegeben. Bei Fremdgeräten muss man Option 43 allerdings zu Fuß einrichten, da dort buchstäblich alles mögliche stehen kann. Deswegen ist im oben verlinkten Beispiel die IP als Hex zu codieren, sozusagen als Rohdaten.

Daher habe ich auch den Eingriff mit set-inform versucht.

Das ist im Zweifelsfalle ja auch richtig, wenn man beispielsweise gar keinen Einfluss auf den lokalen DNS hat oder dieser weder manuelle Einträge zulässt noch Option 43 bietet. Mit einer FortiGate sollte es aber eigentlich möglich sein. Hintergrund des ganzen ist einfach, dass bei korrekter DNS-Auflösung und/oder Option 43 ein neuer AP einfach angestöpselt wird und sofort im Controller adoptet werden kann. Bei manueller inform-url muss jeder neue oder ausgetauschte AP oder ggfs weitere Unifi-Geräte (zB Unifi-Switch) zunächst via ssh mit der IP des Controllers verheiratet werden muss. DNS/DHCP ist da der handlichere Weg, wenn's denn funktioniert.

Ping auf Controller IP aus dem Netz der APs funktioniert aber problemlos.

Ping ist eine Sache, aber die APs rufen eine URL auf, rufen die Daten also via http ab. Ping = ICMP und ICMP != http. Das sind zwei Paar Schuhe. Du müsstest explizit mal checken ob du http://controllerip:8080 aufrufen kannst bzw. im Zweifelsfalle die tcpdump / packet capture Funktion der FortiGate bemühen und nachsehen ob http bzw tcp 8080 ins andere Subnetz durchgeht und zurückkommt.

Ansonsten würde ich ein Clean install machen und es mal so testen.

In der Tat. Bei 2 APs ist der Aufwand überschaubar. Zudem kann man so sicherstellen, dass die beiden APs, die @deslout! scheinbar im Controller sieht, tatsächlich durch Meldungen der APs angezeigt werden oder ob sie nur dirt auftauchen, weil sie aus dem Backup importiert wurden und jetzt in der Luft hängen.

Wie auf dem Screenshot ersichtlich, erhalte ich nun einen "server reject" error.

Das kann zum einen darauf hindeuten, dass die FortiGate den Traffic blockiert, und zum anderen, dass die Firewall auf dem Server selbst blockiert. Prüfe mal ob der Server überhaupt Verbindungsanfragen aus dem anderen Subnetz erlaubt. Siehe dazu auch der eben erwähnte Test mit dem Browser. Wenn der Server bzw dessen Firewall nämlich sinngemäß auf "Accept traffic from local subnet only" steht, nimmt er die Inform-Pakete von den APs nicht an. Daher: Firewall bei tcp 8080 prüfen und ggfs für Quell-IP = 10.17.17.0/24 freischalten.

 

[deslout!]

Option43 konnte ich nun auf der Forti konfigurieren. Leide weiterhin ohne Erfolg.
Wenn ich via Browser aus dem Netz der APs auf http://10.10.10.24:8080 aufrufe, werde ich auf das normale Web Interface (Port 8443) weitergeleitet. Die Firewall sollte also keine Ports blockieren.

Auf der Forti kann ich die Firewall Regeln für das Remote Netz nicht konfigurieren, da ein Raspbi via Wireguard ein s2s ins Remote Netz vom Controller aufbaut. Ich teste nun eine komplett Neuinstallation, kann mir aber nicht vorstellen, dass die APs den Controller dann finden. Ansonsten hole ich mir den Controller auf einen Raspbi im AP Netz.

 

[Raijin]

Wenn die Neuinstallation bzw. der Reset des Controllers nicht hilft, bleibt dir außer blinder Rumstocherei oder dem lokalen Controller eigentlich nichts anderes übrig als den Traffic am FortiGate sowie am Controller mittels tcpdump/WireShark/PacketCapture mitzuschneiden und auszuwerten.

Ergänzung (3. Juni 2022)

Ich teste nun eine komplett Neuinstallation, kann mir aber nicht vorstellen, dass die APs den Controller dann finden.

Der Teufel steckt im Detail. Aktuell ist es doch so, dass die APs melden, dass die Verbindung zum Controller "rejected" wurde. Das bedeutet ganz objektiv, dass sie versuchen, sich mit der 10.10.10.24 zu verbinden, aber als Antwort erhalten sie ein "Du darfst nicht". Das kann einerseits vom FortiGate kommen, aber andererseits auch von der Firewall des Betriebssystems in der Controller-VM oder gar vom Controller selbst. Würden die APs den Controller gar nicht finden, würde dort tendenziell eine Meldung mit Bezug auf einen Timeout kommen, weil "nicht finden" heißt im Klartext "gar keine Antwort" aka "Timeout".

Hier findest du eine Liste von Ports, die Unifi sonst noch so verwendet. Eventuell wird ja auch einer von denen geblockt. Auch das würdest du mit nem tcpdump, etc. sehen können.


Die Frage ist letztendlich wie tief du da jetzt einsteigen willst. Das Forum kann dir an dieser Stelle zumindest nur noch bedingt helfen - es sei denn irgendjemand hat jetzt noch einen Geistesblitz oder schießt ins Blaue und trifft..

 

[MetalForLive]

Sofern dort keine neuen NextGen Firewalls im Traffic flow sind welche auf App Basis arbeiten kannst du auch einfach mal mit nem nmap einen Portscann auf den Controller machen um zu schauen ob der Port offen ist.

 

[Raijin]

Es ist immerhin ein FortiGate mit im Spiel.

Bitte einfach ein packet capture für die oben verlinkten Ports machen. Sonst kommen wir nicht weiter, weil nmap auch einfach nur "keine Verbindung" ausspucken würde und man wäre keinem Deut schlauer, weil man immer noch nicht weiß wo es hängt.

Wenn also die Neueinrichtung nicht fruchtet, bitte gleich ordentlich debuggen mit verwertbarem Ergebnis.

 

[deslout!]

Sooo

Ich danke euch für eure ausführliche Hilfe und die Tipps. Nach erfolgloser Neuinitialisierung der gesamten Infrastruktur habe ich mich dazu entschieden, den Controller im Netz der APs auf einer Home Assistant Instanz laufen zu lassen. Dies funktioniert problemlos.

Ich vermute nach den Port Tests mit Wireshark (welche alle erfolgreich waren) ehrlichgesagt ein Problem mit der s2s Verbindung via Wireguard. Was irgendwie auch keinen Sinn macht, da die Ports vom Windows Client (gleiches VLAN wie APs) alle geöffnet sind.

Irgendwo übersehe ich etwas, was ich in Zukunft mal debuggen will. Mit eurer Hilfe und schlechtem Wetter werde ich es zu einem späteren Zeitpunkt neu angehen