IPsec-Tunnel: "no shared key found for ..."

[Emma2]

"Natürlich" verstehe ich nicht alles, was Du gerade gefragt hast, "aber":

• Auf beiden OPNsense sind für den Tunnel alle Ports offen (meine ich zumindest).
• Der Tunnel wird nur von der einen Seite aufgebaut, um irgendwelche - für mich unerwarteten - Kollisionen zu vermeiden.
• Ausprobiert habe ich es aber schon von beiden Seiten, und es funktionierte.
• Im Problemfall vorgestern habe ich es ebenfalls von beiden Seiten probiert, aber es hat von keiner Seite aus geklappt, selbst nach einem knappen Tag "Wartezeit" nicht.

Als Nichtkenner finde ich ja die Fehlermeldung so seltsam, dass der PSK nicht gefunden würde, denn das habe ich natürlich überprüft, und er war auf beiden OPNsense eingetragen (muss ja auch, sonst hätte es ja nicht nach einem Neustart sofort wieder funktioniert).

[JeGr]

"Natürlich" ist doof, dann muss ichs anders fragen :)

-> Auf beiden OPNsense sind für den Tunnel alle Ports offen (meine ich zumindest).

Das wäre nicht das Problem, sondern die Geräte oder Router DAVOR :)

-> Der Tunnel wird nur von der einen Seite aufgebaut, um irgendwelche - für mich unerwarteten - Kollisionen zu vermeiden.

Hast du also auf einer Sense dediziert eingestellt "responder only" und auf einer dann default oder konkret initiator in phase 1?

Unwissende andere Frage: sind wirklich beide Seiten Sensen in gleicher Version? Hat das einen tieferen Grund, dass da uraltes 3DES verwendet wird zum Aushandel von einem aktuellen Tunnel? Frage nur weil das typische FritzBox Einstellungen sind (3DES,SHA512,DH2) aber das kein Mensch für nen modernen Tunnel nutzen würde?

[Emma2]

"Natürlich" ist doof, dann muss ichs anders fragen :)

Nee, das "natürlich" bezog sich auf meine mangelnde Detailkenntnis.

Hast du also auf einer Sense dediziert eingestellt "responder only" und auf einer dann default oder konkret initiator in phase 1?

Ja, genau, so habe ich das eingestellt: "Sofort starten" und "Nur antworten" in der GUI.
BTW: Gibt es irgendwo eine gute Beschreibung für die Nicht-GUI-Seite der OPNsense? Das OPNsense-Buch habe ich, habe aber erst das Lesen begonnen...

Unwissende andere Frage: sind wirklich beide Seiten Sensen in gleicher Version? Hat das einen tieferen Grund, dass da uraltes 3DES verwendet wird zum Aushandel von einem aktuellen Tunnel? Frage nur weil das typische FritzBox Einstellungen sind (3DES,SHA512,DH2) aber das kein Mensch für nen modernen Tunnel nutzen würde?

Ja, ich aktualisiere beide OPNsense recht regelmäßig, alle paar Wochen einmal.

Die Einstellungen für den Tunnel sind mir - als Nicht-Experte - im Detail unklar, denn den Tunnel habe ich vor etwa drei Jahren nach irgend einer Step-by-Step eingerichtet (im Zweifel immer vom Thomas-Krenn-Wiki).

Die Idee, dass der Tunnel nur von einer Seite aus aufgebaut wird, war tatsächlich historisch, denn vorher hatte ich an beiden Standorten den unsäglichen (zum Glück mittlerweile verschwundenen) MS-TMG im Einsatz, und der machte regelmäßig eine Art Deadlock, wenn beide Seiten gleichzeitig den Tunnelaufbau versuchten... danke an MS übrigens, denn unter anderem war der TMG der Grund dafür, dass ich mich überhaupt mit Alternativen beschäftigt habe und mittlerweile fast alle Server auf Linuxen laufen habe (oder BSD für die OPNsense).

Aber tatsächlich ist dieses Problem nun, nach etwa drei Jahren, erstmalig aufgetaucht, das finde ich ja so seltsam. Die einzige Änderung (außer Updates der OPNsense) war, dass ich die hiesige von Hyper-V/Win portiert habe auf VirtualBox/Ubuntu (die entfernte wird im August umgestellt) - aber dabei gab es ja keine Änderungen außer an den virtuellen Adaptern.

