IPsec sous debian avec strongswan

aptitude install strongswan strongswan-swanctl

Placer la CA dans /etc/ipsec.d/cacerts puis :

cd /etc/ipsec.d/cacerts/
ln -s myca.pem `openssl x509 -hash -noout -in myca.pem`.0

Placer le certificat dans /etc/ipsec.d/certs/
Placer la clé privée dans /etc/ipsec.d/private/

Il faut définir la clé privé dans /etc/ipsec.secrets sous le format ID : TYPE KEY. L'ID peut être vide, contenir une ip, un FQDN, user@FQSN, %any ou any6. TYPE est PSK ou RSA. KEY peut être soit une clé, soit un chemin vers une clé.

: RSA /etc/ipsec.d/private/mykey.key

VTI auth RSA

/etc/strongswan.d/charon.conf -> install_routes = no

ipsec.conf

De manière générale :

• left* correspond à la machine locale
• right* correspond à la machine distante

Les champs suivant sont à modifier :

• left = l'ip de la machine locale (peut être une ip rfc1918)
• right = l'ip de la machine distante (obligatoirement une ip accessible sur le réseau, donc pas d'ip rfc1918)
• leftid une manière d'identifier la machine locale (IP, FQDN, etc). En cas d'authentification RSA, cet identifiant devra exister soit au champ CN soit au champ SubjectAltName du certificat local.
• rightid une manière d'identifier la machine distante (IP, FQDN, etc). En cas d'authentification RSA, cet identifiant devra exister soit au champ CN soit au champ SubjectAltName du certificat distant.
• leftcert contient le chemin vers le certificat ssl local. La clé privé est définie dans /etc/ipsec.secret
• rightca contient une manière d'identifier la CA ayant généré le certificat distant.
• leftsubnet est défini à l'ip locale servant de transport VTI. Vous avez besoin d'un minimum de deux ip pour définir un transport VTI, le choix de /30 est donc à privilégier.
• rightsubnet est défini à l'ip distante servant de transport VTI.

conn ipsec1
        reqid = 1
        fragmentation = yes
        keyexchange = ikev2
        reauth = yes
        forceencaps = no
        mobike = no
        rekey = yes
        installpolicy = yes
        auto = start
        dpdaction = restart
        dpddelay = 10s
        dpdtimeout = 60s
        left = 211.124.34.153
        right = 92.119.29.26
        leftid = fqdn:nodeA.domain.tld
        rightid = fqdn:nodeB.domain.tld
        ikelifetime = 28800s
        lifetime = 3600s
        ike = aes128gcm128-sha512-modp4096!
        esp = aes128gcm128-sha256-modp2048!
        leftauth = pubkey
        rightauth = pubkey
        leftcert="/etc/ipsec.d/certs/mycert.crt"
        leftsendcert=always
        rightca="/CN=My Ca/ST=My Location/L=My City/O=My Company/OU=My Company Unit/"
        leftsubnet = 10.66.10.2/30
        rightsubnet = 10.66.10.1
        mark = 42
        leftupdown = /etc/ipsec.updown

Lancement

ipsec start

ipsec status
ipsec statusall

création de l'interface

LOCAL_IP=211.124.34.153
REMOTE_IP=92.119.29.26
LOCAL_TUNNEL=10.66.10.2
REMOTE_TUNNEL=10.66.10.1

ip tunnel add ipsec0 local $LOCAL_IP remote $REMOTE_IP mode vti okey 42 ikey 42
ip link set ipsec0 up
ip addr add ${LOCAL_TUNNEL}/30 remote ${REMOTE_TUNNEL}/30 dev ipsec0

A ce stade, seul le tunnel sera joignable (10.66.10.1 et 10.66.10.2) car ipsec a installé une policy restrictive (ip xfrm policy).
Si d'autres ranges doivent être joignable de part et d'autres du VPN (ce qui est probable sinon vous n'utiliseriez pas VTI) :

• Passez installpolicy à no dans /etc/ipsec.conf
• Installez votre propre policy ouverte :

ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 dir fwd priority 368255 ptype main mark 0x2a tmpl src $REMOTE_IP dst $LOCAL_IP proto esp reqid 1 mode tunnel
ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 dir in priority 368255 ptype main mark 0x2a tmpl src $REMOTE_IP dst $LOCAL_IP proto esp reqid 1 mode tunnel
ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 dir out priority 368255 ptype main mark 0x2a tmpl src $LOCAL_IP dst $REMOTE_IP proto esp reqid 1 mode tunnel

Avec cette configuration, il vous suffira de router votre range, par exemple 192.168.1.0/24, vers l'ip distante du tunnel.

ip r a 192.168.1.0/24 via $REMOTE_TUNNEL dev ipsec0

Note : il est aussi possible d'installer une policy (enfin, 3) restrictive, pour chaque range. Cela complexifie néanmoins grandement la configuration et supprime les bénéfices d'un tunnel VTI.

Note : sur une infrastructure, j'avais également du définir sysctl -wq net.ipv4.conf.ipsec0.disable_policy=1 afin de permettre au trafic de passer.