Zurück zu den Updates
New releaseSep 8, 2026

strongswan v6.1.0

strongSwan - IPsec-basiertes VPN

Teilen

strongSwan-Konfiguration

Übersicht

strongSwan ist eine Open-Source-IPsec-basierte VPN-Lösung.

Dieses Dokument ist nur eine kurze Einführung in den swanctl-Befehl von strongSwan, der die moderne vici Versatile IKE Configuration Interface verwendet. Der veraltete ipsec-Befehl mit der älteren stroke-Konfigurationsschnittstelle wird hier beschrieben. Für detailliertere Informationen konsultieren Sie die Manpages, unsere neue Dokumentationsseite und das alte Wiki.

Schnellstart

Zertifikate für Benutzer, Hosts und Gateways werden von einer fiktiven strongSwan-CA ausgestellt. In unseren Beispielszenarien muss das CA-Zertifikat strongswanCert.pem auf allen VPN-Endpunkten vorhanden sein, um die Peers authentifizieren zu können. Für Ihre spezielle VPN-Anwendung können Sie entweder Zertifikate einer beliebigen Drittanbieter-CA verwenden oder die benötigten privaten Schlüssel und Zertifikate selbst mit dem strongSwan-pki-Werkzeug erzeugen, dessen Verwendung in einem der folgenden Abschnitte erläutert wird.

Site-to-Site-Szenario

In diesem Szenario verbinden zwei Sicherheits-Gateways moon und sun die beiden Subnetze moon-net und sun-net über einen zwischen den beiden Gateways aufgebauten VPN-Tunnel miteinander:

10.1.0.0/16 -- | 192.168.0.1 | === | 192.168.0.2 | -- 10.2.0.0/16
  moon-net          moon                 sun           sun-net

Konfiguration auf Gateway moon:

/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/x509/moonCert.pem
/etc/swanctl/private/moonKey.pem

/etc/swanctl/swanctl.conf:

    connections {
        net-net {
            remote_addrs = 192.168.0.2

            local {
                auth = pubkey
                certs = moonCert.pem
            }
            remote {
                auth = pubkey
                id = "C=CH, O=strongSwan, CN=sun.strongswan.org"
            }
            children {
                net-net {
                    local_ts  = 10.1.0.0/16
                    remote_ts = 10.2.0.0/16
                    start_action = trap
                }
            }
        }
    }

Konfiguration auf Gateway sun:

/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/x509/sunCert.pem
/etc/swanctl/private/sunKey.pem

/etc/swanctl/swanctl.conf:

    connections {
        net-net {
            remote_addrs = 192.168.0.1

            local {
                auth = pubkey
                certs = sunCert.pem
            }
            remote {
                auth = pubkey
                id = "C=CH, O=strongSwan, CN=moon.strongswan.org"
            }
            children {
                net-net {
                    local_ts  = 10.2.0.0/16
                    remote_ts = 10.1.0.0/16
                    start_action = trap
                }
            }
        }
    }

Die in diesem Szenario verwendeten lokalen und entfernten Identitäten sind die subjectDistinguishedNames, die in den Endentitätszertifikaten enthalten sind. Die Zertifikate und privaten Schlüssel werden mit dem Befehl

swanctl --load-creds

in den charon-Daemon geladen, während

swanctl --load-conns

die in swanctl.conf definierten Verbindungen lädt. Mit start_action = trap wird die IPsec-Verbindung automatisch mit dem ersten unverschlüsselten IP-Paket aufgebaut, das durch den Tunnel geleitet werden soll.

Host-zu-Host-Szenario

Dies ist ein Aufbau zwischen zwei einzelnen Hosts, hinter denen sich kein Subnetz befindet. Obwohl der IPsec-Transportmodus für Host-zu-Host-Verbindungen ausreichen würde, verwenden wir den standardmäßigen IPsec-Tunnelmodus.

| 192.168.0.1 | === | 192.168.0.2 |
     moon                sun

Konfiguration auf Host moon:

/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/x509/moonCert.pem
/etc/swanctl/private/moonKey.pem

/etc/swanctl/swanctl.conf:

    connections {
        host-host {
            remote_addrs = 192.168.0.2

            local {
                auth=pubkey
                certs = moonCert.pem
            }
            remote {
                auth = pubkey
                id = "C=CH, O=strongSwan, CN=sun.strongswan.org"
            }
            children {
                net-net {
                    start_action = trap
                }
            }
        }
    }