[Emma2]

Ach so, Nachtrag: Tja, die uralten Einstellungen kommen dann vielleicht aus einem uralten "HOWTO"? ::)
Gibt es irgendwo ein moderneres ("für Dummies")?

... oder überhaupt mal eine Erläuterung, warum z.B. immer wieder jemand empfiehlt, dass IPsec doof ist und man absolut lieber OpenVPN nehmen muss? Das wüsste ich ja auch mal gerne, warum das so ist oder so sein soll...

[mimugmail]

Schau dir auf YouTube das Video zu VPN von mir und Thomas Krenn an, das hilft bestimmt

[Emma2]

Jau, mach ich, danke.
Worauf achte ich dann besonders? Was an meinen Einstellungen ist denn "veraltet"?

[mimugmail]

Da geht es allgemein wann man OpenVPN und IPsec mach :)

[Emma2]

Ok, macht ja aber trotzdem Sinn.
Und dennoch: was gefällt Dir an meinen Einstellungen nicht?

[mimugmail]

Ich hab mir deine Einstellungen weder angeschaut noch mich dazu geäußert. Laut Logs verwendest du 3DES mit SHA512, das solltest du vielleicht auf AES 256 ändern. SHA alles ab 256 und DH alles ab 14. (Ich glaub 22 und 23 wieder nicht und dann bis 31 alles ok)

[Emma2]

Ja, danke, das passt zu dem, was "JeGr" oben schrieb. Ich werde das testweise mal umstellen.
Danke an Euch alle!

[Emma2]

Ich hab mir deine Einstellungen weder angeschaut noch mich dazu geäußert. Laut Logs verwendest du 3DES mit SHA512, das solltest du vielleicht auf AES 256 ändern. SHA alles ab 256 und DH alles ab 14. (Ich glaub 22 und 23 wieder nicht und dann bis 31 alles ok)

Da ich alles nur über die GUI kann:

• Bei mir steht dort "256 bit AES-GCM with 128 bit ICV". Das meinst Du?
• SHA 512 kann ich stehen lassen?
• Macht es Sinn, die "Schlüsselgruppe" zu ändern? Dann auf 31? Oder ist das "wurscht"?
• Wird das vom Tunnel auf die einzelnen Netze "vererbt", oder muss ich die Einträge alle ändern?
• Um das zu ändern, muss ich auf beide OPNsense direkt, also OHNE Tunnel, draufkommen?

[JeGr]

Ich hab mir deine Einstellungen weder angeschaut noch mich dazu geäußert. Laut Logs verwendest du 3DES mit SHA512, das solltest du vielleicht auf AES 256 ändern. SHA alles ab 256 und DH alles ab 14. (Ich glaub 22 und 23 wieder nicht und dann bis 31 alles ok)

Hat er gut auf den Punkt gebracht :)

TL;DR:

Für Kompatibilität > all:
AES-128-CBC, SHA256, DH14

Für Performance:
AES-128-GCM, SHA256, DH19, 31 oder 14

Für Security > all
AES-256-GCM, SHA-384/512, DH21 oder 31

Bei OpenVPN ebenso, da kann man allerdings noch nicht die DH Parameter auf ECDH only einstellen wie bei der pfSense (muss ich mal nen Feature Request zu machen :)) ansonsten auch hier die gleichen Settings:

AES-128-CBC,SHA256, DH 2k/4k für kompat. mit alten Gegenstellen wenn welche VORHANDEN sind!

Wenn man eh alles selbst ausrollt und neu macht:

AES-128/256-GCM, SHA256, DH2k/4k

Das letzte Mal als ich die 21.7rc reingeschaut hatte, war da die data-ciphers Option noch nicht am Start um mehrere Cipher auszuwählen aber das kommt sicher noch. Wenn das geht, dann wählt man sich den gewünschten AES-GCM aus und zusätzlich CHACHA2-POLY1305 noch, wenn man Mobilgeräte hat.

--

long version background try:

3DES ist seit längerem veraltet und nicht mehr wirklich als sicher angesehen, daher kaum mehr genutzt außer man muss aus Kompatibilität und von oben abgesegnet mit irgendwelchen ganz alten Gurken sprechen die nichts anderes können.

