Probleme mit einer RED

Puh, viel raten kann ich dir nicht (weil wir ja auch keinen Blinkcode des REDs haben). Wenn sich das Ding nicht irgendwo aufgehängt hat, dann befindet es sich in einer Schleife und wartet auf die Config. Also wenn du es nochmal im Webadmin löschst, auch das Interface und es dann neu (wenn du Zeit sparen willst mit Deployment Helper) anlegst und es dann immer noch nicht hoch kommt, könnte ich mir vorstellen, dass es hängt.

Hi Ron

Ich bin grad nicht sicher, was das neuerstellen des X.509 certs mit dem RED zu tun haben sollte.

Wenns das einzige RED ist, schreib Dir mal den Unlock Code auf und deaktiviere den RED Server auf der ASG komplett. Wenn weitere RED daran hängen, ist das natürlich keine Lösung ;o))

Du kannst das RED temporär auf eine andere UTM registrieren (Home UTM ???), und aktiviere den RED Part auf Deiner UTM wieder, sobald der Tunnel auf die temporäre UTM steht.

Danach das RED von der temporären UTM runterlöschen (Unlock Code aufschreiben !!!) und auf der "richtigen" UTM neu erstellen.

Ich glaub ich hatte das auch schon mal, dass das RED sich solange die neue Konfig NICHT abgeholt hatte, solange er seine UTM mit aktiviertem RED Dienst erreichen konnte (auch wenn da was geändert hat). Ich hatte damals temporär mit Hilfe einer zweiten UTM vor meiner UTM den TCP/UDP3400 Verkehr vom RED zur UTM geblockt, und damit das RED enforced sich zum Broker zu verbinden.

Alternative - Du kannst natürlich ebenfalls mit einer anderen Firewall vor der UTM einfach den Verkehr vom betroffenen RED zur UTM blocken, und damit das RED enforcen sich beim RED Provisionierungsserver nach einer neuen Konfig umzuschauen.

Bin nicht sicher ob das RED sich immer noch so verhält, das Problem liegt bei  mir schon ne ganze Weile zurück. Aber mit dem obigen Workaround über ne zweite UTM oder ner zweiten Firewall VOR Deiner UTM kann es sein, dass Du das Ding wieder zum korrekten Betrieb motivieren kannst, sofern das Problem tatsächlich daran liegen sollte, dass das RED keine neue Konfig abholen sollte.

Ist natürlich wie bei Andreas auch alles mal reine Spekulation (und etwas eigene Erfahrung aus der Vergangenheit) [[:)]][[:)]]

Hi Ron

Ich bin grad nicht sicher, was das neuerstellen des X.509 certs mit dem RED zu tun haben sollte.

Wenns das einzige RED ist, schreib Dir mal den Unlock Code auf und deaktiviere den RED Server auf der ASG komplett. Wenn weitere RED daran hängen, ist das natürlich keine Lösung ;o))

Du kannst das RED temporär auf eine andere UTM registrieren (Home UTM ???), und aktiviere den RED Part auf Deiner UTM wieder, sobald der Tunnel auf die temporäre UTM steht.

Danach das RED von der temporären UTM runterlöschen (Unlock Code aufschreiben !!!) und auf der "richtigen" UTM neu erstellen.

Ich glaub ich hatte das auch schon mal, dass das RED sich solange die neue Konfig NICHT abgeholt hatte, solange er seine UTM mit aktiviertem RED Dienst erreichen konnte (auch wenn da was geändert hat). Ich hatte damals temporär mit Hilfe einer zweiten UTM vor meiner UTM den TCP/UDP3400 Verkehr vom RED zur UTM geblockt, und damit das RED enforced sich zum Broker zu verbinden.

Alternative - Du kannst natürlich ebenfalls mit einer anderen Firewall vor der UTM einfach den Verkehr vom betroffenen RED zur UTM blocken, und damit das RED enforcen sich beim RED Provisionierungsserver nach einer neuen Konfig umzuschauen.

Bin nicht sicher ob das RED sich immer noch so verhält, das Problem liegt bei  mir schon ne ganze Weile zurück. Aber mit dem obigen Workaround über ne zweite UTM oder ner zweiten Firewall VOR Deiner UTM kann es sein, dass Du das Ding wieder zum korrekten Betrieb motivieren kannst, sofern das Problem tatsächlich daran liegen sollte, dass das RED keine neue Konfig abholen sollte.

Ist natürlich wie bei Andreas auch alles mal reine Spekulation (und etwas eigene Erfahrung aus der Vergangenheit) [[:)]][[:)]]