OpenBSD est fourni avec iked(8), un serveur IKEv2 moderne, avec séparation des privilèges. Il peut agir à la fois comme répondeur, p. ex. un serveur recevant des requêtes de connexion, ou initiateur, p. ex. un client demandant une connexion à un répondeur. L'utilitaire ikectl(8) est utilisé pour contrôler le serveur, qui a sa configuration dans le fichier iked.conf(8).

L'utilitaire ikectl(8) permet aussi de maintenir un simple certificat d'autorité X.509 (CA) pour les pairs IKEv2.

Un serveur IKEv1 (isakmpd(8)) est aussi disponible, et couplé avec npppd(8), permet de construire un VPN IKEv1/L2TP là où IKEv2 ne peut être déployé.

La prise en charge native de WireGuard est aussi disponible via le périphérique wg(4). Ainsi que l'explique la page de manuel, il peut être configuré de la même manière que pour toutes les autres interfaces réseaux dans OpenBSD.

iked(8) prend en charge les méthodes d'authentification suivantes :

• les clés pré-partagées (non recommandé)
• les clés publiques RSA & ECDSA : facile à paramétrer lors de connexion à iked, RouterOS et certaines autres implémentations
• EAP MSCHAPv2 (avec un certificat X.509 côté serveur) : iked supporte cela seulement sur le “répondeur” (le serveur).
• les certificats X.509 : souvent requis pour les clients Windows, Android et Apple.

Par défaut, une clé RSA est générée au démarrage dans /etc/iked/local.pub, avec la clé privée enregistrée dans etc/iked/private/local.key.

Cela peut être réalisé par l'échange des clés publiques RSA fournies par défaut : la clé /etc/iked/local.pub du premier système (“server1”) devra être copiée vers /etc/iked/pubkeys/fqdn/server1.domain du second système (“server2”). Ensuite, la clé /etc/iked/local.pub du second système devra être copiée vers /etc/iked/pubkeys/fqdn/server2.domain du premier. Remplacez “serverX.domain” par votre propre FQDN.

À partir de ce point, nous assumerons le fait que le server1 a l'adresse IP publique 192.0.2.1 et un réseau interne 10.0.1.0/24, et que le server2 a une adresse IP publique 198.51.100.1 et un réseau internet 10.0.2.0/24.

Pour permettre à l'initiateur d'atteindre le répondeur, le port UDP isakmp devra être ouvert sur le répondeur. Si un des pairs est derrière un NAT, le port UDP ipsec-nat-t devra aussi être ouvert sur le répondeur. Si les deux pairs ont des adresses IP publiques alors le protocole ESP devra être permis.

pass in log on $ext_if proto udp from 198.51.100.1 to 192.0.2.1 port {isakmp, ipsec-nat-t} tag IKED
pass in log on $ext_if proto esp from 198.51.100.1 to 192.0.2.1 tag IKED

Un exemple de configuration du fichier /etc/iked.conf pour le server1 (agissant comme répondeur) pourrait ressembler à cela :

ikev2 'server1_rsa' passive esp \
      from 10.0.1.0/24 to 10.0.2.0/24 \
      local 192.0.2.1 peer 198.51.100.1 \
      srcid server1.domain \

Et une simple configuration pour le server2 comme initiateur :

ikev2 'server2_rsa' active esp \
        from 10.0.2.0/24 to 10.0.1.0/24 \
        peer 192.0.2.1 \
        srcid server2.domain

Utiliser iked -dv peut vous aider à comprendre l'échange. Dans cet exemple, le répondeur est derrière un NAT :

server1# iked -dv
...
ikev2_recv: IKE_SA_INIT request from initiator 198.51.100.1:500 to 192.0.2.1:500 policy 'server1_rsa' id 0, 510 bytes
ikev2_msg_send: IKE_SA_INIT response from 192.0.2.1:500 to 198.51.100.1:500 msgid 0, 451 bytes
ikev2_recv: IKE_AUTH request from initiator 198.51.100.1:4500 to 192.0.2.1:4500 policy 'server1_rsa' id 1, 800 bytes
ikev2_msg_send: IKE_AUTH response from 192.0.2.1:4500 to 198.51.100.1:4500 msgid 1, 720 bytes, NAT-T

Du côté de l'initiateur :

