Umstellung OpenVPN (Legacy) auf OpenVPN instances

[BüroMensch]

Dieses Youtube-Video hat mir bei der Umstellung geholfen:
https://www.youtube.com/watch?v=Wiy7lbaQmrw

Ich habe allerdings die alte Zertifizierungsstelle, Server-Zertifikat und die Benutzer mit den bestehenden Klient-Zertifikaten weiterbenutzt und erst bei dem Punkt: Server in instances einrichten mit der Umstellung (Erstellung zusätzlich zum OpenVPN legacy) begonnen.

Hier gleich die Frage an die Experten: Wird das so mit den alten Zertifikaten, nach der Abschaffung von OpenVPN Legacy, funktionieren? Oder werden die alten Zertifikate gelöscht oder nicht kompatibel mit OpenVPN instances werden? Bitte nach Möglichkeit überprüfen!

Auf jeden Fall nach dem Abschluss der Konfiguration hat die Verbindung zum neuen OpenVPN-Server instances klaglos funktioniert. Ich konnte mich mit jeder IPv4 Adresse in meinem Netzwerk in der Firma verbinden, bzw. anpingen.

Ich habe jedoch die User nicht der Gruppe der Administratoren hinzugefügt, wie im Film und im Server unter instances die Einstellung "Server" ist eigentlich das Transport- oder Tunnel-Netzwerk gemeint und hier hat die Angabe des privaten IP-Bereichs 172.16.0.0 nicht funktioniert. Der Server wollte nicht starten. Warum? Keine Ahnung. Ich habe dann 10.0.0.0 genommen. Ganz wichtig, wenn man schon einen OpenVPN Legacy-Server am Laufen hat, muss man natürlich anderes Netzwerk wählen und einen anderen Port für die neue VPN-Verbindungen nehmen, anders als 1194 z.B. 1199 oder so.
Zum Schluss habe ich die User-VPN-Konfigurationen xxx.ovpn exportiert und in die VPN-Klient-Software eingelesen. Hat sofort alles funktioniert.
Jetzt ist Arbeit und Fleiß angesagt. Ich muss noch ca. 150 Benutzer einrichten.

Vielleicht war das alles umsonst und morgen werden welche Skripten veröffentlicht, die die ganze Arbeit einem abnehmen, aber ich wollte nicht warten.

Schönen Sonntag noch!

 

[viragomann]

Hier gleich die Frage an die Experten: Wird das so mit den alten Zertifikaten, nach der Abschaffung von OpenVPN Legacy, funktionieren?

Zertifikate sind völlig unabhängig von der OpenVPN Instanz (Server, Client, auch legacy). Wenn du eine Instanz löscht, bleiben die Zertifikate und die CA erhalten.

Oder werden die alten Zertifikate gelöscht oder nicht kompatibel mit OpenVPN instances werden?

Die Kompatibilität ist eine Frage der OpenSSL Version, die in OPNsense installiert ist, und mit welchen Parameter die Zertifikate generiert wurden. Die ist für legacy und Instances dieselbe.
Sie könnte sich natürlich in Zukunft mal ändern und ältere, dann als schwach geltende, Algorithmen könnten nicht mehr unterstützt werden.

[BüroMensch]

Super vielen Dank!

[Oachkatze]

Weiß man schon, ob es dafür künftig einen Konverter geben wird oder ob die Umstellung vereinfacht werden kann? Wir haben einige Verbindungen, die sonst manuell angepasst werden müssten.

[BüroMensch]

Es wurde eigentlich ausreichen, wenn es eine Möglichkeit gebe den alten (legacy) Server auf den neuen Server (instances) mit den gleichen Parametern zu klonen, da den meisten Aufwand hat man mit dem Export- und Anbindung der Konfigurationsdatei bei den Klienten.

[viragomann]

Die Client Konfig zu aktualisieren ist auch gar nicht nötig, wenn die Konfigurationsparameter in der neuen Instanz dieselben sind. Allerdings ist das oft nicht so, vor allem, wenn der Legacy Server schon älter ist.

In den neuen Instances sind einige Optionen nicht mehr verfügbar, die schon eine Zeit lang als veraltet gelten, in der aktuellen OpenVPN Version in OPNsense noch unterstützt werden, in zukünftigen aber nicht mehr.

Ändert man also Optionen, die auch am Client konfiguriert werden müssen, braucht der Client ein neues Konfig File.
Wenn du dir dessen nicht sicher bist, exportiere einfach von beiden Servern die Konfigurationen und vergleiche sie. Sind ja nur ein paar Zeilen.

