... und schon wieder bin ich verwirrt: Ich habe ganz, ganz sicher nichts an meinen beiden OPNsense geändert (schon deshalb nicht, weil ich gerade Dringenderes mache). Dennoch stand heute morgen der Tunnel zwischen meinen Standorten nicht. Das wollte ich nutzen, um den funktionierenden Tip aus https://forum.opnsense.org/index.php?topic=23975.0 (https://forum.opnsense.org/index.php?topic=23975.0) anzuwenden.
Doch was passiert? Es geht nicht! (Liegt aber nicht am Tip, der hat funktioniert!)
Ich erhalte jedoch eine Fehlermeldung:
authentication of '<myFirstIP>' (myself) with pre-shared key
no shared key found for '<myFirstIP>' - '<mySecondIP>'
establishing connection 'con1' failed
Auf beiden OPNsense finden sich die gleichen (unveränderten!) VPN-IPsec-Tunneleinstellungen.
Ich bin vermutlich wieder zu ungeduldig, aber ein kleines bisschen "pressiert's mich".
Hat niemand eine Idee, was ich wie reparieren muss?
Dann kann der Tunnel aus irgendeinem Grund nur von einer Seite aufgebaut werden.
Also entweder machst du den Hack auf der anderen Seite oder du postest die config und logs.
Vergiss den IPsec Quatsch. Mach openVPN oder Wireguard und fertig. Ich habe mich auch mal mit dem Kram rumgeschlagen. Für site-to-site waren mit IPsec viel mehr Unterbrechungen als mit den anderen beiden...
Quote from: chemlud on July 22, 2021, 03:12:30 PM
Vergiss den IPsec Quatsch.
Das hat jetzt aber mindestens drei Jahre völlig problemlos funktioniert.
Quote from: chemlud on July 22, 2021, 03:12:30 PM
Mach openVPN oder Wireguard und fertig.
... wobei ich mangels Kenntnisse keine echte Vorliebe habe. Gibt es für einen Tunnel per openVPN oder Wirecard ein gutes HOWTO?
Quote from: mimugmail on July 22, 2021, 03:02:12 PM
Dann kann der Tunnel aus irgendeinem Grund nur von einer Seite aufgebaut werden.
Also entweder machst du den Hack auf der anderen Seite
Das habe ich versucht, gleicher Fehler von beiden Seiten.
Quote from: mimugmail on July 22, 2021, 03:02:12 PM
oder du postest die config und logs.
Mache ich gerne. Welche Dateien sind das, und wo stehen die?
phase1 und phase2 von beiden seiten und dann die logs wenn der fehler kommt mit up/down
Da ich mich "nicht so gut" auskenne, meinte ich eher, wo ich die finde und wie die genau heißen.
(NB: Ich kenne mich so wenig aus, dass ich - zumindest noch - alles per GUI mache, machen muss).
Aber das Problem hat sich nun (erst einmal) gelöst: Ich habe den "Windows-Trick" angewendet und beide OPNsense neu gestartet (ja, ich komme zum Glück remote auf beide drauf). Danach stand der Tunnel auf Anhieb wieder.
(Hätte nicht gedacht, dass das bei einem Unixoiden helfen kann, ich dachte, das sei nur bei MS-Zeugs so.)
Langer Rede kurzer Sinn: haben wir (habt Ihr) jetzt noch eine Chance, dem Problem forensisch nachzugehen?
Oder macht das wenig Sinn, und ich sollte lieber hinnehmen, dass auch eine OPNsense von Zeit zu Zeit mal einen Neustart "braucht"?
Falls das wichtig sein könnte: Meine OPNsense laufen beide als VM (die eine als VB auf Ubuntu, die andere noch als HV auf WinSvr). Die hiesige (VB/Ubu) wird einmal pro Woche per "ACPIPOWERBUTTON" heruntergefahren und dann per RSYNC gesichert, danach wieder gestartet. Wenn das herunterfahren nicht klappt (weil sie nicht auf den Befehl reagiert), dann wird sie auch nicht gesichert. Es kann aus meiner Sicht hier also eigentlich nichts schiefgehen. Aber ich will es dennoch zur Info berichten.
Nein, neu starten muss man nicht (hinnehmen). Im IPsec Menü sind doch logs, einfach drauf und runterladen, dann die Zeiten vergleichen wann der Ausfall war und posten
Suche ich sofort raus...
Der nicht-funktionierende Versuch, den Tunnel aufzubauen, sieht so aus:
2021-07-22T13:45:22 charon[36881] 15[IKE] <con1|31> no shared key found for '<meine-Heim-IP>' - '<meine-Fern-IP>'
2021-07-22T13:45:22 charon[36881] 15[IKE] <con1|31> authentication of '<meine-Heim-IP>' (myself) with pre-shared key
2021-07-22T13:45:22 charon[36881] 15[IKE] <con1|31> sending cert request for "C=US, O=(STAGING) Let's Encrypt, CN=(STAGING) Artificial Apricot R3"
2021-07-22T13:45:22 charon[36881] 15[IKE] <con1|31> sending cert request for "C=US, O=Let's Encrypt, CN=R3"
2021-07-22T13:45:22 charon[36881] 15[IKE] <con1|31> sending cert request for "C=DE, ST=<meinLand>, L=<meineStadt>, O=<meineFirma>, E=info@<meineFirma>.de, CN=<meineFirma>-DE-CA"
2021-07-22T13:45:22 charon[36881] 15[IKE] <con1|31> sending cert request for "C=DE, ST=<meinBundesland>, L=<meineStadt>, O=<meineFirma>, E=info@<meineFirma>.de, CN=OpenVPN CA DE"
2021-07-22T13:45:22 charon[36881] 15[IKE] <con1|31> sending cert request for "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3"
2021-07-22T13:45:22 charon[36881] 15[IKE] <con1|31> sending cert request for "CN=Fake LE Intermediate X1"
2021-07-22T13:45:22 charon[36881] 15[IKE] <con1|31> received 2 cert requests for an unknown ca
2021-07-22T13:45:22 charon[36881] 15[IKE] <con1|31> received cert request for "C=US, O=(STAGING) Let's Encrypt, CN=(STAGING) Artificial Apricot R3"
2021-07-22T13:45:22 charon[36881] 15[IKE] <con1|31> received cert request for "C=US, O=Let's Encrypt, CN=R3"
2021-07-22T13:45:22 charon[36881] 15[IKE] <con1|31> received cert request for "CN=Fake LE Intermediate X1"
2021-07-22T13:45:22 charon[36881] 15[IKE] <con1|31> received cert request for "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3"
2021-07-22T13:45:22 charon[36881] 15[CFG] <con1|31> selected proposal: IKE:3DES_CBC/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048_256
2021-07-22T13:45:22 charon[36881] 15[ENC] <con1|31> parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
2021-07-22T13:45:22 charon[36881] 15[NET] <con1|31> received packet: from <meine-Fern-IP>[500] to <meine-Heim-IP>[500] (593 bytes)
2021-07-22T13:45:22 charon[36881] 15[NET] <con1|31> sending packet: from <meine-Heim-IP>[500] to <meine-Fern-IP>[500] (460 bytes)
2021-07-22T13:45:22 charon[36881] 15[ENC] <con1|31> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
2021-07-22T13:45:22 charon[36881] 15[IKE] <con1|31> initiating IKE_SA con1[31] to <meine-Fern-IP>
2021-07-22T13:45:22 charon[36881] 10[CFG] received stroke: initiate 'con1'
Aber nach dem Neustart ging's sofort und automatisch:
2021-07-22T21:44:14 charon[86343] 07[KNL] creating rekey job for CHILD_SA ESP/0xcf832cf5/<meine-Heim-IP>
2021-07-22T21:01:09 charon[86343] 11[ENC] <con1|1> parsed INFORMATIONAL response 4 [ ]
2021-07-22T21:01:09 charon[86343] 11[NET] <con1|1> received packet: from <meine-Fern-IP>[4500] to <meine-Heim-IP>[4500] (80 bytes)
2021-07-22T21:01:09 charon[86343] 11[NET] <con1|1> sending packet: from <meine-Heim-IP>[4500] to <meine-Fern-IP>[4500] (136 bytes)
2021-07-22T21:01:09 charon[86343] 11[ENC] <con1|1> generating INFORMATIONAL request 4 [ N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) ]
2021-07-22T21:01:09 charon[86343] 11[IKE] <con1|1> sending address list update using MOBIKE
2021-07-22T21:01:09 charon[86343] 05[KNL] 192.168.5.1 appeared on ovpns1
2021-07-22T21:01:09 charon[86343] 12[KNL] interface ovpns1 activated
2021-07-22T21:01:09 charon[86343] 12[IKE] <con1|1> CHILD_SA con1{2} established with SPIs ccb36a96_i c4959463_o and TS 192.168.0.0/24 192.168.4.0/24 === 192.168.2.0/24 192.168.6.0/24
2021-07-22T21:01:09 charon[86343] 12[CFG] <con1|1> selected proposal: ESP:3DES_CBC/HMAC_SHA2_512_256/MODP_2048/NO_EXT_SEQ
2021-07-22T21:01:09 charon[86343] 12[IKE] <con1|1> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
2021-07-22T21:01:09 charon[86343] 12[ENC] <con1|1> parsed CREATE_CHILD_SA response 3 [ N(ESP_TFC_PAD_N) SA No KE TSi TSr ]
2021-07-22T21:01:09 charon[86343] 12[NET] <con1|1> received packet: from <meine-Fern-IP>[4500] to <meine-Heim-IP>[4500] (512 bytes)
2021-07-22T21:01:09 charon[86343] 12[NET] <con1|1> sending packet: from <meine-Heim-IP>[4500] to <meine-Fern-IP>[4500] (512 bytes)
2021-07-22T21:01:09 charon[86343] 12[ENC] <con1|1> generating CREATE_CHILD_SA request 3 [ N(ESP_TFC_PAD_N) SA No KE TSi TSr ]
2021-07-22T21:01:09 charon[86343] 12[IKE] <con1|1> establishing CHILD_SA con1{2}
2021-07-22T21:01:09 charon[86343] 12[ENC] <con1|1> parsed INFORMATIONAL response 2 [ ]
2021-07-22T21:01:09 charon[86343] 12[NET] <con1|1> received packet: from <meine-Fern-IP>[4500] to <meine-Heim-IP>[4500] (80 bytes)
2021-07-22T21:01:09 charon[86343] 12[CFG] received stroke: initiate 'con1'
2021-07-22T21:01:09 charon[86343] 16[CFG] added configuration 'con1'
2021-07-22T21:01:09 charon[86343] 05[NET] <con1|1> sending packet: from <meine-Heim-IP>[4500] to <meine-Fern-IP>[4500] (128 bytes)
2021-07-22T21:01:09 charon[86343] 05[ENC] <con1|1> generating INFORMATIONAL request 2 [ N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) ]
2021-07-22T21:01:09 charon[86343] 05[IKE] <con1|1> sending address list update using MOBIKE
2021-07-22T21:01:09 charon[86343] 05[KNL] interface ovpns1 deactivated
2021-07-22T21:01:09 charon[86343] 14[KNL] 192.168.5.1 disappeared from ovpns1
2021-07-22T21:01:09 charon[86343] 16[CFG] received stroke: add connection 'con1'
2021-07-22T21:01:09 charon[86343] 14[CFG] deleted connection 'con1'
2021-07-22T21:01:09 charon[86343] 14[CFG] received stroke: delete connection 'con1'
2021-07-22T21:01:09 charon[86343] 16[CFG] rereading crls from '/usr/local/etc/ipsec.d/crls'
2021-07-22T21:01:09 charon[86343] 16[CFG] rereading attribute certificates from '/usr/local/etc/ipsec.d/acerts'
2021-07-22T21:01:09 charon[86343] 16[CFG] rereading ocsp signer certificates from '/usr/local/etc/ipsec.d/ocspcerts'
2021-07-22T21:01:09 charon[86343] 16[CFG] rereading aa certificates from '/usr/local/etc/ipsec.d/aacerts'
2021-07-22T21:01:09 charon[86343] 16[CFG] loaded ca certificate "C=US, O=(STAGING) Let's Encrypt, CN=(STAGING) Artificial Apricot R3" from '/usr/local/etc/ipsec.d/cacerts/d51988df.0.crt'
2021-07-22T21:01:09 charon[86343] 16[CFG] loaded ca certificate "C=US, O=Let's Encrypt, CN=R3" from '/usr/local/etc/ipsec.d/cacerts/8d33f237.0.crt'
2021-07-22T21:01:09 charon[86343] 16[CFG] loaded ca certificate "C=DE, ST=<meinLand>, L=<meineStadt>, O=<meineFirma>, E=info@<meineFirma>.de, CN=<meineFirma>-DE-CA" from '/usr/local/etc/ipsec.d/cacerts/0a9b39ac.0.crt'
2021-07-22T21:01:09 charon[86343] 16[CFG] loaded ca certificate "C=DE, ST=<meinBundesland>, L=<meineStadt>, O=<meineFirma>, E=info@<meineFirma>.de, CN=OpenVPN CA DE" from '/usr/local/etc/ipsec.d/cacerts/eefe3217.0.crt'
2021-07-22T21:01:09 charon[86343] 16[CFG] loaded ca certificate "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3" from '/usr/local/etc/ipsec.d/cacerts/4f06f81d.0.crt'
2021-07-22T21:01:09 charon[86343] 16[CFG] loaded ca certificate "CN=Fake LE Intermediate X1" from '/usr/local/etc/ipsec.d/cacerts/0a3654cf.0.crt'
2021-07-22T21:01:09 charon[86343] 16[CFG] rereading ca certificates from '/usr/local/etc/ipsec.d/cacerts'
2021-07-22T21:01:09 charon[86343] 16[CFG] expanding file expression '/usr/local/etc/ipsec.secrets.opnsense.d/*.secrets' failed
2021-07-22T21:01:09 charon[86343] 16[CFG] loaded IKE secret for <meine-Fern-IP>
2021-07-22T21:01:09 charon[86343] 16[CFG] loading secrets from '/usr/local/etc/ipsec.secrets'
2021-07-22T21:01:09 charon[86343] 16[CFG] rereading secrets
2021-07-22T21:01:06 charon[86343] 16[IKE] <con1|1> peer supports MOBIKE
2021-07-22T21:01:06 charon[86343] 16[IKE] <con1|1> received AUTH_LIFETIME of 27868s, scheduling reauthentication in 27328s
2021-07-22T21:01:06 charon[86343] 16[IKE] <con1|1> CHILD_SA con1{1} established with SPIs cf832cf5_i cc71bdd2_o and TS 192.168.0.0/24 192.168.4.0/24 === 192.168.2.0/24 192.168.6.0/24
2021-07-22T21:01:06 charon[86343] 16[CFG] <con1|1> selected proposal: ESP:3DES_CBC/HMAC_SHA2_512_256/NO_EXT_SEQ
2021-07-22T21:01:06 charon[86343] 16[IKE] <con1|1> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
2021-07-22T21:01:06 charon[86343] 16[IKE] <con1|1> maximum IKE_SA lifetime 28587s
2021-07-22T21:01:06 charon[86343] 16[IKE] <con1|1> scheduling reauthentication in 28047s
2021-07-22T21:01:06 charon[86343] 16[IKE] <con1|1> IKE_SA con1[1] established between <meine-Heim-IP>[<meine-Heim-IP>]...<meine-Fern-IP>[<meine-Fern-IP>]
2021-07-22T21:01:06 charon[86343] 16[IKE] <con1|1> authentication of '<meine-Fern-IP>' with pre-shared key successful
2021-07-22T21:01:06 charon[86343] 16[ENC] <con1|1> parsed IKE_AUTH response 1 [ IDr AUTH N(ESP_TFC_PAD_N) SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) ]
2021-07-22T21:01:06 charon[86343] 16[NET] <con1|1> received packet: from <meine-Fern-IP>[4500] to <meine-Heim-IP>[4500] (344 bytes)
2021-07-22T21:01:06 charon[86343] 16[NET] <con1|1> sending packet: from <meine-Heim-IP>[4500] to <meine-Fern-IP>[4500] (528 bytes)
2021-07-22T21:01:06 charon[86343] 16[ENC] <con1|1> 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) ]
2021-07-22T21:01:06 charon[86343] 16[IKE] <con1|1> establishing CHILD_SA con1{1}
2021-07-22T21:01:06 charon[86343] 16[IKE] <con1|1> authentication of '<meine-Heim-IP>' (myself) with pre-shared key
2021-07-22T21:01:06 charon[86343] 16[IKE] <con1|1> sending cert request for "C=US, O=(STAGING) Let's Encrypt, CN=(STAGING) Artificial Apricot R3"
2021-07-22T21:01:06 charon[86343] 16[IKE] <con1|1> sending cert request for "C=US, O=Let's Encrypt, CN=R3"
2021-07-22T21:01:06 charon[86343] 16[IKE] <con1|1> sending cert request for "C=DE, ST=<meinLand>, L=<meineStadt>, O=<meineFirma>, E=info@<meineFirma>.de, CN=<meineFirma>-DE-CA"
2021-07-22T21:01:06 charon[86343] 16[IKE] <con1|1> sending cert request for "C=DE, ST=<meinBundesland>, L=<meineStadt>, O=<meineFirma>, E=info@<meineFirma>.de, CN=OpenVPN CA DE"
2021-07-22T21:01:06 charon[86343] 16[IKE] <con1|1> sending cert request for "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3"
2021-07-22T21:01:06 charon[86343] 16[IKE] <con1|1> sending cert request for "CN=Fake LE Intermediate X1"
2021-07-22T21:01:06 charon[86343] 16[IKE] <con1|1> received 2 cert requests for an unknown ca
2021-07-22T21:01:06 charon[86343] 16[IKE] <con1|1> received cert request for "C=US, O=(STAGING) Let's Encrypt, CN=(STAGING) Artificial Apricot R3"
2021-07-22T21:01:06 charon[86343] 16[IKE] <con1|1> received cert request for "C=US, O=Let's Encrypt, CN=R3"
2021-07-22T21:01:06 charon[86343] 16[IKE] <con1|1> received cert request for "CN=Fake LE Intermediate X1"
2021-07-22T21:01:06 charon[86343] 16[IKE] <con1|1> received cert request for "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3"
2021-07-22T21:01:06 charon[86343] 16[CFG] <con1|1> selected proposal: IKE:3DES_CBC/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048_256
2021-07-22T21:01:06 charon[86343] 16[ENC] <con1|1> parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
2021-07-22T21:01:06 charon[86343] 16[NET] <con1|1> received packet: from <meine-Fern-IP>[500] to <meine-Heim-IP>[500] (593 bytes)
2021-07-22T21:01:06 charon[86343] 15[NET] <con1|1> sending packet: from <meine-Heim-IP>[500] to <meine-Fern-IP>[500] (460 bytes)
2021-07-22T21:01:06 charon[86343] 15[ENC] <con1|1> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
2021-07-22T21:01:06 charon[86343] 15[IKE] <con1|1> initiating IKE_SA con1[1] to <meine-Fern-IP>
2021-07-22T21:01:06 charon[86343] 15[CFG] received stroke: initiate 'con1'
2021-07-22T21:01:06 charon[86343] 05[CFG] added configuration 'con1'
2021-07-22T21:01:06 charon[86343] 05[CFG] received stroke: add connection 'con1'
Auf beiden Seiten NAT Traversal auf "Force" stellen, dann geht's :)
Magst Du mir erklären, was das bedeutet?
Es ist ja so, dass es bis auf gestern immer funktioniert hat, nur gestern gab es den Protokolleintrag, dass der "shared key" nicht gefunden wurde, aber nach einem Neustart ging es sofort wieder.
Wieso führt "fehlendes" NAT-Traversal zu diesem Problem? Ich würde es gern verstehen.
Ein Gerät dazwischen kommt mit dem Nat nicht zurecht. Wo es geht Port 4500, beim Fehler 500. Hatte ich schon bei ein paar Kunden mit Lancom.
Das verstehe ich zwar immer noch nicht, aber das passiert nur "ganz selten", nämlich bisher nur ein einziges Mal?
Und was für ein "Gerät dazwischen"? Im entfernten Netz hängt die OPNsense direkt am Netz (Proxy des Providers, der mir eine öffentliche IP liefert), und zu Hause hängt die OPNsense hinter einem Zyxel, das als reines DSL-Modem verwendet wird.
Ich will Deinen Tipp gern befolgen, nur würde ich gern zusätzlich auch ein bisschen dazulernen, damit ich nicht immer gleich bei jeder Kleinigkeit ins Schwimmen komme und nachfragen muss...
Kann es sein dass eine der beiden Seiten nicht mit Port 4500 klarkommt bzw. dies eingehend erlaubt? Dann hat man genau den Fall, dass NAT-T schiefgeht, da es via 4500 also NAT-T scheitert. Aber wenn die Seite bei der eingehend das Problem hat ausgehend 4500 sauber spricht (meistens) und die andere Seite kein Problem hat, klappt es natürlich. Das Problem kommt dann immer, wenn die Seite mit dem Problem nicht Initiator ist, sondern Receiver. Dann läuft der Tunnel in nen Timeout weil die andere Seite als Initiator auf 4500 keine Antwort bekommt. Irgendwann gibts dann Timeout, retry und wenn währenddessen die andere Seite den Tunnel aufbaut klappt es wundersamerweise wieder.
Hatten wir tatäschlich auch schon mal, dass ein Tunnel der bislang immer sehr gut lief, ab und an immer mal wieder ein paar kleine Schluckaufs hatte. Hatte sich keiner was bei gedacht. Irgendwann mussten wir auf der einen Seite zusätzlich OVPN ausrollen und haben uns gewundert warum da kein Paket ankam. Dabei wurde beim ISP bzw. auf dem Router davor gefunden, dass dort nur klassisches IPsec, 22 und Webports auf waren. Aber weder NAT-T (4500) noch OVPN wurden weitergeleitet, sondern ausgefiltert. Daher hat nie IPsec eingehend geklappt (die kleinen Ausfälle immer) aber ausgehend gings natürlich. Fällt selten gleich auf, weil bei IPsec eben beide Seiten bedes sein können - Server und Client.
Cheers
"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).
"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?
Quote from: JeGr on July 24, 2021, 04:56:58 PM
"Natürlich" ist doof, dann muss ichs anders fragen :)
Nee, das "natürlich" bezog sich auf meine mangelnde Detailkenntnis.
Quote from: JeGr on July 24, 2021, 04:56:58 PM
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...
Quote from: JeGr on July 24, 2021, 04:56:58 PM
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.
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...
Schau dir auf YouTube das Video zu VPN von mir und Thomas Krenn an, das hilft bestimmt
Jau, mach ich, danke.
Worauf achte ich dann besonders? Was an meinen Einstellungen ist denn "veraltet"?
Da geht es allgemein wann man OpenVPN und IPsec mach :)
Ok, macht ja aber trotzdem Sinn.
Und dennoch: was gefällt Dir an meinen Einstellungen nicht?
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)
Ja, danke, das passt zu dem, was "JeGr" oben schrieb. Ich werde das testweise mal umstellen.
Danke an Euch alle!
Quote from: mimugmail on July 25, 2021, 10:48:23 AM
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?
Quote from: mimugmail on July 25, 2021, 10:48:23 AM
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
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 (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:
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?).
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
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?
Eigentlich nicht. Müsste ich mal testen. Sind beide Seiten 21.1-latest?
Quote from: JeGr on July 28, 2021, 12:54:14 PM
Sind beide Seiten 21.1-latest?
Beide Seiten sind
OPNsense 21.1.6-amd64
FreeBSD 12.1-RELEASE-p16-HBSD
OpenSSL 1.1.1k 25 Mar 2021
und der Meldung
This is the end of life release for the 21.1 series with 21.7 being released tomorrow.
Also ich habe nur zwei Instanzen von der eine auf 21.1.8 und eine auf 21.1.6.
Trotzdem konnte ich auf die Schnelle einen simplen Tunnel konfigurieren mit
* 256 bit AES-GCM with 128 bit ICV + AESXCBC + DH Group 31 in Phase 1
* aes256gcm16 + AES-XCBC + 31 (Elliptic Curve 25519) in Phase 2
Baute sich problemlos zwischen den beiden Endpunkten auf. Egal von welcher Seite ich angeklopft habe. Kann ich so also nicht ganz nachvollziehen, sieht nach einem Problem in der Konfiguration oder von WAN/IP/ID aus.
Hmm, dann probiere ich das nochmal in Ruhe und melde mich dann wieder. Danke bis hier!