server2# iked -dv
...
ikev2_msg_send: IKE_SA_INIT request from 0.0.0.0:500 to 192.0.2.1:500 msgid 0, 510 bytes
ikev2_recv: IKE_SA_INIT response from responder 192.0.2.1:500 to 198.51.100.1:500 policy 'server2_rsa' id 0, 451 bytes
ikev2_msg_send: IKE_AUTH request from 198.51.100.1:4500 to 192.0.2.1:4500 msgid 1, 800 bytes, NAT-T
ikev2_recv: IKE_AUTH response from responder 192.0.2.1:4500 to 198.51.100.1:4500 policy 'server2_rsa' id 1, 720 bytes
sa_state: VALID -> ESTABLISHED from 192.0.2.1:4500 to 198.51.100.1:4500 policy 'server2_rsa'

Les flux IPSec peuvent être vus avec ipsecctl(8) :

server1# ipsecctl -sa
FLOWS:
flow esp in from 10.0.2.0/24 to 10.0.1.0/24 peer 198.51.100.1 srcid FQDN/server1.domain dstid FQDN/server2.domain type use
flow esp out from 10.0.1.0/24 to 10.0.2.0/24 peer 198.51.100.1 srcid FQDN/server1.domain dstid FQDN/server2.domain type require
flow esp out from ::/0 to ::/0 type deny

SAD:
esp tunnel from 192.0.2.1 to 198.51.100.1 spi 0xabb5968a auth hmac-sha2-256 enc aes-256
esp tunnel from 198.51.100.1 to 192.0.2.1 spi 0xb1fc90b8 auth hmac-sha2-256 enc aes-256

server2# ipsecctl -sa
FLOWS:
flow esp in from 10.0.1.0/24 to 10.0.2.0/24 peer 192.0.2.1 srcid FQDN/server2.domain dstid FQDN/server1.domain type use
flow esp out from 10.0.2.0/24 to 10.0.1.0/24 peer 192.0.2.1 srcid FQDN/server2.domain dstid FQDN/server1.domain type require
flow esp out from ::/0 to ::/0 type deny

SAD:
esp tunnel from 192.0.2.1 to 198.51.100.1 spi 0xabb5968a auth hmac-sha2-256 enc aes-256
esp tunnel from 198.51.100.1 to 192.0.2.1 spi 0xb1fc90b8 auth hmac-sha2-256 enc aes-256

Avec cela, les deux réseaux internes devraient être capables de s'atteindre l'un l'autre. Le trafic entre eux devrait apparaître après décapsulation de l'interface enc0, et peut ainsi être filtré. Dans cet exemple, le tag VPN a été ajouté à la politique :

# pfctl -vvsr|grep VPN
@16 pass log on enc0 tagged VPN
# tcpdump -nei pflog0 rnr 16
00:03:26.793522 rule 16/(match) pass in on enc0: 10.0.2.24 > 10.0.1.13: icmp: echo request

Quelques mots d'attention :

• Si le répondeur n'a pas paramétré srcid, alors iked essayera d'utiliser la clé correspondant à son FQDN par défaut
• Le répondeur n'a pas besoin de paramétrer local, il doit juste s'assurer qu' iked écoute sur l'interface correcte.
• Le répondeur n'a pas besoin de paramétrer peer, il doit juste s'assurer que les connexions viennent bien de l'adresse IP de confiance.

Si les points terminaux des VPN ont besoin d'atteindre le réseau interne à distance, ou que le réseau interne à besoin d'atteindre le point terminal VPN, les flux additionnels doivent être paramétrés des deux côtés :

• depuis l'IP locale publique vers le réseau à distance
• depuis le réseau interne vers l'IP publique à distance

La configuration du répondeur pourrait ressembler à celle-ci :

ikev2 'server1_rsa' passive esp \
      from 10.0.1.0/24 to 10.0.2.0/24 \
      from 10.0.1.0/24 to 198.51.100.1 \
      from 192.0.2.1 to 10.0.2.0/24 \
      local 192.0.2.1 peer 198.51.100.1 \
      srcid server1.domain      

Et, celle de l'initiateur pourrait être :

ikev2 'server2_rsa' active esp \
        from 10.0.2.0/24 to 10.0.1.0/24 \
        from 10.0.2.0/24 to 192.0.2.1 \
        from 198.51.100.1 to 10.0.1.0/24 \
        peer 192.0.2.1 \
        srcid server2.domain