[BüroMensch]

das sieht leider schon am Anfang nicht gut aus:

legacy:

dev tun
persist-tun
persist-key
data-ciphers-fallback AES-256-GCM
auth SHA512
client
resolv-retry infinite
remote xxx.xxx.xxx.xxx 1194 udp
remote yyy.yyy.yyy.yyy 1194 udp
lport 0
verify-x509-name "C=DE, ST=NDS, L=Stadt, O=Firma, emailAddress=mail@mail.com, CN=SERVER-CE" subject
remote-cert-tls server
auth-user-pass
compress lz4-v2
<ca>

instances:

dev tun
persist-tun
persist-key
client
resolv-retry infinite
remote xxx.xxx.xxx.xxx 1196 udp
remote yyy.yyy.yyy.yyy 1196 udp
lport 0
verify-x509-name "C=DE, ST=NDS, L=Stadt, O=Firma, emailAddress=mail@mail.com, CN=SERVER-CE" subject
remote-cert-tls server
auth-user-pass
<ca>

[Patrick M. Hausen]

Compression ist deprecated und die Cipher sollten automatisch ausgehandelt werden. Was fehlt noch?

[BüroMensch]

am Ende legacy:


............................
eV0OfZIEbdzw4gob8VyaH/PrpJ8F
-----END PRIVATE KEY-----
</key>
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
8870edd30ce654024741e8f9a2795f51
................................

-----END OpenVPN Static key V1-----
</tls-auth>
key-direction 1


instances:

............................
eV0OfZIEbdzw4gob8VyaH/PrpJ8F
-----END PRIVATE KEY-----
</key>
<tls-crypt>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
f9d1a9622bb3570205eb4a65f90382de
................................

-----END OpenVPN Static key V1-----
</tls-crypt>


die tls und static-keys sind leider anders

Danke

[viragomann]

die tls und static-keys sind leider anders

Für den neuen Server denselben TLS Key zu verwenden, liegt allein in deiner Macht.
Für den Encryption Mode gilt dasselbe.

Beides unter Instances am Reiter "Static Keys" zu konfigurieren.
Den Key kannst du vom Legacy Server kopieren und da bei dem neuen einfügen.
Unter Mode kannst du zwischen "auth" und "crypt" auswählen. Dein Legacy Server und damit die Clients verwenden offenbar "auth".

[BüroMensch]

ich habe so gemacht wie Du geschrieben hast. Der neue Server startet, die Schnittstelle startet, zeigt auch das Tunnel-Netzwerk, die Firewall Regel in der neuen Schnittstelle eingerichtet und aktiviert. Aber die Verbindung klappt leider nicht. Ich habe mir die Konfigurationen angeschaut:

legacy:

dev tun
persist-tun
persist-key
data-ciphers-fallback AES-256-GCM
auth SHA512
client
resolv-retry infinite
remote xxx.xxx.xxx.xxx 1194 udp
remote yyy.yyy.yyy.yyy 1194 udp
lport 0
verify-x509-name "C=DE, ST=NDS, L=Stadt, O=Firma, emailAddress=mail@mail.com, CN=SERVER-CE" subject
remote-cert-tls server
auth-user-pass
compress lz4-v2
<ca>


instances:


dev tun
persist-tun
persist-key
client
resolv-retry infinite
remote xxx.xxx.xxx.xxx 1194 udp
remote yyy.yyy.yyy.yyy 1194 udp
lport 0
verify-x509-name "C=DE, ST=NDS, L=Stadt, O=Firma, emailAddress=mail@mail.com, CN=SERVER-CE" subject
remote-cert-tls server
auth-user-pass
<ca>

der Rest stimmt überein.

Ergänzung:
Ich habe eine alte (vom legacy) Konfiguration bearbeitet und alles was in der neuen nicht vorhanden ist, gelöscht. Und voila, die Verbindung zum instances-Server steht. Jetzt muss ich noch herausfinden, was wirklich in der Konfiguration stört:

data-ciphers-fallback AES-256-GCM
auth SHA512
compress lz4-v2

das mache ich aber Morgen, weil sich heute schon genervte Mitarbeiter gemeldet haben :-(

[BüroMensch]

Das ist diese Eintragung in der alten (legacy) Konfiguration ovpn:

"auth SHA512"

die die Verbindung zum instances-Server verhindert.