Konfiguration auf Host sun:

/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/x509/sunCert.pem
/etc/swanctl/private/sunKey.pem

/etc/swanctl/swanctl.conf:

    connections {
        host-host {
            remote_addrs = 192.168.0.1

            local {
                auth = pubkey
                certs = sunCert.pem
            }
            remote {
                auth = pubkey
                id = "C=CH, O=strongSwan, CN=moon.strongswan.org"
            }
            children {
                host-host {
                    start_action = trap
                }
            }
        }
    }

Roadwarrior-Szenario

Dies ist ein sehr häufiger Fall, bei dem ein strongSwan-Gateway einer beliebigen Anzahl von Remote-VPN-Clients dient, die normalerweise dynamische IP-Adressen haben.

10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x |
  moon-net          moon              carol

Konfiguration auf Gateway moon:

/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/x509/moonCert.pem
/etc/swanctl/private/moonKey.pem

/etc/swanctl/swanctl.conf:

    connections {
        rw {
            local {
                auth = pubkey
                certs = moonCert.pem
                id = moon.strongswan.org
            }
            remote {
                auth = pubkey
            }
            children {
                net-net {
                    local_ts  = 10.1.0.0/16
                }
            }
        }
    }

Konfiguration auf Roadwarrior carol:

/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/x509/carolCert.pem
/etc/swanctl/private/carolKey.pem

/etc/swanctl/swanctl.conf:

    connections {
        home {
            remote_addrs = moon.strongswan.org

            local {
                auth = pubkey
                certs = carolCert.pem
                id = [email protected]
            }
            remote {
                auth = pubkey
                id = moon.strongswan.org
            }
            children {
                home {
                    local_ts  = 10.1.0.0/16
                    start_action = start
                }
            }
        }
    }

Für remote_addrs wurde der Hostname moon.strongswan.org gewählt, der zur Laufzeit von DNS in die entsprechende IP-Zieladresse aufgelöst wird. In diesem Szenario ist die Identität des Roadwarriors carol die E-Mail-Adresse [email protected], die als subjectAlternativeName in das Roadwarrior-Zertifikat carolCert.pem aufgenommen werden muss.

Roadwarrior-Szenario mit virtueller IP

Roadwarrior haben normalerweise dynamische IP-Adressen, die vom jeweiligen ISP zugewiesen werden. Um das Routing von moon-net zurück zum Remote-Access-Client carol zu vereinfachen, wäre es wünschenswert, wenn der Roadwarrior eine innere IP-Adresse aus einem vordefinierten Pool hätte.

10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x | -- 10.3.0.1
  moon-net          moon              carol       virtuelle IP

In unserem Beispiel wird die virtuelle IP-Adresse aus dem Adresspool 10.3.0.0/16 gewählt, der durch Hinzufügen des Abschnitts

pools {
    rw_pool {
        addrs = 10.3.0.0/16
    }
}

zur swanctl.conf des Gateways konfiguriert werden kann, von wo sie mit dem Befehl

swanctl --load-pools

in den charon-Daemon geladen werden.

Um eine IP-Adresse aus diesem Pool anzufordern, kann ein Roadwarrior die IKEv1-Mode-Config oder IKEv2-Konfigurations-Payloads verwenden. Die Konfiguration ist für beide gleich:

vips = 0.0.0.0

Konfiguration auf Gateway moon:

/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/x509/moonCert.pem
/etc/swanctl/private/moonKey.pem

/etc/swanctl/swanctl.conf:

    connections {
        rw {
            pools = rw_pool

            local {
                auth = pubkey
                certs = moonCert.pem
                id = moon.strongswan.org
            }
            remote {
                auth = pubkey
            }
            children {
                net-net {
                    local_ts  = 10.1.0.0/16
                }
            }
        }
    }

    pools {
        rw_pool {
            addrs = 10.30.0.0/16
        }
    }

Konfiguration auf Roadwarrior carol:

/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/x509/carolCert.pem
/etc/swanctl/private/carolKey.pem

/etc/swanctl/swanctl.conf:

    connections {
        home {
            remote_addrs = moon.strongswan.org
            vips = 0.0.0.0

            local {
                auth = pubkey
                certs = carolCert.pem
                id = [email protected]
            }
            remote {
                auth = pubkey
                id = moon.strongswan.org
            }
            children {
                home {
                    local_ts  = 10.1.0.0/16
                    start_action = start
                }
            }
        }
    }