Se connecter à un VPN IKEv2 en tant que road warrior est similaire au cas précédent, excepté que l'initiateur envisage généralement d'acheminer son trafic Internet via le répondeur, qui agira comme NAT, ainsi le trafic de l'initiateur apparaîtra venir de l'adresse IP publique du répondeur.

Selon ce cas d'utilisation, comme tout le trafic passera au-travers du répondeur, il faut s'assurer que l'initiateur soit configuré pour utiliser un serveur DNS qu'il peut atteindre (éventuellement un sur le répondeur)

Dans nos exemples, le réseau 10.0.5.0/24 est utilisé pour supporter le VPN. L'adresse IP interne actuelle sera automatiquement installée par iked sur l'interface vether0. Nous assumerons le fait que l'adresse IP publique du client est 203.0.113.2.

Comme dans l'exemple précédent, l'échange des clés publiques RSA fournies par défaut est suffisant pour paramétrer une simple authentification entre le répondeur et l'initiateur : /etc/iked/local.pub du premier système (“server1”) devra être copié vers /etc/iked/pubkeys/fqdn/server1.domain du second système (“roadwarrior”). Ensuite /etc/iked/local.pub du système roadwarrior devra être copié vers /etc/iked/pubkeys/fqdn/roadwarrior du premier. Remplacez “serverX.domain” avec votre propre FQDN.

Le répondeur iked.conf(5) crée les flux depuis toute destination au baux d'IP dynamique venant du pool d'adresses, qui sera décidé au démarrage, et étiquette les paquets avec ROADW :

ikev2 'responder_rsa' passive esp \
        from any to dynamic \
        local 192.0.2.1 peer any \
        srcid server1.domain \
        config address 10.0.5.0/24 \
        tag "ROADW"

Le répondeur a besoin de fournir une adresse IP à l'initiateur. Ce qui est réalisé par les directives de configuration. Par l'utilisation de l'option config address, to dynamic sera remplacé par l'adresse IP dynamique assignée.

Il a aussi besoin d'allouer IPSec depuis tout hôte (puisque les clients peuvent se connecter de n'importe où), permettre le trafic étiqueté ROADW sur enc0 et d'appliquer la NAT :

pass in log on $ext_if proto udp from any to 192.0.2.1 port {isakmp, ipsec-nat-t} tag IKED
pass in log on $ext_if proto esp from any to 192.0.2.1 tag IKED
pass log on enc0 tagged ROADW
match out log on $ext_if inet tagged ROADW nat-to $ext_if

L'initiateur configure un flux global pour envoyer tout son trafic au répondeur, lui demandant de s'identifier avec la clé nommée “roadwarrior” :

ikev2 'roadwarrior' active esp \
        from dynamic to any \
        peer 192.0.2.1 \
        srcid roadwarrior \
        dstid server1.domain \
        request address any \
        iface vether0

L'initiateur utilise l'adresse l'opotion request address any pour demander une adresse IP dynamique au répondeur. L'option iface vether0 spécifie l'interface qui reçoit l'adresse et les routes correspondantes seront installées. Le répondeur doit avoir une configuration NAT appropriée pour le client road warrior.

Arrêter correctement le VPN sur l'initiateur peut être réalisé en utilisant ikectl decouple (iked est toujours fonctionnel, attendant ikectl couple afin de se reconnecter au répondeur) ou avec ikectl reset sa && rcctl stop iked pour arrêter définitivement iked et s'assurer qu'il n'y ait plus de flux.

Le client VPN par défaut d'Android supporte seulement IKEv1. Pour utiliser IKEv2, strongSwan est une option.

Il est aussi requis de paramétrer un PKI et des certificats X.509 ainsi l'initiateur pourra valider le certificat émis par le répondeur :

server1# ikectl ca vpn create
server1# ikectl ca vpn install
certificate for CA 'vpn' installed into /etc/iked/ca/ca.crt
CRL for CA 'vpn' installed to /etc/iked/crls/ca.crl
server1# ikectl ca vpn certificate server1.domain create
server1# ikectl ca vpn certificate server1.domain install
writing RSA key
server1# cp /etc/iked/ca/ca.crt /var/www/htdocs/