Ansonsten mind. AES-128(-CBC) und im Optimalfall auf ordentlicher HW die AES-NI kann AES-256-GCM. GCM > CBC was Performance angeht, da GCM von der HW besser "gerechnet" werden kann (ums einfach auszudrücken). Dadurch weniger CPU Load, dadurch mehr Performance bevor ein Kern ausgemaxt ist, dadurch mehr Bandbreite :)

SHA-1 ist wie MD5 inzwischen auch nicht mehr so gern gesehen als Hash bei VPNs, daher mind. SHA-256. Das reicht dafür aber auch ganz gut, wer mehr will kann auch SHA-384 nehmen, SHA-512 ist eigentlich schon wieder Overkill ;)

Bei den DH Gruppen sind elliptische Kurven (EC) inzwischen lieber gesehen als die klassischen RSA Bitstärken. Alles kleiner als 2048Bit RSA ist unsicher, 2k selbst ist am "wackeln" und wird zumindest vom BSI bspw. demnächst abgelöst mit 3072 oder mehr. Besser sind die elliptischen Kurven: NIST EC256,284 oder 521 (nicht 512, das ist so richtig) also DH Group 19-21 sind da empfohlen. 22-24 sollte man meiden - die sind kryptografisch zu schwach und nicht mehr relevant oder ggf. gebrochen. Die Brainpool 28-30 kommen IMHO sogar aus DE, sind aber schlechter in HW zu rechnen (war mein letzter Stand), daher "OK aber wenn Performance, lieber NIST EC. Ansonsten ist DH 31 noch eine gute Wahl, die inzwischen auch mal bei größeren Firmen ankommt. Sophos kann bspw. inzwischen auch mal DH 31. Das ist die EC25519 - kennt man als genutzte Chiffre bspw. bei SSH als ED25519 Key zur Generierung von SSH Keys und wird dort über allen anderen Varianten empfohlen weil starke Crypto und gute Kurve.

Zu OpenVPN: AES-NI in x64 CPUs beschleunigt AES enorm, gibt es aber bei ARM Geräten nicht. Diese können dafür mit CHACHA20-POLY1305 der wesentlich leichter zu rechnen ist, ordentliche Sicherheit bei VPNs haben und das dazu performanter nutzen als sich mit AES abzumühen. Wenn der Server via data-ciphers beides unterstützt kann man die Desktop/Laptop Clients mit x64 mit AES ausrollen und Mobiles mit CHACHA20 und hat the best of both worlds. :)

--

Kann aber die Videos von Mimugmail dazu wirklich empfehlen, ist eine schöne Zusammenfassung was warum und weshalb.

OpenVPN ist eben wesentlich flexibler und interessanter nutzbar als IPsec was an sehr starre Setup-Punkte gebunden ist und durch seine Ports und Tunnelart vielfach mehr Probleme hat, als ein simples SSL-VPN wie OpenVPN. OpenVPN hat dafür Probleme bei der Performance weil es im Gegensatz zu IPsec nicht im Kernel implementiert ist. Wireguard springt da als ganz neuer Contender mittenrein, weil es enorm schnell und flexibel ist aber auch im Kernel laufen kann und daher schneller agiert als OVPN. Allerdings ist es so neu bzw. anders, dass einige Dinge, die mit OVPN kein Problem sind hier (noch!) nicht so einfach zu lösen sind (CARP, HA, MultiVPN Tunnel etc.)

Cheers

[Emma2]

Danke, JeGr, für die ausführliche Info, muss ich mir jetzt mal ganz in Ruhe zu Gemüte führen. Und das Video sehe ich mir auch an. Ihr meint dieses https://www.youtube.com/watch?v=wq-M0bAFViE&t=442s?

Aber eine eventuelle Umstellung auf OpenVPN will ich dann "in Ruhe" machen und nicht unter dem Druck, den Tunnel schnell wieder aufbauen zu müssen. In diesem Zusammenhang ein Update und zwei weitere Fragen:

Ich hatte gestern im entfernten Standort in Südschweden einen mehrstündigen Stromausfall, und danach baute sich der Tunnel nicht wieder von allein auf. Allerdings funktionierte der manuelle Aufbau auch nicht, jedoch diesmal mit einer anderen Fehlermeldung:

Code Select Expand