Roadwarrior-Szenario mit EAP-Authentifizierung

Dies ist ein sehr häufiger Fall, bei dem ein strongSwan-Gateway einer beliebigen Anzahl von Remote-VPN-Clients dient, die sich über ein passwortbasiertes Extended Authentication Protocol wie z. B. EAP-MD5 oder EAP-MSCHAPv2 authentifizieren.

10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x |
  moon-net          moon              carol

Konfiguration auf Gateway moon:

/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/x509/moonCert.pem
/etc/swanctl/private/moonKey.pem

/etc/swanctl/swanctl.conf:

    connections {
        rw {
            local {
                auth = pubkey
                certs = moonCert.pem
                id = moon.strongswan.org
            }
            remote {
                auth = eap-md5
            }
            children {
                net-net {
                    local_ts  = 10.1.0.0/16
                }
            }
            send_certreq = no
        }
    }

Die Datei swanctl.conf enthält zusätzlich einen secrets-Abschnitt, der alle Client-Anmeldedaten definiert:

    secrets {
        eap-carol {
            id = [email protected]
            secret = Ar3etTnp
        }
        eap-dave {
            id = [email protected]
            secret = W7R0g3do
        }
    }

Konfiguration auf Roadwarrior carol:

/etc/swanctl/x509ca/strongswanCert.pem

/etc/swanctl/swanctl.conf:

    connections {
        home {
            remote_addrs = moon.strongswan.org

            local {
                auth = eap
                id = [email protected]
            }
            remote {
                auth = pubkey
                id = moon.strongswan.org
            }
            children {
                home {
                    local_ts  = 10.1.0.0/16
                    start_action = start
                }
            }
        }
    }

    secrets {
        eap-carol {
            id = [email protected]
            secret = Ar3etTnp
        }
    }

Roadwarrior-Szenario mit EAP-Identität

Oft wird eine Client-EAP-Identität über EAP ausgetauscht, die sich von der externen IKEv2-Identität unterscheidet. In diesem Beispiel wird die IKEv2-Identität standardmäßig auf die IPv4-Adresse des Clients gesetzt.

10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x |
  moon-net          moon              carol

Konfiguration auf Gateway moon:

/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/x509/moonCert.pem
/etc/swanctl/private/moonKey.pem

/etc/swanctl/swanctl.conf:

    connections {
        rw {
            local {
                auth = pubkey
                certs = moonCert.pem
                id = moon.strongswan.org
            }
            remote {
                auth = eap-md5
                eap_id = %any
            }
            children {
                net-net {
                    local_ts  = 10.1.0.0/16
                }
            }
            send_certreq = no
        }
    }

    secrets {
        eap-carol {
            id = carol
            secret = Ar3etTnp
        }
        eap-dave {
            id = dave
            secret = W7R0g3do
        }
    }

Konfiguration auf Roadwarrior carol:

/etc/swanctl/x509ca/strongswanCert.pem

/etc/swanctl/swanctl.conf:

    connections {
        home {
            remote_addrs = moon.strongswan.org

            local {
                auth = eap
                eap_id = carol
            }
            remote {
                auth = pubkey
                id = moon.strongswan.org
            }
            children {
                home {
                    local_ts  = 10.1.0.0/16
                    start_action = start
                }
            }
        }
    }

    secrets {
        eap-carol {
            id = carol
            secret = Ar3etTnp
        }
    }

Generieren von Zertifikaten und CRLs

Dieser Abschnitt ist kein ausführliches Tutorial zur Verwendung des strongSwan-pki-Werkzeugs. Er listet nur einige Punkte auf, die relevant sind, wenn Sie eigene Zertifikate und CRLs für die Verwendung mit strongSwan erzeugen möchten.

Generieren eines CA-Zertifikats

Die pki-Anweisung

pki --gen --type ed25519 --outform pem > strongswanKey.pem

erzeugt einen elliptischen Edwards-Curve-Schlüssel mit einer kryptografischen Stärke von 128 Bit. Der zugehörige öffentliche Schlüssel wird in ein selbstsigniertes CA-Zertifikat mit einer Lebensdauer von 10 Jahren (3652 Tagen) verpackt:

pki --self --ca --lifetime 3652 --in strongswanKey.pem \
           --dn "C=CH, O=strongSwan, CN=strongSwan Root CA" \
           --outform pem > strongswanCert.pem