Sur le périphérique Android, allez sur http://192.0.2.1/ca.crt et importez le certificat CA dans le client strongSwan. À partir de là, il y a plusieurs manières d'authentifier l'initiateur au répondeur :

• EAP avec nom utilisateur et mot de passe
• un certificat X.509

La configuration du répondeur a besoin de spécifier une liste de noms d'utilisateurs et mots de passe, et utilisera eap “mschap-v2” (qui est la seule méthode EAP prise en charge actuellement), telle que :

user 'android' 'password'
ikev2 'responder_eap' passive esp \
        from any to dynamic \
        local 192.0.2.1 peer any \
        srcid server1.domain \
        eap "mschap-v2" \
        config address 10.0.5.0/24 \
        config name-server 192.0.2.1 \
        tag "ROADW"

Sur le client strongSwan, un nouveau profil est configuré en utilisant :

• IKEv2 EAP comme type VPN
• 192.0.2.1 pour le champ server
• les valeurs de login/password paramétrées dans la configuration du répondeur
• le certificat nouvellement importé CN=VPN pour le champ CA certificate
• client1.domain pour le champ User identity
• server1.domain pour le champ Server identity (dans les paramètres avancés : 'advanced settings')

Avec cela, le périphérique Android peut se connecter au répondeur, authentifier le certificat du répondeur avec le certificat CA, s'authentifier au répondeur avec le couple de connexion EAP, obtenir une adresse dans le réseau 10.0.5.0/24, et tout son trafic passant au-travers du VPN, utilisant 192.0.2.1 comme étant son serveur DNS.

Pour cette méthode, un certificat est généré pour le client, installé dans iked ca, exporté comme une archive ; le fichier .pfx devra être rendu disponible en ligne afin que le client puisse l'installer. Le fichier .pfx comprend :

• le certificat X.509
• la clé privée X.509, chiffrée avec RSA
• la clé privée RSA utilisant la clé privée X.509 chiffrée
• la clé RSA publique

server1# ikectl ca vpn certificate client1.domain create
server1# cp /etc/ssl/vpn/client1.domain.crt /etc/iked/certs/
server1# ikectl ca vpn certificate client1.domain export
server1# tar -C /tmp -xzf client1.domain.tgz *pfx
server1# cp /tmp/export/client1.domain.pfx /var/www/htdocs/client1.domain.pfx

Le certificat public CA et le certificat du client ont été importés dans le client strongSwan lors de la configuration du nouveau profil.

La configuration du répondeur est légèrement plus simple puisqu'il n'y a pas besoin de spécifier eap ni de paramétrer un nom utilisateur et mot de passe.

ikev2 'responder_x509' passive esp \
        from any to dynamic \
        local 192.0.2.1 peer any \
        srcid server1.domain \
        config address 10.0.5.0/24 \
        config name-server 192.0.2.1 \
        tag "ROADW"

Dans le client strongSwan, un nouveau profil est configuré, utilisant :

• IKEv2 certificate pour le type VPN
• 192.0.2.1 pour le champ server
• le certificat nouvellement importé CN=client1.domain pour le champ User certificate
• client1.domain pour le champ User identity
• server1.domain dans le champ Server identity (dans les paramètres avancés : 'advanced settings')

Tel que dans le cas EAP, le périphérique Android peut maintenant se connecter au répondeur et utiliser le VPN.

