Wer kennt sich mit StrongSwan (ipsec) aus?

  • Ich bin gerade dabei, meinen Web-Server auf eine neue Hardware mit virtuellen Maschinen umzuziehen und bin dabei auf das Problem gestoßen, daß anscheinend StrongSwan nicht mehr so ohne weiteres funktioniert. Ich benutze das bisher auf meinem alten Server, um ein VPN zwischen dem Server und meinem Router zuhause aufzubauen, was auch all die Jahre wunderbar funktioniert hat. Aber einfach die bestehenden Konfigurationsdateien rüberkopieren und anzupassen (Rechnername, IP-Nummer) scheint nicht zu reichen, denn beim Start liefert StrongSwan jede Menge Fehlermeldungen im Log:


    So geht das dann im Abstand von einigen Sekunden immer wieder von vorne los.
    Bevor ich jetzt anfange, die Fehlermeldungen im einzelnen zu verstehen zu versuchen (wobei ich den Verdacht habe, daß einiges davon einfach nur daher kommt, daß bestimmte Sachen, die ich eh nicht brauche, nicht vorhanden sind), wollte ich mal fragen ob hier jemand Erfahrung mit dem Umstieg von StrongSwan Version 4.5.3 auf 5.1.3 hat (das sind die Versionen auf dem alten und neuen Server). Eventuell muß man ja nur Kleinigkeiten anpassen. Eine wirklich brauchbare Umstiegsanleitung habe ich im Web leider nicht gefunden.


    Die ipsec-Konfiguration sieht so aus:


    Den Parameter "leftnexthop" habe ich schon auskommentiert, da der inzwischen obsolete sein soll.


    Wäre für jeden Hinweis dankbar.


    Klaus

  • Inzwischen bin ich einen kleinen Schritt weiter gekommen. Die Meldung


    Apr 5 14:39:19 racoon2 charon: 00[LIB] opening '/etc/ipsec.d/private/{' failed: No such file or directory


    kommt wohl daher, daß sich das Format der Datei ipsec.secrets geändert hat. Bisher konnte da sowas drinstehen:

    Code
    1. @racoon2.tvdr.de: RSA {
    2. Modulus: 0x69f81f353a2e5a465aaefac...
    3. PublicExponent: 0x03
    4. PrivateExponent: 0x11a95a88df07b9b66...
    5. Prime1: 0xd069b9ff95931689bf46d8bf94...
    6. Prime2: 0x822a4b6e7c84cb397d243d43...
    7. Exponent1: 0x8af126aa63b7645bd4d9e...
    8. Exponent2: 0x56c6dcf453033226536d7...
    9. Coefficient: 0x651d36c4acc094875372...
    10. }


    aber jetzt scheint nur noch

    Code
    1. @racoon2.tvdr.de : RSA racoon2.pem


    gültig zu sein. Die Klammer '{' wurde also als Dateiname interpretiert, und eine solche Datei gab es nicht.


    Ich habe also jetzt ipsec.secrets entsprechend geändert und die Schlüssel-Daten nach /etc/ipsec.d/private/racoon2.pem verlagert. Das bringt mir aber nun die Meldung

    Code
    1. Apr 5 17:10:28 racoon2 charon: 00[CFG] loading secrets from '/etc/ipsec.secrets'
    2. Apr 5 17:10:28 racoon2 charon: 00[LIB] file coded in unknown format, discarded
    3. Apr 5 17:10:28 racoon2 charon: 00[LIB] building CRED_PRIVATE_KEY - RSA failed, tried 11 builders
    4. Apr 5 17:10:28 racoon2 charon: 00[CFG] loading private key from '/etc/ipsec.d/private/racoon2.pem' failed


    wobei sich das "file coded in unknown format, discarded" wohl auf die /etc/ipsec.d/private/racoon2.pem bezieht, und nicht, wie man auf den ersten Blick vermuten möchte, auf /etc/ipsec.secrets, denn wenn ich die racoon2.pem lösche, erhalte ich

    Code
    1. Apr 5 17:18:10 racoon2 charon: 00[CFG] loading secrets from '/etc/ipsec.secrets'
    2. Apr 5 17:18:10 racoon2 charon: 00[LIB] opening '/etc/ipsec.d/private/racoon2.pem' failed: No such file or directory
    3. Apr 5 17:18:10 racoon2 charon: 00[LIB] building CRED_PRIVATE_KEY - RSA failed, tried 11 builders
    4. Apr 5 17:18:10 racoon2 charon: 00[CFG] loading private key from '/etc/ipsec.d/private/racoon2.pem' failed


    Jetzt ist also die Frage, wie die Datei aussehen muß. Der Inhalt

    Code
    1. Modulus: 0x69f81f353a2e5a465aaefac...
    2. PublicExponent: 0x03
    3. PrivateExponent: 0x11a95a88df07b9b66...
    4. Prime1: 0xd069b9ff95931689bf46d8bf94...
    5. Prime2: 0x822a4b6e7c84cb397d243d43...
    6. Exponent1: 0x8af126aa63b7645bd4d9e...
    7. Exponent2: 0x56c6dcf453033226536d7...
    8. Coefficient: 0x651d36c4acc094875372...


    wird ja als "unknown format" abgelehnt.
    Leider weiß ich auch nicht, wie man überhaupt so einen Key neu erstellen sollte, denn das bisherige


    ipsec rsasigkey


    gibt es wohl nicht mehr ("/usr/sbin/ipsec: unknown IPsec command `rsasigkey'").


    Klaus

  • Leider weiß ich auch nicht, wie man überhaupt so einen Key neu erstellen sollte, denn das bisherige


    ipsec rsasigkey


    gibt es wohl nicht mehr ("/usr/sbin/ipsec: unknown IPsec command `rsasigkey'").

    Das müsste z.B. mit openssl möglich sein: https://www.strongswan.org/docs/readme4.htm#section_3

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Das ist irgendwie alles nicht das, was ich suche. Ich will keine Zertifizierung, sondern einfach nur einen RSA-Key für eine VPN-Verbindung, so wie das in Version 4.5.3 wunderbar einfach funktioniert hat. Aber anscheinend hat da mal wieder jemand sich selbst verwirklicht und alles mögliche "verschlimmbessert"... :-(


    Ich habe jetzt in /etc/ipsec.secrets sowas eingetragen:


    @racoon2.tvdr.de : PSK "xxxxxxxxx"


    Das sollte ja auch gehen. Ist zwar wohl nicht so sicher wie RSA, aber das ist mir momentan auch egal.
    Das Log enthält damit


    Das Secret wird also geladen, aber irgend etwas geht immer noch schief...


    Klaus

  • Versuch mal als PSK nur Zahlen und Buchstaben (Groß- und Kleinschreibung) zu verwenden, aber keine Sonderzeichen. Ich meine mich schwach zu entsinnen, dass IPSec damit Probleme hat.


    iNOB

  • So, für alle, die es interessiert: die Fehlermeldungen der Art


    binding socket 'unix:///run/strongswan/charon.dck' failed: No such file or directory


    waren entscheidend. Ein Blick in /var/run ergab, daß es kein Subdirectory namens 'strongswan' gab. Nachdem ich das angelegt hatte startete "charon" zumindest mal, ohne nach ein paar Sekunden gleich wieder gekillt zu werden.


    Warum /var/run/strongswan nicht automatisch angelegt wurde, ist mir ein Rätsel.


    Dann kann ich jetzt endlich mit der eigentlichen Konfiguration weitermachen...


    Klaus

  • Die beiden Rechner "sprechen" jetzt zumindest schonmal miteinander. Aber anscheinend können sie sich noch nicht auf ein Verschlüsselungsverfahren einigen. Im Log erhalte ich jetzt


    Code
    1. Apr 6 15:40:45 racoon2 ipsec[5003]: 08[CFG] received proposals: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_MD5_96/MODP_2048/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_MD5_96/MODP_2048/NO_EXT_SEQ
    2. Apr 6 15:40:45 racoon2 ipsec[5003]: 08[CFG] configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/BLOWFISH_CBC_256/HMAC_SHA1_96/AES_XCBC_96/HMAC_MD5_96/NO_EXT_SEQ
    3. Apr 6 15:40:45 racoon2 ipsec[5003]: 08[IKE] received 28800s lifetime, configured 3600s
    4. Apr 6 15:40:45 racoon2 ipsec[5003]: 08[IKE] no matching proposal found, sending NO_PROPOSAL_CHOSEN


    Weiß jemand, wo man die "proposals" konfigurieren kann? Irgendwie finde ich da nichts...


    Klaus

  • Auf meiner IPFire lege ich die proposals in der ipsec.conf bzw. ipsec.user.conf in der conn für den User fest, z.B.:

    Code
    1. conn foo
    2. ...
    3. ike=aes256-sha2_512-modp4096,aes256-sha2_384-modp4096,aes256-sha2_256-modp4096
    4. esp=aes256-sha2_512-modp4096,aes256-sha2_384-modp4096,aes256-sha2_256-modp4096
    5. ...


    Allerdings benutze ich Zertifikate und keinen PSK.


    iNOB

  • Ich schätze mal ob Zertifikate oder PSK macht da keinen Unterschied. Die Hürde ist, glaube ich, schon genommen.
    Ich habe mal deine Zeilen verwendet, aber anscheinend haben da die verschiedenen Versionen schon wieder unterschiedliche Syntax, denn hier muß es wohl


    aes256-sha2_512;modp4096


    heißen statt


    aes256-sha2_512-modp4096


    (also ein ';' statt '-' zwischen "512" und "mod").


    Aber auch damit klappt es nicht.
    Auf http://linux.die.net/man/5/ipsec.conf habe ich jetzt noch folgendes gefunden:


    sha2_truncbug
    The default hash truncation for sha2_256 is 128 bits. Linux implemented the draft version which stated 96 bits. This option enables using the bad 96 bits version to interop with older linux kernels (unpatched version 2.6.33 and older) and openswan versions before 2.6.38. Currently the accepted values are no, (the default) signifying default IETF truncation of 128 bits, or yes, signifying 96 bits broken Linux kernel style truncation.


    Mein Router verwendet openWRT mit Kernel 2.6.32.27, würde also wohl darunter fallen. Leider kennt aber StrongSwan auf meinem Server (Kernel 3.16.7-7) diese Option nicht.


    Es ist zum Verzweifeln...


    Klaus