authentication of <myGermanIP> (myself) with pre-shared key
establishing CHILD_SA con1{6}
generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ IDr AUTH N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
sending packet: from <myGermanIP>[4500] to <mySwedishIP>[4500] (528 bytes)
received packet: from <mySwedishIP>[4500] to <myGermanIP>[4500] (88 bytes)
parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
received AUTHENTICATION_FAILED notify error


Nun meine Fragen:

• Kann der Fehler mit meinen Einstellungen zu tun haben? Ist es denkbar, dass die irgendwie "nicht mehr" funktionieren?
• Beim Ändern der Einstellungen: Was ist der Unterschied zwischen "AES (256 bits)" und "256 bit AES-GCM"

Ich habe jedenfalls "mal eben" umgestellt auf "AES (256 bits)" mit Schlüsselgruppe 31 - und damit gelingt der Tunnelaufbau "sofort" (deshalb meine Frage, ob die bisherigen Einstellungen vielleicht "grundsätzlich" nicht mehr funktionieren: aber dieser Verdacht wäre wohl paranoid, oder?).

[JeGr]

Ah noch eine kurze Korrektur dazu:

Wenn auf beiden Seiten verfügbar: bei einem GCM Algo dann bei Hash lieber auf AES-XCBC gehen, da beide dann von AES-NI profitieren können und bei GCM per se eigentlich kein wirklicher Hash mehr genutzt wird, sondern eine PRF (pseudo random function) benötigt wird. Das kann XCBC abdecken und ist dafür dann schlanker.  Oft können aber - wie GCM auch - das die kommerziellen Pendants auf der Gegenseite nicht. Oder wollen es nicht damit sie vielleicht teurere HW verkaufen können? ;)

Zudem P1 Lifetime: ~28800 guter Wert. Max. sollte nach Empfehlung nicht mehr als 86400 sein.
P2 Lifetime ist dann relevant für PFS und sollte bei ~3600s liegen, nicht mehr und kleiner als P1 aber liegen (also ~max <28800).

---

Gute Quellen sind da u.a. die BSI recommendations dafür (TRs - Technische Richtlinien) sowie div. Crypto Empfehlungen von Herstellern. Witzig dabei ist, dass selbst Cisco bspw. nen Dokument am Start hat, das seit Jahren bereits GCM empfiehlt, ich aber immer wieder von Gegenseiten höre, die alte Cisco ASAs o.ä. im Einsatz haben aber kein GCM können ;)

Auch gut für kurze Übersichten: https://www.privacy-handbuch.de/handbuch_97.htm

---

AUTHENTICATION_FAILED gibts IMHO 2x, einmal als Main/Aggressive Mode Aushandlungs-Fail, einmal als P1 ID Mismatch. Also keine passende Phase 1 ID. Das würde heißen, dass die IDs nicht passen, also das, was default auf "my IP address" und "peer IP address" stehen. Das wären sonst die einzigen 2 Punkte wo ich AUTH FAILs im normalen Ablauf kenne

> Beim Ändern der Einstellungen: Was ist der Unterschied zwischen "AES (256 bits)" und "256 bit AES-GCM"

Das sind völlig andere Cipher. AES ist hier meist Kurzform für AES-CBC-256, während das andere AES-GCM-256 darstellt. Das sind andere Arten zu chiffrieren und zu rechnen, daher nicht kompatibel zueinander. Man kann also nicht die eine Seite mit CBC und die andere mit GCM nehmen.

Cheers

[Emma2]

Oh, Menno, mir schwirrt der Kopf... :P
Die Lebenszeiten dort sind jedoch schon 28800 für P1 und 3600 für P2.

Verfügbar ist natürlich auf beiden Seiten das gleiche (weil auf beiden Seiten die gleiche OPNsense ist).
Also stelle ich den Hash von SHA512 um auf AES-XCBC. Aber, oh, das funktioniert reproduzierbar nicht.
In VPN/IPsec/Statusübersicht ist der Tunnel (der Abspieln-Button) zwar grün, aber im Dashboard sehe ich, dass der Tunnel nicht steht, und er kann auch nicht aufgebaut werden. Nach dem Zurückändern geht es sofort wieder.
Müsste ich mehr tun, als SHA512 ab- und AES-XCBC an-zuwählen?