Windows 7 et supérieur fournit un initiateur IKEv2 qui requiert aussi l'utilisation des certificats X.509, qui a besoin d'être exporté en tant que .pfx/.p12 et importé dans le magasin de certificats de la machine locale (non pas dans le compte utilisateur), à la fois pour la CA et pour le client, soit en utilisant la console de gestion Microsoft - MMC (écrivez mmc dans une ligne de commande et ajoutez les certificats comme compte d'ordinateur) ou avec la commande certutil dans Windows 10. Importez ca.crt dans le magasin de certificats d'autorité, et ClientIP.p12 dans le magasin personnel. Le projet StrongSwan a une bonne documentation à ce propos, avec des captures d'écrans.

Windows ne facilite pas le paramétrage srcid pour le client ; le champ CN du certificat client doit correspondre avec le client FQDN envoyé par le répondeur, ou son adresse IP par défaut. Il est aussi requis que srcid sur le répondeur corresponde avec le FQDN du répondeur (ou son adresse IP, s'il n'utilise pas FQDN) - autrement vous expérimenterez l'erreur redoutée error 3801. Le projet Libreswan a de précieuses précisions sur ces prérequis.

Une fois que les certificats ont été importés, configurez une nouvelle connexion VPN, avec :

• le FQDN du répondeur ayant pour cible le nom d'hôte dans l'onglet general
• IKEv2 pour le type dans l'onglet security
• soit 'machine certificate' ou 'EAP authentication' pour l'authentification
• si vous utilisez EAP, le login/password sera affiché lors de la connexion

Le fichier de configuration du répondeur sera très similaire au cas Android.

user 'windows' 'password'
ikev2 'responder_eap' passive esp \
        from any to dynamic \
        local 192.0.2.1 peer any \
        srcid server1.domain.fqdn \
        eap "mschap-v2" \
        config address 10.0.5.0/24 \
        config name-server 192.0.2.1 \
        tag "ROADW"

Par défaut, tout le trafic windows passera au-travers du VPN IKEv2.

Au moment de l'écriture de ce tutoriel, les versions actuelles de Windows utilisent un faible chiffrement par défaut (3DES/SHA1). Cela peut être corrigé avec la commande PowerShell Set-VpnConnectionIPsecConfiguration.

Parfois, on ne contrôle pas le serveur VPN, et le seul choix donné est de se connecter à un serveur IKEv1. Dans ce cas, le paquet tierce xl2tpd est nécessaire pour agir en tant que client L2TP.

Il est premièrement requis d'activer les services isakmpd(8) et ipsec, ainsi les démons seront actifs et le fichier de configuration ipsec.conf(5) sera chargé au démarrage :

# rcctl enable ipsec
# rcctl enable isakmpd
# rcctl set isakmpd flags -K

La configuration ipsec.conf(5) suivante devrait permettre de se connecter à un serveur IKEv1 à A.B.C.D avec un PSK fourni, permettant seulement le port UDP 1701 pour L2TP :

ike dynamic esp transport proto udp from egress to A.B.C.D port l2tp \
        psk mekmitasdigoat

Démarrer isakmpd(8) et charger ipsec.conf(5) en utilisant ipsecctl(8) devrait vous permettre de visualiser les Associations de Sécurité (SAs) configurées et les flux :

# rcctl start isakmpd
# ipsecctl -f /etc/ipsec.conf
# ipsecctl -sa
FLOWS:
flow esp in proto udp from A.B.C.D port l2tp to W.X.Y.Z peer A.B.C.D srcid my.client.fqdn dstid A.B.C.D/32 type use
flow esp out proto udp from W.X.Y.Z to A.B.C.D port l2tp peer A.B.C.D srcid my.client.fqdn dstid A.B.C.D/32 type require

SAD:
esp transport from A.B.C.D to W.X.Y.Z spi 0x0d16ad1c auth hmac-sha1 enc aes
esp transport from W.X.Y.Z to A.B.C.D spi 0xcd0549ba auth hmac-sha1 enc aes

Si ce n'est pas le cas, il peut être utile d'ajuster les paramètres de phase 1 (Main) et phase 2 (Quick), quand les deux parties échangent les paramètres de chiffrement afin d'agréer la meilleure combinaison disponible. Idéalement, ces paramètres devraient être fournis par l'administrateur système à distance, et devraient être utilisés dans ipsec.conf(5) :

ike dynamic esp transport proto udp from egress to A.B.C.D port l2tp \
        main auth "hmac-sha1" enc "3des" group modp1024 \
        quick auth "hmac-sha1" enc "aes" \
        psk mekmitasdigoat

Une fois que le tunnel IKEv1 est monté et fonctionnel, le tunnel L2TP a besoin d'être configuré. OpenBSD ne fournit pas de client L2TP par défaut, ainsi l'installation de xl2tpd est requise :

# pkg_add xl2tpd 

Référez-vous au fichier /usr/local/share/doc/pkg-readmes/xl2tpd pour les instructions sur comment paramétrer proprement le client L2TP.

Cette page est la traduction officieuse de la page FAQ - Virtual Private Networks (VPN) de la FAQ officielle d'OpenBSD.
En cas de doute, merci de vous y référer !

Si vous voulez participer à l'effort de traduction, merci de lire ce topic.

Contribut(rice|eur)s :