Dieses kann mit dem Befehl

pki --print --in strongswanCert.pem

subject:  "C=CH, O=strongSwan, CN=strongSwan Root CA"
issuer:   "C=CH, O=strongSwan, CN=strongSwan Root CA"
validity:  not before May 18 08:32:06 2017, ok
           not after  May 18 08:32:06 2027, ok (expires in 3651 days)
serial:    57:e0:6b:3a:9a:eb:c6:e0
flags:     CA CRLSign self-signed
subjkeyId: 2b:95:14:5b:c3:22:87:de:d1:42:91:88:63:b3:d5:c1:92:7a:0f:5d
pubkey:    ED25519 256 bits
keyid:     a7:e1:6a:3f:e7:6f:08:9d:89:ec:23:92:a9:a1:14:3c:78:a8:7a:f7
subjkey:   2b:95:14:5b:c3:22:87:de:d1:42:91:88:63:b3:d5:c1:92:7a:0f:5d

Wenn Sie den CA-privaten Schlüssel und das X.509-Zertifikat im binären DER-Format bevorzugen, lassen Sie einfach die Option --outform pem weg. Das Verzeichnis /etc/swanctl/x509ca enthält alle erforderlichen CA-Zertifikate entweder im binären DER- oder im Base64-PEM-Format. Unabhängig von der Dateiendung wird das korrekte Format von strongSwan automatisch ermittelt.

Generieren eines Host- oder Benutzer-Endentitätszertifikats

Auch hier verwenden wir den Befehl

pki --gen --type ed25519 --outform pem > moonKey.pem

um einen privaten Ed25519-Schlüssel für den Host moon zu erzeugen. Alternativ können Sie

pki --gen --type rsa --size 3072 > moonKey.der

eingeben, um einen traditionellen 3072-Bit-RSA-Schlüssel zu erzeugen und im binären DER-Format zu speichern. Als Alternative kann ein TPM 2.0 Trusted Platform Module, das auf jeder aktuellen Intel-Plattform verfügbar ist, als virtuelle Smartcard verwendet werden, um einen RSA- oder ECDSA-privaten Schlüssel sicher zu speichern. Details finden Sie im TPM-2.0- HOWTO.

Im nächsten Schritt erzeugt der Befehl

pki --req --type priv --in moonKey.pem \
          --dn "C=CH, O=strongswan, CN=moon.strongswan.org" \
          --san moon.strongswan.org --outform pem > moonReq.pem

eine PKCS#10-Zertifikatsanforderung, die von der CA signiert werden muss. Durch die [mehrfache] Verwendung des Parameters --san kann eine beliebige Anzahl gewünschter subjectAlternativeNames zur Anforderung hinzugefügt werden. Diese können die folgende Form haben:

--san sun.strongswan.org     # voll qualifizierter Hostname
--san [email protected]   # RFC822-Benutzer-E-Mail-Adresse
--san 192.168.0.1            # IPv4-Adresse
--san fec0::1                # IPv6-Adresse

Basierend auf der Zertifikatsanforderung stellt die CA mit dem folgenden Befehl ein signiertes Endentitätszertifikat aus:

pki --issue --cacert strongswanCert.pem --cakey strongswanKey.pem \
            --type pkcs10 --in moonReq.pem --serial 01 --lifetime 1826 \
            --outform pem > moonCert.pem

Wenn der Parameter --serial mit einem hexadezimalen Argument weggelassen wird, wird eine zufällige Seriennummer erzeugt. Einige Drittanbieter-VPN-Clients verlangen, dass ein VPN-Gateway-Zertifikat das Flag TLS Server Authentication Extended Key Usage (EKU) enthält, das mit der folgenden Option aufgenommen werden kann:

--flag serverAuth

Wenn Sie die in einem der folgenden Abschnitte beschriebene Funktion zum dynamischen Abrufen von CRLs verwenden möchten, können Sie mit dem Parameter --crl einen oder mehrere crlDistributionPoints in Ihre Endentitätszertifikate aufnehmen:

--crl  http://crl.strongswan.org/strongswan.crl
--crl "ldap://ldap.strongswan.org/cn=strongSwan Root CA, o=strongSwan,c=CH?certificateRevocationList"

Das ausgestellte Host-Zertifikat kann mit folgendem Befehl aufgelistet werden:

pki --print --in moonCert.pem

