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

Started by Emma2, July 22, 2021, 09:51:16 AM

Previous topic - Next topic
... 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 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...
kind regards
chemlud
____
"The price of reliability is the pursuit of the utmost simplicity."
C.A.R. Hoare

felix eichhorns premium katzenfutter mit der extraportion energie

A router is not a switch - A router is not a switch - A router is not a switch - A rou....

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

July 23, 2021, 02:55:29 PM #9 Last Edit: July 23, 2021, 04:23:27 PM by Emma2
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
"It doesn't work!" is no valid error description! - Don't forget to [applaud] those offering time & brainpower to help you!
Better have some *sense as no(n)sense! ;)

If you're interested in german-speaking business support, feel free to reach out via PM.