[SOLVED] FAIL: Upgrade auf 20.7 via ssh ...

[white_rabbit]

Hallo.
Ich habe gerade das Upgrade auf 20.7 angeworfen -- so wie ich es zuvor schon x-fach gemacht habe.

Der Unterschied nun war jedoch: Ich war mit Wireguard -> ssh verbunden und dann .... ja: "epic fail": der wireguard socket wird ziemlich zu Beginn des Upgrades entfernt und das war's.

Meine Frage ist nun natürlich, wie/ob ich das Upgrade "gefahrlos" wieder aufnehmen kann, wenn ich das nächste Mal vor der Kiste sitze?

[franco]

Hallöchen,

"ziemlich zum Beginn" ist etwas wage.

Entweder so früh, dass die Shell terminiert und das Update nicht durchgeführt wird oder so spät dass der Reboot kam und das Update dann durchläuft...

Wahrscheinlicher ist letzteres weil das Update nicht mit Wireguard oder SSH interagiert, d.h. wenn es nicht der Upgrade Reboot war dann ist einfach die Verbindung abgebrochen.


Grüsse
Franco

[chemlud]

...es gibt vereinzelt Hinweise auf "Startschwierigkeiten" mit Wireguard nach updaten auf 20.7

z.B. https://forum.opnsense.org/index.php?topic=18497.0

[mimugmail]

Ja, bitte nicht per WireGuard. Es schwirrt ein Howto irgendwo rum wo man dem WireGuard Endpoint die Netze hinterlegt die er gepusht bekommen soll. FreeBSD 11 hat das einfach ignoriert, bei 12 startet er nicht.

[white_rabbit]

Ok, also vermutlich hängt der Upgrade-Prozess jetzt -- jedenfalls komme ich nicht mehr per ssh drauf.

Wie gehe ich nun vor, wenn ich vor Ort bin? Einfach auf der Konsole erneut die "12" oder was ist der beste Weg?

[white_rabbit]

Ok, ein Kollege war vor Ort und hat gesehen, dass V20.7.1 aktiv ist ... zudem ist immerhin im Webinterface das Symbol für den Wireguard-Service auf "grün". Dennoch kommt keine Verbindung mehr zustande.
Ist das nun ein Bug oder was ist zu tun?

[mimugmail]

Kein Bug, falsche WireGuard config.
Der Kollege soll für deine IP Zugriff auf die UI freischalten (ohne VPN), dann schaust du mal.

[white_rabbit]

Hi.
Ja, davon ist ja auch im zitierten englischen Thread zu lesen -- aber mir ist nicht ganz klar, was nun zu ändern ist. Bezieht sich die Netzmaske /32 auf die Client-Seite (also hier lokal) oder bezieht es sich auf die Endpoint-Konfiguration in der WebUI? Wo genau soll die /24 durch die /32 ersetzt werden?

Und so wie ich es verstanden habe, hat das nicht überall geholfen. Bei einigen lag es auch an einem anderen Problem??

[mimugmail]

Im Endpoint /32 in Local /24

[white_rabbit]

Ich kann's zwar erst Montag nachsehen, aber damals bin ich dieser Anleitung gefolgt:
https://www.ja-ki.eu/2019/02/19/wireguard-vpn-mit-opnsense-und-tunsafe/

Da steht für die Endpoints bereits /32.
Ich hatte gehofft, dass die Anleitung einen Fehler hatte ... daher die Frage hinterher: Was tun, wenn bei den Endpoints bereits /32 steht?

[mimugmail]

Kannst du Mal ein anderes Netz nehmen und nicht das CGN? Eventuell zählt das zu Bogon

[white_rabbit]

Du meinst, dass evtl 100.64.0.0/24 nicht (mehr) als Wireguard-Netz aktzeptiert wird?
Was hat sich denn im Vergleich zu 20.1 so grundlegend geändert, dass es daran liegen könnte??

[mimugmail]

Ich rate nur wenn du keine detaillierten Screenshots postest

[white_rabbit]

Ok, jetzt bin ich vor Ort ... also die Endpoints stehen alle auf /32 -- der Wireguardserver auf /24.
Das sollte also stimmen.
Wenn ich den VPN-Tunnel z.B. vom Smartphone aus öffne, gibt es keine Fehlermeldung -- aber in den LiveLogs auf der OPNSense erscheint auch nichts. Ich meine, dass sonst zumindest der Verbindungsaufbau auf Port 51820 quittiert wurde??

[mimugmail]

Screenshots von local und endpoint