subject:  "C=CH, O=strongSwan, CN=moon.strongswan.org"
issuer:   "C=CH, O=strongSwan, CN=strongSwan Root CA"
validity:  not before May 19 10:28:19 2017, ok
           not after  May 19 10:28:19 2022, ok (expires in 1825 days)
serial:    01
altNames:  moon.strongswan.org
flags:     serverAuth
CRL URIs:  http://crl.strongswan.org/strongswan.crl
authkeyId: 2b:95:14:5b:c3:22:87:de:d1:42:91:88:63:b3:d5:c1:92:7a:0f:5d
subjkeyId: 60:9d:de:30:a6:ca:b9:8e:87:bb:33:23:61:19:18:b8:c4:7e:23:8f
pubkey:    ED25519 256 bits
keyid:     39:1b:b3:c2:34:72:1a:01:08:40:ce:97:75:b8:be:ce:24:30:26:29
subjkey:   60:9d:de:30:a6:ca:b9:8e:87:bb:33:23:61:19:18:b8:c4:7e:23:8f

Normalerweise benötigt ein VPN-Client auf Windows-, OSX-, Android- oder iOS-Basis seinen privaten Schlüssel, sein Host- oder Benutzerzertifikat und das CA-Zertifikat. Der bequemste Weg, diese Informationen zu laden, besteht darin, alles in einen PKCS#12-Container zu packen:

openssl pkcs12 -export -inkey carolKey.pem \
               -in carolCert.pem -name "carol" \
               -certfile strongswanCert.pem -caname "strongSwan Root CA" \
               -out carolCert.p12

Das strongSwan-pki-Werkzeug kann derzeit keine PKCS#12-Container erstellen, daher muss openssl verwendet werden.

Generieren einer CRL

Eine leere, von der CA signierte CRL kann mit dem Befehl

pki --signcrl --cacert strongswanCert.pem --cakey strongswanKey.pem \
              --lifetime 30 > strongswan.crl

erzeugt werden. Wenn Sie die Option --lifetime weglassen, wird der Standardwert von 15 Tagen verwendet. CRLs können entweder auf einen HTTP- oder LDAP-Server hochgeladen oder im binären DER- oder Base64-PEM-Format in das Verzeichnis /etc/swanctl/x509crl gelegt werden, von wo sie mit dem Befehl

swanctl --load-creds

in den charon-Daemon geladen werden.### Widerruf eines Zertifikats ###

Ein bestimmtes End-Entity-Zertifikat wird mit folgendem Befehl widerrufen:

pki --signcrl --cacert strongswanCert.pem --cakey strongswanKey.pem \
              --lifetime 30 --lastcrl strongswan.crl \
              --reason key-compromise --cert moonCert.pem > new.crl

Anstelle der Zertifikatsdatei (in unserem Beispiel moonCert.pem) kann die Seriennummer des zu widerrufenden Zertifikats über den Parameter --serial angegeben werden. Der Befehl pki --signcrl --help dokumentiert alle möglichen Widerrufsgründe, der Parameter --reason kann jedoch auch weggelassen werden. Der Inhalt der neuen CRL-Datei kann mit dem folgenden Befehl aufgelistet werden:

pki --print --type crl --in new.crl

issuer:   "C=CH, O=strongSwan, CN=strongSwan Root CA"
update:    this on May 19 11:13:01 2017, ok
           next on Jun 18 11:13:01 2017, ok (expires in 29 days)
serial:    02
authKeyId: 2b:95:14:5b:c3:22:87:de:d1:42:91:88:63:b3:d5:c1:92:7a:0f:5d
1 revoked certificate:
  01: May 19 11:13:01 2017, key compromise

Lokales Zwischenspeichern von CRLs

Die Option strongswan.conf

charon {
    cache_crls = yes
}

aktiviert das lokale Zwischenspeichern von CRLs, die dynamisch von einem HTTP- oder LDAP-Server abgerufen wurden. Zwischengespeicherte Kopien werden unter /etc/swanctl/x509crl mit einem eindeutigen Dateinamen gespeichert, der aus dem subjectKeyIdentifier des Ausstellers und der Endung .crl gebildet wird.

Mit der zwischengespeicherten Kopie ist die CRL unmittelbar nach dem Start verfügbar. Wenn die lokale Kopie veraltet ist, wird bei der nächsten IKEv2-Authentifizierung automatisch eine aktualisierte CRL von einem der definierten CRL-Verteilungspunkte abgerufen.

Kategorien