🥳 Network IPv6 - IPSec - strongSwan - Modern Security communication

[ZW3B]

Bonsoir,

j’ai installé strongSwan 6.0beta Vici Post-Quantum IKEv2 Daemon. Bien sûr vous pouvez utiliser la version officielle d’aujourd’hui, la version 5.9 sans compiler, mais vous ne pourrez pas chiffrer avec les algorithmes OQS.

Je ne connais pas « stroongSwan VICI » c’est à dire une configuration IPSec sans le fichier « ipsec.conf » (j’ai du retard sûrement) :

Avec ces fichiers donc :

/etc/strongswan.conf
/etc/swanctl/swanctl.conf

Je voulais créer un « mémo » - je me suis dis que sur ce forum c’était parfait.

J’ai fais quelques « tests » pour joindre plusieurs réseaux et sous-réseaux IPv6 (ULA et UNICAST GLOBAL) et je souhaitai ouvrir ce sujet pour ce grand plaisir de « sécurité moderne ».

Je ne connais pas, ou plutôt n’ai « jamais utilisé » la commande « ip xfrm » non plus.

xfrm est un framework IP pour transformer les paquets (comme le chiffrement de leurs payloads (charges utiles). Ce cadre est utilisé pour implémenter la suite de protocoles IPsec (avec l’objet state fonctionnant sur la base de données d’association de sécurité et l’objet policy fonctionnant sur la base de données de politique de sécurité). Il est également utilisé pour le protocole de compression de charge utile IP et les fonctionnalités de Mobile IPv6.

ip xfrm state add	add new state into xfrm
ip xfrm state update	update existing state in xfrm
ip xfrm state allocspi	allocate an SPI value
ip xfrm state delete	delete existing state in xfrm
ip xfrm state get	get existing state in xfrm
ip xfrm state deleteall	delete all existing state in xfrm
ip xfrm state list	print out the list of existing state in xfrm
ip xfrm state flush	flush all state in xfrm
ip xfrm state count	count all existing state in xfrm

ip xfrm policy add	add a new policy
ip xfrm policy update	update an existing policy
ip xfrm policy delete	delete an existing policy
ip xfrm policy get	get an existing policy
ip xfrm policy deleteall	delete all existing xfrm policies
ip xfrm policy list	print out the list of xfrm policies
ip xfrm policy flush	flush policies

Déjà, je voulais remonter cette information.

Après une déconnexion de ma boxe internet par exemple, je reste connecté à la IKEv2_SA - par contre j’ai étais déconnecté de la CHILD_SA.

root@initiator:~ # swanctl --list-sas
gw-gw: #4, ESTABLISHED, IKEv2, 66402962da1dd722_i befb11fc81c37e67_r*
  local  'bw.zw3b.eu' @ 192.168.1.254[4500]
  remote 'vps.zw3b.eu' @ 135.125.133.51[4500]
  AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519/KE1_KYBER_L3/KE2_BIKE_L3/KE3_HQC_L3/KE4_HQC_L5
  established 13185s ago, rekeying in 684s

J’aimerai savoir si une commande permettrait de « terminer » la connexion de l’association de sécurité IKEv2.

Bon j’ai trouvé la solution, pour terminer la connexion IKE_SA (enfants ou non) :

$ swanctl --terminate --ike gw-gw

Pour initialiser une connexion IKE_SA seulement :

$ swanctl --initiate --ike gw-gw

Pour initialiser une connexion IKE_SA + CHILD_SA :

$ swanctl --initiate [ --ike gw-gw ] --child gw-gw

Sur une « association de sécurité IKE » en particulier ouvrir sur un autre « Child SA » :

$ swanctl --initiate --ike gw-gw --child test
initiate failed: CHILD_SA config 'test' not found

Pour terminer une connexion CHILD_SA :

$ swanctl --terminate --ike gw-gw --child test

---

Documentation StrongSwan - Modern vici-based Scenarios IPv6 Configuration Examples et la page Usable Examples configurations.

Dumps de trafic IPsec sous Linux :: strongSwan Documentation
Il s’agit d’un court didacticiel expliquant comment obtenir des dumps de trafic IPsec corrects sous Linux.
De nombreux utilisateurs ne sont pas conscients de l’anomalie de capture de paquets qui se produit lors de la capture avec les paramètres par défaut à l’aide de Wireshark et tcpdump. Cet article expliquera comment effectuer des vidages de trafic corrects de…​

#tcpdump #wiresharp #certifs

Sous Linux, « strongSwan » installe les routes dans la table de routage 220 par défaut et nécessite donc que le noyau prenne en charge le routage basé sur des politiques.

ip -6 route show table 220

Documentation strongSwan :: Introduction to strongSwan → Routing
Documentation strongSwan :: Route-based VPN

J'ajoute un script "updown.sh"

Vu que j’essaie de passer directement sur l’interface réseau principale, je n’utilise ce script (en bas de la page Route-based VPN. Je ne sais pas encore si c’est mieux de créer des interfaces « vti_/ipsecX » ou de tout faire passer sur la carte principale. Pour l’instant « je galère avec mes routes » sans dissocier plusieurs interfaces réseaux (pour plusieurs connexions), mais au final cela pourait être mieux que d’avoir 20 ethernet « ipsec », je sais pas trop.

#!/bin/bash

# set charon.install_virtual_ip = no to prevent the daemon from also installing the VIP

set -o nounset
set -o errexit

VTI_IF="vti${PLUTO_UNIQUEID}"

PLUTO_MY_SOURCEIP="172.16.5.1"

#PLUTO_MARK_OUT=42

echo ''
echo 'VTP_IF : '$VTI_IF
echo 'PLUTO_VERB : '$PLUTO_VERB
echo 'PLUTO_ME : '$PLUTO_ME
echo 'PLUTO_PEER : '$PLUTO_PEER

#echo 'PLUTO_MARK_IN : '$PLUTO_MARK_IN
#echo 'PLUTO_MARK_OUT : '$PLUTO_MARK_OUT

echo 'PLUTO_MY_SOURCEIP :'$PLUTO_MY_SOURCEIP
echo 'PLUTO_PEER_SOURCEIP : '$PLUTO_PEER_SOURCEIP
echo 'PLUTO_PEER_CLIENT : '$PLUTO_PEER_CLIENT
echo ''

case "${PLUTO_VERB}" in
    up-client)
        ip tunnel add "${VTI_IF}" local "${PLUTO_ME}" remote "${PLUTO_PEER}" mode vti key "${PLUTO_MARK_OUT%%/*}"
#       ip tunnel add "${VTI_IF}" local "${PLUTO_ME}" remote "${PLUTO_PEER}" mode vti key "42"
#        ip tunnel add "${VTI_IF}" local "${PLUTO_ME}" remote "${PLUTO_PEER}" mode vti

        ip link set "${VTI_IF}" up
        ip addr add "${PLUTO_MY_SOURCEIP}" dev "${VTI_IF}"

        # Ajoutez les itinéraires souhaités sur le tunnel
        ip route add "${PLUTO_PEER_SOURCEIP}" dev "${VTI_IF}"

        # Désactivez les vérifications de politique pour cette interface, sinon le noyau supprimera le trafic après le déchiffrement.
        sysctl -w "net.ipv4.conf.${VTI_IF}.disable_policy=1"

        # Disable RP filter for the tunnel interface
        sysctl -w "net.ipv4.conf.${VTI_IF}.rp_filter=0"

        ;;
    down-client)
        ip tunnel del "${VTI_IF}"
        ;;
esac

Merci.

IPsec (Internet Protocol Security)

IPSec permet d’assurer des communications privées et protégées sur des réseaux IP, par l’utilisation des services de sécurité cryptographiques. De plus, IPsec opère à la couche réseau (couche 3 du modèle OSI), ce qui le rend indépendant des applications, et veut dire que les utilisateurs n’ont pas besoin de configurer chaque application.
Son objectif est d’authentifier et de chiffrer les données : le flux ne pourra être compréhensible que par le destinataire final (confidentialité) et la modification des données par des intermédiaires ne pourra être possible (Intégrité).

Lors de l’établissement d’une connexion IPsec, plusieurs opérations sont effectuées :

1. Échange des clés

• un canal d’échange de clés, sur une connexion UDP depuis et vers le port 500 (ISAKMP pour Internet Security Association and Key Management Protocol).
  Le protocole IKE (Internet Key Exchange) est chargé de négocier la connexion. Avant qu’une transmission IPsec puisse être possible, IKE est utilisé pour authentifier les deux extrémités d’un tunnel sécurisé en échangeant des clés.

2. Transfert des données
   Un ou plusieurs canaux de données par lesquels le trafic du réseau privé est véhiculé, deux protocoles sont possibles :

• le protocole no 51, AH, (Authentication Header) fournit l’intégrité et l’authentification. AH authentifie les paquets en les signant, ce qui assure l’intégrité de l’information. Une signature unique est créée pour chaque paquet envoyé et empêche que l’information soit modifiée.
• le protocole no 50, ESP (Encapsulating Security Payload), en plus de l’authentification et l’intégrité, fournit également la confidentialité par l’entremise de la cryptographie.

IPsec peut fonctionner dans un mode transport hôte à hôte ou bien dans un mode tunnel réseau.

• Mode transport
  Dans le mode transport, ce sont uniquement les données transférées (la partie payload du paquet IP) qui sont chiffrées et/ou authentifiées. Le reste du paquet IP est inchangé et de ce fait le routage des paquets n’est pas modifié. Néanmoins, les adresses IP ne pouvant pas être modifiées par le NAT sans corrompre le hash de l’en-tête AH généré par IPsec, AH ne peut pas être utilisé dans un environnement nécessitant ces modifications d’en-tête. En revanche, il est possible d’avoir recours à l’encapsulation NAT-T pour encapsuler IPSec ESP. Le mode transport est utilisé pour les communications dites hôte à hôte (Host-to-Host).

• Mode tunnel
  En mode tunnel, c’est la totalité du paquet IP qui est chiffré et/ou authentifié. Le paquet est ensuite encapsulé dans un nouveau paquet IP avec un nouvel en-tête IP. Au contraire du mode transport, ce mode supporte donc bien la traversée de NAT quand le protocole ESP est utilisé. Le mode tunnel est utilisé pour créer des réseaux privés virtuels (VPN) permettant la communication de réseau à réseau (c.a.d. entre deux sites distants), d’hôte à réseau (accès à distance d’un utilisateur) ou bien d’hôte à hôte (messagerie privée.)

IPsec utilise une association de sécurité (Security association) pour dicter comment les parties vont faire usage de AH (Authentication header), protocole définissant un format d’en-tête spécifique portant les informations d’authentification, et de ESP l’encapsulation de la charge utile d’un paquet.

---

Source : Wikipédia → IPsec

IKE (Internet Key Exchange)

Le protocole IKE (Internet Key Exchange) est chargé de négocier la connexion. Avant qu’une transmission IPsec puisse être possible, IKE est utilisé pour authentifier les deux extrémités d’un tunnel sécurisé en échangeant des clés partagées ou des certificats. Ce protocole permet deux types d’authentifications, PSK (secret prépartagé ou secret partagé) pour la génération de clefs de sessions RSA ou à l’aide de certificats. IKE utilise l’échange de clés Diffie-Hellman.

---

Source : Wikipédia → Internet Key Exchange - Échange de clés Diffie-Hellman

AH (Autentification Header)

L’Autentification Header ou AH est un protocole définissant un format d’en-tête spécifique portant les informations d’authentification, et de l’encapsulation de la charge utile d’un paquet. À l’aide de l’AH on obtient l’authentification et l’intégrité. AH authentifie les paquets en les signant, ce qui assure l’intégrité de l’information. Une signature unique est créée pour chaque paquet envoyé et empêche que l’information soit modifiée.

---

Source : Wikipédia → Authentication Header

ESP (Encapsulating Security Payload)

Encapsulating Security Payload (ou ESP), est un protocole appartenant à la suite IPsec, permettant de combiner plusieurs services de sécurité : confidentialité, authentification et intégrité.

ESP fournit le chiffrement des messages / données utiles et l’authentification d’une donnée utile et de son origine. Le protocole ESP assure la confidentialité des encapsulations des messages, des données utiles. ESP propose également les services AH. ESP propose de l’authentification de la même manière que AH grâce à l’utilisation de données d’en-tête : Le SPI (Security Parameters Index).

ESP ne protège pas l’en-tête du paquet; cependant, dans un mode tunnel si le paquet entier est encapsulé dans un autre paquet en tant que paquet de données utiles / données, il peut crypter le paquet entier résidant à l’intérieur d’un autre paquet.

---

Source : Wikipédia → Encapsulating Security Payload

EAP (Extensible Authentication Protocol)

Extensible Authentication Protocol ou EAP est un protocole de communication réseau embarquant de multiples méthodes d’authentification, pouvant être utilisé sur les liaisons point à point, les réseaux filaires et les réseaux sans fil tels que les réseaux Wi-Fi.

Plusieurs méthodes d’authentification sont prédéfinies (MD5, OTP (One-Time Passwords), Generic Token Card, SIM, etc.) mais il est possible d’en rajouter sans qu’il soit nécessaire de changer ou de créer un nouveau protocole réseau.

Il est conçu pour fournir un mécanisme d’authentification pour les liaisons PPP (couche 2 du modèle OSI) afin d’autoriser ou interdire l’établissement de la couche réseau (couche 3 du modèle OSI). Ce protocole ne s’appuie donc pas sur le protocole IP (couche 3 du modèle OSI).

La liaison PPP est définie entre un peer et un authenticator.
L’authenticator peut envoyer une requête au peer pour connaître son identité ou alors de déterminer son identité par l’interface de communication.
Cette identification est suivie d’une ou plusieurs requêtes envoyées par l’authenticator (obligatoire) avec un paramètre contenant la méthode d’authentification souhaitée (MD5, OTP (One-Time Passwords), Generic Token Card, SIM, etc.)
Cette authentification peut être réalisée par l’authenticator lui-même ou déléguée à un service tiers (authentication server). L’authentification peut être demandée par chaque extrémité.

Le protocole EAP ne supporte pas nativement la fragmentation des paquets réseau (MTU (Maximum Transmission Unit)) mais ce comportement peut être modifié avec certaines méthodes :

Les standards WPA et WPA2 ont adopté 5 types d’EAP comme mécanismes officiels d’identification.

• EAP-TLS
• EAP-TTLS/MSCHAPv2
• PEAPv0/EAP-MS-CHAPv2
• PEAPv1/EAP-GTC
• EAP-SIM

---

• EAP-TLS : C’est le seul protocole EAP qui doit obligatoirement être implanté sur un matériel pour que ce dernier puisse porter le logo WPA ou WPA2. Il offre une bonne sécurité. En effet il utilise deux certificats pour la création d’un tunnel sécurisé qui permet ensuite l’identification : un côté serveur et un côté client. Cela signifie que même si le mot de passe est découvert, il ne sera d’aucune utilité sans le certificat client. Bien que EAP-TLS fournisse une excellente sécurité, l’obligation de disposer d’un certificat client est peut-être son talon d’Achille. En effet lorsque l’on dispose d’un grand parc de machines, il peut s’avérer difficile et coûteux de gérer un certificat par machine. C’est pour se passer du certificat client que les protocoles PEAP et EAP-TTLS ont été créés.
  Il utilise une Infrastructure à clés publiques (PKI) pour sécuriser les communications d’identification entre les clients et le serveur RADIUS (Remote Authentication Dial-In User Service).

• EAP-TTLS ou EAP-Tunneled Transport Layer Security utilise des certificats X-509 uniquement sur le serveur d’identification. Le certificat est optionnel du côté client. Il offre un très bon niveau de sécurité. Le défaut de EAP-TTLS par rapport à PEAP est de ne pas être présent nativement sur les systèmes Microsoft et Cisco. En revanche, il est légèrement plus sécurisé que PEAP car il ne diffuse pas le nom de l’utilisateur en clair.

• PEAP Protected EAP : PEAP est très similaire à une autre méthode EAP : EAP-TTLS. Protected EAP a été créé pour contrer EAP-TTLS qui était jusque-là la seule méthode EAP à utiliser une Infrastructure à clés publiques (Public Key Infrastructure, PKI) que du côté serveur, pour la création d’un tunnel TLS protégeant l’identification. Dans ces deux standards, l’utilisation d’une clef publique côté client est optionnelle. Il existe deux versions de PEAP certifiées WPA (mise à jour) et WPA2 : PEAPv0/EAP-MS-CHAPv2 et PEAPv1/EAP-GTC.

• EAP-SIM est une méthode EAP pour les clients des réseaux Wi-Fi et des réseaux de téléphonie mobile GSM, UMTS et LTE. Il est utilisé pour l’identification et la distribution de clefs au travers des réseaux ; SIM signifie « Subscriber Identity Module ».

Autres méthodes EAP (Extensible Authentication Protocol) :

• LEAP, EAP-MD5, EAP-FAST, EAP-AKA

---

Source : Wikipédia : Extensible Authentication Protocol - Maximum Transmission Unit (MTU)

SA (Security Association)

Une association de sécurité IPSec est une structure de données servant à stocker l’ensemble des paramètres de sécurité associés à une communication . Une SA étant unidirectionnelle, il faut deux SA pour protéger les deux sens d’une communication.

---

Source : Wikipedia → Security association

SPI (Security Parameter Index)

L’index des paramètres de sécurité (SPI) est une balise d’identification ajoutée à l’en-tête lors de l’utilisation d’IPsec pour tunneliser le trafic IP. Cette balise aide le noyau à distinguer deux flux de trafic dans lesquels des règles et algorithmes de chiffrement différents peuvent être utilisés.

Le SPI (conformément à la RFC 2401) est un élément obligatoire d’une association de sécurité (SA) IPsec car il permet au système de réception de sélectionner la SA sous laquelle un paquet reçu sera traité. Un SPI n’a qu’une signification locale, puisqu’il est défini par le créateur de la SA ; un SPI est généralement considéré comme une chaîne de bits opaque. Cependant, le créateur d’une SA peut interpréter les bits d’un SPI pour faciliter le traitement local.

Cela fonctionne comme les numéros de port dans les connexions TCP et UDP. Cela signifie qu’il peut y avoir différentes SA utilisées pour assurer la sécurité d’une connexion. Une SA pourrait donc agir comme un ensemble de règles.

Transporté dans l’en-tête Encapsulated Security Payload (ESP) ou dans l’en-tête d’authentification (AH), sa longueur est de 32 bits.

---

Source : Wikipedia → Security Parameter Index

Je finis avec :

PKI (Public Key Infrastructure)

Une « infrastructure à clés publiques » (ICP) ou « infrastructure de gestion de clés » (IGC) ou encore « public key infrastructure » (PKI), est un ensemble de composants physiques ou matériel type Hardware Security Module (HSM), de procédures humaines (vérifications, validation) et de logiciels destiné à gérer les clés publiques des utilisateurs d’un système.

Une infrastructure de gestion de clés permet de lier des clés publiques à des identités (comme des noms d’utilisateurs ou d’organisations). Une infrastructure de gestion de clés fournit des garanties permettant de faire a priori confiance à une clé publique obtenue par son biais.

Une erreur courante est d’assimiler le terme « infrastructure de gestion de clés » à « autorité de certification ». Cette erreur provient probablement du terme PKIX, pour PKI X.509, qui est lui bien associé aux autorités de certification et aux certificats X.509

L’infrastructure à clés publiques (PKI) repose sur un ensemble de processus, de technologies et de politiques qui permettent de chiffrer et de signer des données. Vous pouvez alors émettre des certificats numériques pour l’authentification de vos utilisateurs, de vos appareils et de vos services. Ces certificats établissent des connexions sécurisées pour vos pages web publiques, mais aussi vos systèmes privés (VPN, Wi-Fi interne, et autres services compatibles avec l’authentification multifacteur).

---

Source : Wikipedia → Infrastructure à clés publiques

Bonne journée, mesdames, messieurs.

Romain

PS : J’hésite à mettre ici ma configuration strongSwan (ce que je ferais sûrement, ultérieurement ;

→ Mes tests de configuration (j’ai rien de mieux pour le moment)

1. La config « 1 » est un exemple des fichiers « /etc/strongSwan.conf » (Serveur / Client)
2. La config « 2 » est OK sans sous-réseaux (IPv4 publique to IPv4 publique - le traceroute ne fait pas de saut entre les 2 machines connectées).
3. La config « 3 » est OK de « site » à « site » (ping & services) avec sous réseaux IPv6.
4. La config « 4 » est OK de « site » à « serveur » à « site » : (ping et services) avec sous-réseaux, j’en suis là au 20240313.

Exemple de création de certificats SSL/TLS avec la commande « pki ».

Il faudrait essayer d’autres méthodes d’autentification – EAP (Extensible Authentication Protocol)

20240313 : Je vous ajoute mon script « firewall-icmpv6 » où j’ai ajouté la fonction « ipv6_strongswan() » qui permet de laisser passer les requêtes UDP/TCP sur le prefix d’adresses « IPv6 SWAN Site-Local scoped » en plus de l’ICMPv6 (du ping)

• un bout du firewall-ipv6 pour checker les networks range de liens fe80::/10, des sites-Locals fec0::/10, du multicast ff00::/8 (même longueur de bloc IPv6::/64 et IPv6::/104) et des adresses locales fc00::/7

J’ai écris/copié/collé ces informations sur le sujet « IPsec modern communication IPv6 et IKEv2 security ».

Ce n’est pas trop « lourd » à lire

Note : pour infos j’ai ouvert un sujet sur LaFibre.info pour celles et ceux qui préféraient ou qui n’ont pas de compte sur Debian-Fr.org.

Greets.

---

GestióIP : IPv6 subnet calculator

Note personnelle d'un exemple réseau IPv6 (temporaire, todo)

---

Date : 20240226
Info : 🥳 Network IPv6 - IPSec - strongSwan - Modern Security communication

FR.LAB3W.DC (France/Alpes)

Je configure la machine serveur « domain controller »
Ici c’est chez moi à mon domicile.
J’ai plusieurs machines sur différents réseaux de machines, de tablettes, de smartphones etc.

VMBR0 <-> LAN/WAN

//-----------------------
// VMBR0 <-> LAN/WAN
//---------
// IP Address (addr unique locale magic) :
fc01:0000:0000:0000:0000:0000:0000:0253/16
// network range :
fc01:0000:0000:0000:0000:0000:0000:0000-
fc01:ffff:ffff:ffff:ffff:ffff:ffff:ffff

// IP Address (addr unique locale "fc01::") - gateway generale :
2001:cb1d:02d4:88ff:ffff:ffff:ffff:ffff/56
fc01:cb1d:02d4:88ff:ffff:ffff:ffff:ffff/56
// network range :
fc01:cb1d:02d4:8800:0000:0000:0000:0000-
fc01:cb1d:02d4:88ff:ffff:ffff:ffff:ffff
//-----------------------

VMBR1 <-> VLAN/VSERVERs

//-----------------------
// VMBR1 <-> VLAN/VSERVERs
//---------
// IP Address (addr unicast globale "2001::" / addr unique locale "fc01::") -> VLAN_D2 (a2ff:00ff/96) :
2001:cb1d:02d4:8851:0642:0000:a2ff:00ff/96
fc01:cb1d:02d4:8851:0642:0000:a2ff:00ff/96
// network range :
fc01:cb1d:02d4:8850:0000:0000:0000:0000- 
fc01:cb1d:02d4:885f:ffff:ffff:ffff:ffff
//-----------------------

---

FR.LAB3W.BW (France/Alpes)

Je configure la machine serveur « initiateur »
Ici c’est chez moi à mon domicile.
J’ai plusieurs machines sur différents réseaux de machines, de tablettes, de smartphones etc.

VMBR0 <-> LAN/WAN

//-----------------------
// VMBR0 <-> LAN/WAN
//---------
// IP Address (addr unique locale magic) :
fc00:0000:0000:0000:0000:0000:0000:0254/16
// network range :
fc00:0000:0000:0000:0000:0000:0000:0000-
fc00:ffff:ffff:ffff:ffff:ffff:ffff:ffff

// IP Address  (addr unicast globale "2001::" / addr unique locale "fc01::") :
2001:cb1d:2d4:8850:0642:0000:0000:0254/64
fc01:cb1d:2d4:8850:0642:0000:0000:0254/64
// network range :
fc01:cb1d:02d4:8850:0000:0000:0000:0000- 
fc01:cb1d:02d4:8850:ffff:ffff:ffff:ffff

//---------
// IP Address (addr secure wide area) :
fec0:0000:0000:0000:0000:0000:0000:0254/16
// network range :
fec0:0000:0000:0000:0000:0000:0000:0000-
fec0:ffff:ffff:ffff:ffff:ffff:ffff:ffff
//---------

VMBR1 <-> VLAN/VSERVERs

//-----------------------
// VMBR1 <-> VLAN/VSERVERs
//---------
// IP Address (addr unicast globale "2001::" / addr unique locale "fc01::") -> VLAN_D1 (a1ff:00ff/96) :
2001:cb1d:02d4:8851:0642:0000:a1ff:00ff/96
fc01:cb1d:02d4:8851:0642:0000:a1ff:00ff/96
// network range :
fc01:cb1d:02d4:8851:0642:0000:0000:0000-
fc01:cb1d:02d4:8851:0642:0000:ffff:ffff
//-----------------------

---

DE.LAB3W.VPS (Allemagne/Berllin)

Ici c’est un VPS (1 seule IPv6 UNICAST GLOBAL).

VMBR0 <-> LAN/WAN

//-----------------------
// VMBR0 <-> LAN/WAN
//---------

// IP Address (addr unicast globale "2001::/128" :
2001:41d0:701:1100::6530/128

//---------
// IP Address (addr secure wide area) :
fec0:0000:0000:0000:0000:0000:0000:0001/16
// network range :
fec0:0000:0000:0000:0000:0000:0000:0000-
fec0:ffff:ffff:ffff:ffff:ffff:ffff:ffff
//---------

// IP Address (addr unicast globale "2001::" / addr unique locale "fc01::") -> VLAN_D1 (a1ff:00ff/96) :
fec0:cb1d:02d4:885e:eeee:0642:0000:0254/61
// network range :
fec0:cb1d:02d4:8858:0000:0000:0000:0000-
fec0:cb1d:02d4:885f:ffff:ffff:ffff:ffff

vmbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 135.125.133.51  netmask 255.255.255.0  broadcast 135.125.133.255
        inet6 fec0::1  prefixlen 16  scopeid 0x40<site>
        inet6 fe80::24b2:4ff:fea2:c384  prefixlen 64  scopeid 0x20<link>
        inet6 2001:41d0:701:1100::6530  prefixlen 128  scopeid 0x0<global>
        ether 26:b2:04:a2:c3:84  txqueuelen 1000  (Ethernet)
        RX packets 216146041  bytes 93608898294 (87.1 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 231937862  bytes 48252690945 (44.9 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

VMBR1 <-> VLAN/VSERVERs

//-----------------------
// VMBR1 <-> VLAN/VSERVERs
//---------

// IP Address (addr unicast globale "2001::" / addr unique locale "fc01::") -> VLAN_00 (0000:0000:0000:0000/64) :
fc00:41d0:701:1100::fffe/64
// network range :
fc00:41d0:701:1100:0000:0000:0000:0000-
fc00:41d0:701:1100:ffff:ffff:ffff:ffff

vmbr1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.133.0.254  netmask 255.255.255.0  broadcast 10.133.0.255
        inet6 fe80::7069:deff:fe53:4683  prefixlen 64  scopeid 0x20<link>
        inet6 fc00:41d0:701:1100::fffe  prefixlen 64  scopeid 0x0<global>
        ether 72:69:de:53:46:83  txqueuelen 1000  (Ethernet)
        RX packets 68448644  bytes 15499970989 (14.4 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 63449533  bytes 7999980401 (7.4 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

---

UK.LAB3W.VPS (Angleterre/Londres)

Ici c’est un VPS (1 seule IPv6 UNICAST GLOBAL).

VMBR0 <-> LAN/WAN

//-----------------------
// VMBR0 <-> LAN/WAN 
//---------

// IP Address (addr unicast globale "2001::/128" :
2001:41d0:801:2000::44f9/128

//---------
// IP Address (addr secure wide area) :
fec0:0000:0000:0000:0000:0000:0000:0243/16
// network range :
fec0:0000:0000:0000:0000:0000:0000:0000-
fec0:ffff:ffff:ffff:ffff:ffff:ffff:ffff
//---------

// IP Address (addr unicast globale "2001::" / addr unique locale "fc01::") -> VLAN_D1 (a1ff:00ff/96) :
fec0:cb1d:02d4:885e:eeee:0642:0000:0254/61
// network range :
fec0:cb1d:02d4:8858:0000:0000:0000:0000-
fec0:cb1d:02d4:885f:ffff:ffff:ffff:ffff

vmbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 57.128.171.43  netmask 255.255.255.0  broadcast 57.128.171.255
        inet6 fe80::a09c:91ff:fed5:d3d9  prefixlen 64  scopeid 0x20<link>
        inet6 fec1::243  prefixlen 128  scopeid 0x40<site>
        inet6 2001:41d0:801:2000::44f9  prefixlen 128  scopeid 0x0<global>
        ether a2:9c:91:d5:d3:d9  txqueuelen 1000  (Ethernet)
        RX packets 778091  bytes 177948788 (169.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 684303  bytes 250874892 (239.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

VMBR1 <-> VLAN/VSERVERs

//-----------------------
// VMBR1 <-> VLAN/VSERVERs
//---------

// IP Address (addr unicast globale "2001::" / addr unique locale "fc01::") -> VLAN_00 (0000:0000:0000:0000/64) :
fc00:41d0:801:2000::fffe/64
// network range :
fc00:41d0:801:2000:0000:0000:0000:0000-
fc00:41d0:801:2000:ffff:ffff:ffff:ffff

vmbr1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.171.43.254  netmask 255.255.255.0  broadcast 10.171.43.255
        inet6 fe80::40a9:16ff:fe94:6f1a  prefixlen 64  scopeid 0x20<link>
        inet6 fc00:41d0:801:2000::fffe  prefixlen 64  scopeid 0x0<global>
        ether 42:a9:16:94:6f:1a  txqueuelen 1000  (Ethernet)
        RX packets 24074  bytes 3246205 (3.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20868  bytes 64167857 (61.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

---

CA.LAB3W.SRV (Canada/Montreal)

Ici c’est un Dédié (1 bloc IPv6::/64 UNICAST GLOBAL).

//-----------------------
[...]
//-----------------------

---

Pour le plaisir et les nouveaux Êtres comme moi → ScienceEtonnante " L’Algorithme qui Sécurise Internet (entre autres…)"

David Louapre vous parle de l’étonnant algorithme de Diffie-Hellman, une méthode de cryptographie dont il a eu du mal à croire qu’elle puisse exister !

L'Algorithme qui Sécurise Internet (entre autres...)

[ZW3B]

La configuration réseau Fibre - IP❤6 - ULA (Unique Local Address) de chez moi jusqu’aux serveurs ; en image : Sympat, non…

Je « me » fais un récapitulatif de l’installation Post-quantum strongSwan v6 (vérifier si liboqs 0.9.2 et strongswan-6.0.0beta6 n’ont pas évolués) :

Installation

# Installation de la version non officielle StrongSwan qui utilise la librairie OQS (OpenQuantumSafe) des algorhitmes cryptographiques.
apt-get -y install iproute2 iputils-ping nano wget unzip bzip2 make gcc libssl-dev cmake ninja-build

mkdir /liboqs && \
  cd /liboqs && \
  wget https://github.com/open-quantum-safe/liboqs/archive/refs/tags/0.9.2.zip && \
  unzip 0.9.2.zip && \
  cd liboqs-0.9.2 && \
  mkdir build && cd build

cmake -GNinja -DOQS_USE_OPENSSL=ON -DBUILD_SHARED_LIBS=ON -DCMAKE_INSTALL_PREFIX=/usr \
                -DCMAKE_BUILD_TYPE=Release -DOQS_BUILD_ONLY_LIB=ON .. && ninja && ninja install

cd / && rm -R /liboqs

mkdir /strongswan-build && \
  cd /strongswan-build && \
  wget https://download.strongswan.org/strongswan-6.0.0beta6.tar.bz2 && \
  tar xfj strongswan-6.0.0beta6.tar.bz2 && \
  cd strongswan-6.0.0beta6

./configure --prefix=/usr --sysconfdir=/etc --with-systemdsystemunitdir=/lib/systemd/system --disable-ikev1 --disable-constraints --enable-openssl --enable-frodo --enable-oqs --enable-silent-rules --enable-eap-identity --enable-eap-md5 --enable-eap-mschapv2 --enable-eap-tls --enable-eap-ttls --enable-eap-peap --enable-eap-tnc --enable-eap-dynamic --enable-eap-radius --enable-xauth-eap  --enable-dhcp --enable-addrblock --enable-unity --enable-certexpire --enable-radattr 

make all && make install

# --
# Au cas où, vous avez une version strongSwan 5.XX qui cause de conflits avec la version compilée.
# dpkg -r strongswan-swanctl charon-systemd libcharon-extra-plugins strongswan-libcharon

# ./configure [...] --with-systemdsystemunitdir=/lib/systemd/system
# systemctl unmask strongXswan.service
# systemctl enable strongXswan.service
# systemctl restart strongXswan.service
# systemctl status strongXswan.service

---

Connexions (swanctl --load-conns)

Les connexions établies StrongSwan :

root@lab3w:/etc/swanctl # swanctl --list-sas
ca-fr: #8, ESTABLISHED, IKEv2, ad2daa13344fbeae_i 130c69bc0eb38f5b_r*
  local  'srv.ca.lab3w.com' @ 158.69.126.137[4500]
  remote 'srv.fr.lab3w.com' @ 109.210.56.240[4500] [fec1::1]
  AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519/KE1_KYBER_L3/KE2_BIKE_L3/KE3_HQC_L3/KE4_HQC_L5
  established 1698s ago, rekeying in 12654s
  ca-fr: #58, reqid 1, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-256/HMAC_SHA2_256_128/CURVE_25519/KE1_KYBER_L3/KE2_BIKE_L3/KE3_HQC_L3/KE4_HQC_L5
    installed 24s ago, rekeying in 138s, expires in 174s
    in  ca06e0ea,      0 bytes,     0 packets
    out c363d438,      0 bytes,     0 packets
    local  fc00:41d0:701:1100::/64 fc00:41d0:801:2000::/64 fc00:5300:60:9389::/64 fec0::/16 fec2::1/128 fec3::1/128
    remote fc01::10:106:0:0/104 fc01::10:126:42:0/112 fc01::172:16:0:0/104 fc01::192:168:0:0/104 fec1::/16

ca-uk: #12, ESTABLISHED, IKEv2, fbf8d917a028b5fa_i 27993e66b43d5756_r*
  local  'srv.ca.lab3w.com' @ 158.69.126.137[4500]
  remote 'vps.uk.ipv10.net' @ 57.128.171.43[4500] [fec2::1]
  AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519/KE1_KYBER_L3/KE2_BIKE_L3/KE3_HQC_L3/KE4_HQC_L5
  established 1000s ago, rekeying in 12747s
  ca-uk: #59, reqid 4, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA2_256_128/CURVE_25519/KE1_KYBER_L3/KE2_BIKE_L3/KE3_HQC_L3
    installed 3s ago, rekeying in 171s, expires in 195s
    in  c859d552,      0 bytes,     0 packets
    out cdfbc2ee,      0 bytes,     0 packets
    local  fc00:41d0:701:1100::/64 fc00:5300:60:9389::/64 fc01::10:106:0:0/104 fc01::10:126:42:0/112 fc01::172:16:0:0/104 fc01::192:168:0:0/104 fec0::/16 fec1::/16
    remote fc00:41d0:801:2000::/64 fec2::1/128

ca-de: #2, ESTABLISHED, IKEv2, ddc7ac4975d4e081_i 97ce2741655d20ea_r*
  local  'srv.ca.lab3w.com' @ 158.69.126.137[4500]
  remote 'vps.de.ipv10.net' @ 135.125.133.51[4500] [fec3::1]
  AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519/KE1_KYBER_L3/KE2_BIKE_L3/KE3_HQC_L3/KE4_HQC_L5
  established 2715s ago, rekeying in 10567s
  ca-de: #57, reqid 3, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA2_256_128/CURVE_25519/KE1_KYBER_L3/KE2_BIKE_L3/KE3_HQC_L3
    installed 69s ago, rekeying in 110s, expires in 129s
    in  c670c894,      0 bytes,     0 packets
    out c6945952,      0 bytes,     0 packets
    local  fc00:41d0:801:2000::/64 fc00:5300:60:9389::/64 fc01::10:106:0:0/104 fc01::10:126:42:0/112 fc01::172:16:0:0/104 fc01::192:168:0:0/104 fec0::/16 fec1::/16 fec2::1/128
    remote fc00:41d0:701:1100::/64 fec3::1/128

Credits (swanctl --load-creds)

Les autorités :

root@lab3w:/etc/swanctl # swanctl --list-authorities
strongswan:
  cacert: C=FR, O=LAB3W, CN=ZW3B Cyber Root CA : rsa_3072

Les certificats :

root@lab3w:/etc/swanctl # swanctl --list-certs

List of X.509 End Entity Certificates

  subject:  "C=FR, O=LAB3W, CN=srv.ca.lab3w.com"
  issuer:   "C=FR, O=LAB3W, CN=ZW3B Cyber Root CA : rsa_3072"
  validity:  not before Oct 30 07:24:39 2024, ok
             not after  Oct 30 07:24:39 2029, ok (expires in 1824 days)
  serial:    01
  altNames:  srv.ca.lab3w.com
  flags:
  authkeyId: 95:66:e0:e9:97:2d:7b:cb:ee:3d:7b:e3:95:5f:10:19:bc:6e:71:d5
  subjkeyId: 4e:f4:60:60:83:f5:53:a7:53:7d:4d:b8:9b:74:4b:d4:6c:35:d4:f6
  pubkey:    Falcon1024 14344 bits, has private key
  keyid:     28:78:34:78:37:e1:92:9f:91:e5:76:58:5f:e3:40:d8:23:03:aa:c9
  subjkey:   4e:f4:60:60:83:f5:53:a7:53:7d:4d:b8:9b:74:4b:d4:6c:35:d4:f6

  subject:  "C=FR, O=LAB3W, CN=srv.fr.lab3w.com"
  issuer:   "C=FR, O=LAB3W, CN=ZW3B Cyber Root CA : rsa_3072"
  validity:  not before Oct 30 06:48:28 2024, ok
             not after  Oct 30 06:48:28 2029, ok (expires in 1824 days)
  serial:    01
  altNames:  srv.fr.lab3w.com
  flags:
  authkeyId: 95:66:e0:e9:97:2d:7b:cb:ee:3d:7b:e3:95:5f:10:19:bc:6e:71:d5
  subjkeyId: 19:b5:62:8f:31:fc:27:a6:01:45:bc:d3:75:d4:be:07:7f:59:b8:aa
  pubkey:    Falcon1024 14344 bits, has private key
  keyid:     ce:3b:8e:ea:f0:bb:c9:2b:8b:18:7b:9c:f5:e9:24:6a:cf:fd:82:72
  subjkey:   19:b5:62:8f:31:fc:27:a6:01:45:bc:d3:75:d4:be:07:7f:59:b8:aa

  subject:  "C=FR, O=LAB3W, CN=vps.uk.ipv10.net"
  issuer:   "C=FR, O=LAB3W, CN=ZW3B Cyber Root CA : rsa_3072"
  validity:  not before Nov 01 02:51:21 2024, ok
             not after  Nov 01 02:51:21 2029, ok (expires in 1825 days)
  serial:    01
  altNames:  vps.uk.ipv10.net
  flags:
  authkeyId: 95:66:e0:e9:97:2d:7b:cb:ee:3d:7b:e3:95:5f:10:19:bc:6e:71:d5
  subjkeyId: 02:26:c7:d4:59:22:c5:51:64:6a:6e:95:6f:f0:ae:21:ea:8d:f9:1c
  pubkey:    Falcon1024 14344 bits, has private key
  keyid:     96:89:2f:cd:02:5c:80:1e:a6:dc:3e:42:f5:b0:76:15:62:30:c6:4a
  subjkey:   02:26:c7:d4:59:22:c5:51:64:6a:6e:95:6f:f0:ae:21:ea:8d:f9:1c

  subject:  "C=FR, O=LAB3W, CN=vps.de.ipv10.net"
  issuer:   "C=FR, O=LAB3W, CN=ZW3B Cyber Root CA : rsa_3072"
  validity:  not before Nov 01 03:29:17 2024, ok
             not after  Nov 01 03:29:17 2029, ok (expires in 1825 days)
  serial:    01
  altNames:  vps.de.ipv10.net
  flags:
  authkeyId: 95:66:e0:e9:97:2d:7b:cb:ee:3d:7b:e3:95:5f:10:19:bc:6e:71:d5
  subjkeyId: f3:07:2f:87:81:67:7d:66:b2:e7:7a:00:3f:87:70:69:c7:63:28:28
  pubkey:    Falcon1024 14344 bits, has private key
  keyid:     08:34:b3:1c:ca:71:b2:a4:24:69:e7:86:1c:b9:14:b1:bd:9d:63:7d
  subjkey:   f3:07:2f:87:81:67:7d:66:b2:e7:7a:00:3f:87:70:69:c7:63:28:28

List of X.509 CA Certificates

  subject:  "C=FR, O=LAB3W, CN=ZW3B Cyber Root CA : rsa_3072"
  issuer:   "C=FR, O=LAB3W, CN=ZW3B Cyber Root CA : rsa_3072"
  validity:  not before Oct 30 06:37:36 2024, ok
             not after  Oct 30 06:37:36 2034, ok (expires in 3650 days)
  serial:    11:f6:b6:9e:4f:22:12:bc
  flags:     CA CRLSign self-signed
  subjkeyId: 95:66:e0:e9:97:2d:7b:cb:ee:3d:7b:e3:95:5f:10:19:bc:6e:71:d5
  pubkey:    RSA 3072 bits, has private key
  keyid:     cf:4b:7c:c6:cc:38:ac:5b:77:5f:f2:e7:32:31:8c:0c:64:ab:0a:58
  subjkey:   95:66:e0:e9:97:2d:7b:cb:ee:3d:7b:e3:95:5f:10:19:bc:6e:71:d5

Files

Les fichiers sur le serveur :

root@lab3w:/etc/swanctl # tree
.
├── conf.d
│   ├── ca-de.conf
│   ├── ca-fr.conf
│   └── ca-uk.conf
├── ecdsa
├── pkcs12
├── pkcs8
├── private
│   ├── LAB3W_ZW3B-caKey-rsa_3072.pem
│   ├── srv.ca.lab3w.com-Key-falcon1024.pem
│   ├── srv.fr.lab3w.com-Key-falcon1024.pem
│   ├── vps.de.ipv10.net-Key-falcon1024.pem
│   └── vps.uk.ipv10.net-Key-falcon1024.pem
├── pubkey
├── rsa
├── swanctl.conf
├── tmp
│   ├── srv.ca.lab3w.com-Req.pem
│   ├── srv.fr.lab3w.com-Req.pem
│   ├── vps.de.ipv10.net-Req.pem
│   └── vps.uk.ipv10.net-Req.pem
├── x509
│   ├── srv.ca.lab3w.com-Cert-falcon1024-sign_ca-rsa_3072.pem
│   ├── srv.fr.lab3w.com-Cert-falcon1024-sign_ca-rsa_3072.pem
│   ├── vps.de.ipv10.net-Cert-falcon1024-sign_ca-rsa_3072.pem
│   └── vps.uk.ipv10.net-Cert-falcon1024-sign_ca-rsa_3072.pem
├── x509aa
├── x509ac
├── x509ca
│   └── LAB3W_ZW3B-caCert-rsa_3072.pem
├── x509crl
└── x509ocsp

14 directories, 18 files

Les fichiers sur un client :

root@pve:/etc/swanctl # tree
.
├── conf.d
│   └── fr-ca.conf
├── ecdsa
├── pkcs12
├── pkcs8
├── private
│   └── srv.fr.lab3w.com-Key-falcon1024.pem
├── pubkey
├── rsa
├── swanctl.conf
├── x509
│   └── srv.fr.lab3w.com-Cert-falcon1024-sign_ca-rsa_3072.pem
├── x509aa
├── x509ac
├── x509ca
│   └── LAB3W_ZW3B-caCert-rsa_3072.pem
├── x509crl
└── x509ocsp

14 directories, 5 files

---

Conf

La configuration sur le serveur :

Infos : File « /etc/strongswan.conf » par default.

root@lab3w:/etc/swanctl # vim /etc/strongswan.conf
charon {

        load_modular = yes
        plugins {
                include strongswan.d/charon/*.conf
        }

        start-scripts {
                creds = swanctl --load-creds
                conns = swanctl --load-conns
                pools = swanctl --load-pools
        }
        filelog {
                charon {
                        path = /var/log/charon.log
                        # add a timestamp prefix
                        time_format = %b %e %T
                        # prepend connection name, simplifies grepping
                        ike_name = yes
                        # overwrite existing files
                        append = no
                        # increase default loglevel for all daemon subsystems
                        default = 1
                        tls = 2
                        ike = 2
                        # flush each line to disk
                        flush_line = yes
                }

                # and two loggers using syslog
                syslog {
                        # prefix for each log message
                        identifier = charon-custom
                        # use default settings to log to the LOG_DAEMON facility
                        daemon {

                        }
                        # very minimalistic IKE auditing logs to LOG_AUTHPRIV
                        auth {
                                default = -1
                                ike = 0
                        }
                }
        }

        eap-dynamic {
                prefer_user = yes
                preferred = md5, tls
        }

        send_vendor_id = yes
        prefer_configured_proposals = no
        fragment_size = 1480
        max_packet = 30000
#       install_routes = no
#       install_virtual_ip = yes
#       install_virtual_ip_on = vti1
#       interfaces_use = vti0
#       interfaces_ignore = vmbr0
}
include strongswan.d/*.conf

pki {
#        load = plugins: random drbg x509 pubkey pkcs1 pkcs8 pkcs12 pem openssl oqs
}

# for strongSwan 5.9
libtls {
        version_max = 1.3
        suites = TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384
}

root@lab3w:/etc/swanctl # vim swanctl.conf

connections {
        include conf.d/ca-fr.conf
        include conf.d/ca-uk.conf
        include conf.d/ca-de.conf
}

authorities {
        strongswan {
                cacert = LAB3W_ZW3B-caCert-rsa_3072.pem
#               crl_uris = http://ip6-winnetou.strongswan.org/strongswan.crl
        }
}

pools {

        rw_pool {
                addrs = 172.16.1.100-172.16.1.200
        }

        fr-ipv6 {
                addrs = fec1::1/16
        }
        uk-ipv6 {
                addrs = fec2::1/128
        }
        de-ipv6 {
                addrs = fec3::1/128
        }

}

secrets {
        # PSK
        ike-my_pseudo {
                id = my_pseudo
                secret = 0sTdD7IOindSa6FuyjLsWtsdD9o/1a
        }
        # EAP
        eap-my_pseudo {
                id = my_pseudo@doman.tld
                secret = my_password
        }
}

root@lab3w:/etc/swanctl # vim conf.d/ca-fr.conf
ca-fr {
        remote_addrs = 109.210.56.240

        pools = fr-ipv6

        local {
                auth = pubkey
                certs = srv.ca.lab3w.com-Cert-falcon1024-sign_ca-rsa_3072.pem
                id = srv.ca.lab3w.com
        }
        remote {
                auth = pubkey
                id = srv.fr.lab3w.com
        }
        children {
                ca-fr {
#                       mode = transport

                        local_ts = fec0::1/16, fc00:5300:60:9389::/64, fec2::1/128, fc00:41d0:801:2000::/64, fec3::1/128, fc00:41d0:701:1100::/64

                        remote_ts = fec1::1/16, fc01::10:106:42:0/104, fc01::10:126:42:0/112, fc01::172:16:0:0/104, fc01::192:168:8:0/104

                        start_action = trap

                        #-----
                        # ESP

                        # DEFAUT : no cipher
                        # selected proposal: ESP:AES_GCM_16_128/NO_EXT_SEQ

                        # ok
                        esp_proposals = aes256-sha256-x25519-ke1_kyber3-ke2_bike3-ke3_hqc3-ke3_none-ke4_hqc5-ke4_none

                        #-----

#                        rekey_time = 5400 # 90min default
                        rekey_time = 180 # 3min
                        rekey_bytes = 500000000
                        rekey_packets = 1000000

                }
        }

        #-----
        # IKE

        version = 2
        dpd_delay = 60s

        # DEFAULT : no cipher config
        # selected proposal: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256

        # ok
        proposals = aes256-sha256-x25519-ke1_kyber3-ke1_frodoa3-ke2_bike3-ke2_hqc3-ke3_hqc3-ke3_none-ke4_hqc5-ke4_none
        # selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519/KE1_KYBER_L3/KE2_BIKE_L3/KE3_HQC_L3/KE4_HQC_L5

        #-----

}

La configuration sur un client (le fichier /etc/strongswan.conf ne change pas) :

root@pve:/etc/swanctl # vim swanctl.conf
connections {

        include conf.d/fr-ca.conf
}

authorities {
        strongswan {
                cacert = LAB3W_ZW3B-caCert-rsa_3072.pem
#               crl_uris = http://ip6-winnetou.strongswan.org/strongswan.crl
        }
}

pools {

}
secrets {

}

# Include config snippets
include conf.d/*.conf

root@pve:/etc/swanctl # vim conf.d/fr-ca.conf
fr-ca {
        remote_addrs = 158.69.126.137

        local {
                auth = pubkey
                certs = srv.fr.lab3w.com-Cert-falcon1024-sign_ca-rsa_3072.pem
                id = srv.fr.lab3w.com
        }
        remote {
                auth = pubkey
                id = srv.ca.lab3w.com
        }
        children {
                 fr-ca {
#                       mode = transport

                        local_ts  = fec1::1/16, fc01::172:16:0:0/104, fc01::10:106:42:0/104, fc01::10:126:42:0/112, fc01::192:168:8:0/104

                        remote_ts = fec0::1/16, fc00:5300:60:9389::/64, fec2::1/128, fc00:41d0:801:2000::/64, fec3::1/128, fc00:41d0:701:1100::/64

                        #-----
                        start_action = trap

                        #-----
                        # ESP

                        # DEFAUT : no cipher
                        # selected proposal: ESP:AES_GCM_16_128/NO_EXT_SEQ

                        # ok
                        esp_proposals = aes256-sha256-x25519-ke1_kyber3-ke2_bike3-ke3_hqc3-ke3_none-ke4_hqc5-ke4_none
                        # selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
                        #-----

#                        rekey_time = 5400 # 90min default
#                        rekey_bytes = 500000000
#                        rekey_packets = 1000000
                }
        }

        #-----
        # IKE

        version = 2
        dpd_delay = 60s

        # DEFAULT : no cipher config
        # selected proposal: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256

        # ok 
        proposals = aes256-sha256-x25519-ke1_kyber3-ke1_frodoa3-ke2_bike3-ke2_hqc3-ke3_hqc3-ke3_none-ke4_hqc5-ke4_none
        # selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519/KE1_KYBER_L3/KE2_BIKE_L3/KE3_HQC_L3/KE4_HQC_L5

        #-----

}

Voilà la configuration est prête.

Ci-dessous la création des certificats SSL :

# Creation de clefs de l'autorité de certificats
pki --gen --type rsa --size 3072 --outform pem > /etc/swanctl/private/LAB3W_ZW3B-caKey-rsa_3072.pem

# Création des certificats de l'autorité  (certificat auto-signé)
pki --self --ca --type rsa --in /etc/swanctl/private/LAB3W_ZW3B-caKey-rsa_3072.pem --lifetime 3652 --dn "C=FR, O=LAB3W, CN=ZW3B Cyber Root CA : rsa_3072" --outform pem > /etc/swanctl/x509ca/LAB3W_ZW3B-caCert-rsa_3072.pem

En passant pour installer votre autorité sur votre machine Windows il faut ce type de fichier (par exemple « LAB3W_ZW3B-caCert-rsa_3072.der ») ;

# Fichier de l'autorité au format Windows (pour pouvoir l'importer)
openssl x509 -in /etc/swanctl/x509ca/LAB3W_ZW3B-caCert-rsa_3072.pem -out /etc/swanctl/x509ca/LAB3W_ZW3B-caCert-rsa_3072.der -outform DER

Serveur CA (srv.ca.lab3w.com) debian 10 (buster) pq-strongswan 6.0

# falcon1024
pki --gen --type falcon1024 --outform pem > /etc/swanctl/private/srv.ca.lab3w.com-Key-falcon1024.pem

pki --req --type priv --in /etc/swanctl/private/srv.ca.lab3w.com-Key-falcon1024.pem \
          --dn "C=FR, O=LAB3W, CN=srv.ca.lab3w.com" \
          --san srv.ca.lab3w.com --outform pem > /etc/swanctl/tmp/srv.ca.lab3w.com-Req.pem

# Signature rsa_3072
pki --issue --cacert /etc/swanctl/x509ca/LAB3W_ZW3B-caCert-rsa_3072.pem --cakey /etc/swanctl/private/LAB3W_ZW3B-caKey-rsa_3072.pem \
            --type pkcs10 --in /etc/swanctl/tmp/srv.ca.lab3w.com-Req.pem --serial 01 --lifetime 1826 \
            --outform pem > /etc/swanctl/x509/srv.ca.lab3w.com-Cert-falcon1024-sign_ca-rsa_3072.pem

Serveur FR (srv.fr.lab3w.com) debian 12 (bookworm) pq-strongswan 6.0

# falcon1024
pki --gen --type falcon1024 --outform pem > /etc/swanctl/private/srv.fr.lab3w.com-Key-falcon1024.pem
pki --req --type priv --in /etc/swanctl/private/srv.fr.lab3w.com-Key-falcon1024.pem \
          --dn "C=FR, O=LAB3W, CN=srv.fr.lab3w.com" \
          --san srv.fr.lab3w.com --outform pem > /etc/swanctl/tmp/srv.fr.lab3w.com-Req.pem

# Signature rsa_3072
pki --issue --cacert /etc/swanctl/x509ca/LAB3W_ZW3B-caCert-rsa_3072.pem --cakey /etc/swanctl/private/LAB3W_ZW3B-caKey-rsa_3072.pem \
            --type pkcs10 --in /etc/swanctl/tmp/srv.fr.lab3w.com-Req.pem --serial 01 --lifetime 1826 \
            --outform pem > /etc/swanctl/x509/srv.fr.lab3w.com-Cert-falcon1024-sign_ca-rsa_3072.pem

---

Et voilà, on peut lancer notre connexion :

root@lab3w:/etc/swanctl # swanctl --initiate --child ca-fr

Pour terminer une connexion :

root@lab3w:/etc/swanctl # swanctl --terminate --ike ca-fr

---

Avec çà, on a une connexion fonctionnelle « basique » de serveur à serveur VPN utilisant StrongSwan v6 (docs).

StrongSwan permet d’autres types d’authentifications comme l’Extensible Authentication Protocol (EAP) que je n’ai pas testé, pour les réseaux mobiles, Wi-Fi et filaires pour ajouter une méthode d’authentification suplémentaire comme MD5, OTP (One-Time Passwords), Generic Token Card, SIM, etc.) comme par exemple pour les systèmes Microsoft et Cisco.

@+

Romain.

---

Voir un certificat avec la commande PKI :

pki --print --type x509 --in /etc/swanctl/x509/srv.fr.lab3w.com-Cert-falcon1024-sign_ca-rsa_3072.pem

Voir un certificat avec la commande OpenSSL :

openssl x509 -in /etc/swanctl/x509/srv.fr.lab3w.com-Cert-falcon1024-sign_ca-rsa_3072.pem -noout -text -inform pem

---

Les traceroutes :

C:\Users\ORJ>tracert fc00:41d0:801:2000::1

Détermination de l’itinéraire vers fc00:41d0:801:2000::1 avec un maximum de 30 sauts.

  1    <1 ms    <1 ms    <1 ms  fc01::172:16:0:254
  2    97 ms    97 ms    97 ms  fec0::1
  3   175 ms   175 ms   175 ms  fec2::1
  4   174 ms   175 ms   174 ms  fc00:41d0:801:2000::1

Itinéraire déterminé.

C:\Users\ORJ>tracert fc00:41d0:701:1100::1

Détermination de l’itinéraire vers fc00:41d0:701:1100::1 avec un maximum de 30 sauts.

  1    <1 ms    <1 ms    <1 ms  fc01::172:16:0:254
  2    97 ms    97 ms    96 ms  fec0::1
  3   190 ms   190 ms   190 ms  fec3::1
  4   189 ms   189 ms   189 ms  fc00:41d0:701:1100::1

Itinéraire déterminé.

C:\Users\ORJ>tracert fc00:5300:60:9389:15:1:a:10

Détermination de l’itinéraire vers fc00:5300:60:9389:15:1:a:10 avec un maximum de 30 sauts.

  1    <1 ms    <1 ms    <1 ms  fc01::172:16:0:254
  2    97 ms    96 ms    96 ms  fec0::1
  3    97 ms    96 ms    97 ms  fc00:5300:60:9389:15:1:0:1
  4    97 ms     *       96 ms  fc00:5300:60:9389:15:1:a:10

Itinéraire déterminé.

C:\Users\ORJ>tracert fc00:5300:60:9389:15:2:a:10

Détermination de l’itinéraire vers fc00:5300:60:9389:15:2:a:10 avec un maximum de 30 sauts.

  1    <1 ms    <1 ms    <1 ms  fc01::172:16:0:254
  2    97 ms    96 ms    97 ms  fec0::1
  3    96 ms    97 ms    97 ms  fc00:5300:60:9389:15:2:0:1
  4    96 ms    96 ms    97 ms  fc00:5300:60:9389:15:2:a:10

Itinéraire déterminé.

root@lb2.ww2:~ # traceroute fc01::10:106:42:10 -I
traceroute to fc01::10:106:42:10 (fc01::10:106:42:10), 30 hops max, 80 byte packets
 1  fc00:5300:60:9389:15:2:a:ffff (fc00:5300:60:9389:15:2:a:ffff)  0.052 ms  0.016 ms  0.013 ms
 2  fc00:5300:60:9389:15:2:0:f (fc00:5300:60:9389:15:2:0:f)  0.165 ms  0.143 ms  0.128 ms
 3  fec1::1 (fec1::1)  97.483 ms  97.476 ms  97.536 ms
 4  * * *
 5  fc01::10:106:42:10 (fc01::10:106:42:10)  97.534 ms * *

root@lb2.ww2:~ # traceroute fc00:41d0:801:2000::1
traceroute to fc00:41d0:801:2000::1 (fc00:41d0:801:2000::1), 30 hops max, 80 byte packets
 1  fc00:5300:60:9389:15:2:a:ffff (fc00:5300:60:9389:15:2:a:ffff)  0.616 ms  0.539 ms  0.500 ms
 2  fc00:5300:60:9389:15:2:0:f (fc00:5300:60:9389:15:2:0:f)  0.466 ms  0.428 ms  0.397 ms
 3  fec2::1 (fec2::1)  78.224 ms  78.205 ms  78.166 ms
 4  fc00:41d0:801:2000::1 (fc00:41d0:801:2000::1)  78.156 ms  78.172 ms  78.160 ms

root@lb2.ww2:~ # traceroute fc00:41d0:701:1100::1
traceroute to fc00:41d0:701:1100::1 (fc00:41d0:701:1100::1), 30 hops max, 80 byte packets
 1  fc00:5300:60:9389:15:2:a:ffff (fc00:5300:60:9389:15:2:a:ffff)  0.052 ms  0.017 ms  0.016 ms
 2  fc00:5300:60:9389:15:2:0:f (fc00:5300:60:9389:15:2:0:f)  0.117 ms  0.081 ms  0.070 ms
 3  fec3::1 (fec3::1)  92.857 ms  92.880 ms  92.931 ms
 4  fc00:41d0:701:1100::1 (fc00:41d0:701:1100::1)  92.946 ms  92.985 ms  92.959 ms

---

Netfilter

Je vous ajoute ces fonctions ip6tables.

IPv6 ULA : Unique Local Address (IPv4 : 10.0.0.0/8, 192.168.0.0/16, 172.16-32.0.0/12)
IPv6 GUA : Global Unique Address (IPv4 publique Internet)

Je vous ajoute ces fonctions que j’ai créais pour mon pare-feu Linux - correspondante aux addresses « ULA » et autres.

/!\ ttention, on laisse passer les requêtes locales, on adapte après, c’est pour la compréhension de ce type d’adresse.

Exemple :

#####
# we set the rules for local IPv6 addresses
#####

function ipv6_ula()
{
        echo "   |";
        echo "   + IPv6 - Addrs Unique Locale Area -----------------------";

        # Allow Link-Local addresses
        # network range : fc00:0000:0000:0000:0000:0000:0000:0000-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

        echo "   |\\\\";
        $IP6TABLE -A INPUT -s fc00::/7 -j ACCEPT
        $IP6TABLE -A FORWARD -s fc00::/7 -d fc00::/7 -j ACCEPT
        $IP6TABLE -A OUTPUT -d fc00::/7 -j ACCEPT
        echo "   | +--> "fc00::/7 : ACCEPT;
        echo "   | |";
        echo "   |" + IPv6 - Addrs Unique Locale Area : [OK]

}

function ipv6_multicast()
{
        echo "   |";
        echo "   + IPv6 - Addrs Multicast -----------------------";

        # Allow multicast
        # network range : ff00:0000:0000:0000:0000:0000:0000:0000-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

        echo "   |\\\\";
        $IP6TABLE -A INPUT -d ff00::/8 -j ACCEPT
        $IP6TABLE -A FORWARD -s ff00::/8 -d ff00::/8 -j ACCEPT
        $IP6TABLE -A OUTPUT -d ff00::/8 -j ACCEPT
        echo "   | +--> "ff00::/8 : ACCEPT;
        echo "   | |";
        echo "   |" + IPv6 - Addrs Multicast : [OK]
}

function ipv6_link_local()
{
        echo "   |";
        echo "   + IPv6 - Addrs Link-Local Unicast -----------------------";

        # Allow Link-Local addresses
        # network range : fe80:0000:0000:0000:0000:0000:0000:0000-febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff

        echo "   |\\\\";
        $IP6TABLE -A INPUT -s fe80::/10 -j ACCEPT
        $IP6TABLE -A FORWARD -s fe80::/10 -d fe80::/10 -j ACCEPT
        $IP6TABLE -A OUTPUT -d fe80::/10 -j ACCEPT
        echo "   | +--> "fe80::/10 : ACCEPT;
        echo "   | |";
        echo "   | "+ IPv6 - Addrs Link-Local : [OK]

}

#####
# we set the rules for secure local IPv6 addresses (VPN/strongSwan)
#####

function ipv6_strongswan()
{
        # Default ------------------
        echo "   |";
        echo "   + IPv6 - Addrs Site-Local Secure Area Network -------------------------";

        # Allow  Secure Area Network addresses
        # network range : fec0:0000:0000:0000:0000:0000:0000:0000-feff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

        echo "   |\\\\";
        $IP6TABLE -A INPUT -s fec0::/10 -j ACCEPT
        $IP6TABLE -A FORWARD -s fec0::/10 -d fec0::/10 -j ACCEPT
        $IP6TABLE -A OUTPUT -d fec0::/10 -j ACCEPT
        echo "   | +--> "fec0::/10 : ACCEPT;
        echo "   | |";
        echo "   | "+ IPv6 - Addrs Secure Area Network : [OK]

        # Add ------------------

        echo "   |";
        # Allow  Forwarding SLAN (fec0::/10) <> ULA (fc00::/7)
        # network range : fc00:0000:0000:0000:0000:0000:0000:0000-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

        echo "   + IPv6 - Forwarding Addrs SWAN 2 ULA Networks -------------------------";
        echo "   |\\\\";
        $IP6TABLE -A FORWARD -s fec0::/10 -d fc00::/7 -j ACCEPT
        $IP6TABLE -A FORWARD -d fec0::/10 -s fc00::/7 -j ACCEPT
        echo "   | +--> fec0::/10 <?> fc00::/7 : ACCEPT";
        echo "   | |";
        echo "   | "+ IPv6 - Forwarding Addrs SWAN 2 ULA Networks : [OK]
        echo "   |";

}

function nat_v6()
{
        WAN_IF="bridge0"
        CT_WEB="fc01::192:168:10:100/128"

        # NET FOR LXC EXCEPT TO THE ULA (fc00::/7) NETWORK
        $IP6TABLE -t nat -A POSTROUTING -o $WAN_IF -s $CT_WEB ! -d fc00::/7 -j MASQUERADE

        echo "   "+ NAT : [OK]
} 

Preferred lifetime

Je vous ajoute en plus, la préférence de Vie d'une adresse IPv6.

si un « container » (ou une machine du réseau local) a une adresse IPv6 ULA (avec passerelle ULA) et une GUA, on peut fixer la préférence de vie sur la GUA à 0 seconde, comme si elle était obsolète. Cà permet de pouvoir rentrer sur la GUA (malgré tou) mais de pourvoir attraper le(s) local(s) en utilisant l’adresse ULA (je n’ai pas trouvé comment-faire dans windows).

• preferred_lft forever → preferred_lft 0sec – deprecated (obsolète)

$ ip -6 address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2a01:cb1d:12:1c00:1ab3:126:42:dc0/112 scope global deprecated
       valid_lft forever preferred_lft 0sec
    inet6 fc01::10:126:42:dc0/112 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fef3:56b/64 scope link
       valid_lft forever preferred_lft forever

$ ip -6 address add 2a01:cb1d:12:1c00:1ab3:126:42:dc0/112 dev eth0
$ ip -6 address change 2a01:cb1d:12:1c00:1ab3:126:42:dc0/112 dev eth0 prefer 0

Neighbor proxy

Je vous ajoute cela aussi, les adresses voisines proxy-fiante de l'IPv6 GUA.

Quand on a un bloc GUA IPv6::/64 (par exemple) et plusieurs sous-réseaux, pour qu’on puisse accèder à une adresse GUA (d’un sous réseau) il faut ajouter l’adresse IPv6 comme étant une adresse voisine proxifiante.

Par exemple notre serveur principal à 2 cartes ethernet – eth0 et eth1 – sur eth0 (2a01:cb1d:12:1c00::1) on a LA connectivité Internet et sur eth1 on distribue un autre réseau pour des machines locales. Sur eth1 on a une machine, disons la GUA 2a01:cb1d:12:1c00:beef:0000:0000:0001.

Déjà vérifier que la configuration IPv6 est correcte :

Sur la carte eth0 (-r lire et -w écrire):

sysctl -r net.ipv6.conf.eth0.forwarding = 1
sysctl -r net.ipv6.conf.eth0.accept_ra = 2
sysctl -r net.ipv6.conf.eth0.proxy_ndp = 1

Sur la carte eth1 :

sysctl -r net.ipv6.conf.eth1.forwarding = 1
sysctl -r net.ipv6.conf.eth1.accept_ra = 2
sysctl -r net.ipv6.conf.eth1.proxy_ndp = 1

Donc, sur le routeur il faut déclarer une machine comme voisine à la carte ayant la connectivité Internet pour qu’on puisse y accèder de l’exterieur (internet).

root@routeur:~ #  ip -6 neighbor show proxy
2a01:cb1d:12:1c00:beef::1 dev eth0 proxy 

Exemple :

root@routeur:~ # ip -6 neighbor delete proxy 2a01:cb1d:12:1c00:beef::1 dev eth0 
root@routeur:~ # ip -6 neighbor show proxy

Test depuis l’extérieur :

root@machine_externe:~ # ssh -6 2a01:cb1d:12:1c00:beef::1
ssh: connect to host 2a01:cb1d:12:1c00:beef::1 port 22: No route to host

root@routeur:~ # ip -6 neighbor add proxy 2a01:cb1d:12:1c00:beef::1 dev eth0

root@machine_externe:~ # ssh -6 2a01:cb1d:12:1c00:beef::1
root@2a01:cb1d:12:1c00:beef::1’s password: OKKK

---

Ciao. Bonne journée à tous !

Romain.

[ZW3B]

J’ajoute ce commentaire (qui est lié par la librairie OQS et donc la sécurité « plus sûre » sur les connexions HTTPS) :

Open Quantum Safe
Logiciel open source pour le prototypage de cryptographie résistante aux attaques quantiques.

Objectif de Test Open Quantum Safe

Ce serveur est une instance NGINX améliorée avec prise en charge de la cryptographie quantique sécurisée (QSC) à l’aide de packages logiciels fournis par le projet Open Quantum Safe (OQS).

Afin de fournir aux clients un moyen de tester l’interopérabilité avec ce logiciel amélioré par QSC et les algorithmes QSC qu’il contient, il dispose de ports distincts pour toutes les combinaisons d’algorithmes d’échange de signatures/clés QSC prises en charge par la distribution OQS actuelle.

Certificats de Test Open Quantum Safe

Chaque port de test fournit une authentification du serveur TLS à l’aide d’un certificat de serveur généré à l’aide de l’algorithme de signature QSC répertorié. Tous les certificats de serveur sont signés par un certificat d’autorité de certification commun utilisant la cryptographie conventionnelle (RSA).

Bonne continuation.

@+

[Zargos]

Bonjour,

Pas mal
Au passage MD5 est une méthode d’authentification qu’il ne veut mieux pas utiliser désormais autant que possible. C’est un algorithme faible et très largement dépassé de fait de sa fonction de hachage faible vulnérable aux attaques par dictionnaire et ne supporte pas les clefs wep dynamiques.
Le meilleur protocole à mon sens c’est le PEAP…

.

[ZW3B]

Oui @Zargos, bonjour.

Au passage, j’explique rapidement, j’ai pour l’instant créé une AC (PKI) en RSA_3072 et des certificats pour mes Linux en Falcon1024 puisque j’ai compilé strongSwan avec « liboqs ». Par contre sur Windows 11 et/ou Android, il faut des certificats SSL/TL conventionnels (ainsi que ; signé par une autorité avec un algorithme conventionnel) puisque il ne sont pas encore « acceptés » sur ces OS.

Il faut que je fasse un type de connexion « ikev2-eap-tls » et que j’arrive à me connecter depuis un smartphone.

Une connexion type :

ikev2-eap-tls-asymmetric {
       [...]
        local-1 {
            certs = mycert.pem
            id = myid
        }
        remote-1 {
            auth = eap-tls
            # go ask the client for its eap identity.
            eap_id = %any
        }
       [...]
}

Cf : Usable Examples configurations - strongSwan

J’essaie et je reviens par ici.

Note de Moi-même 20241105 :

J’ai créé un certificat pksc12 pour mon smartphone mais çà ne fonctionne pas… je cherche commen réussir à m’authentifier.

charon: 12[CFG] selected peer config 'ikev2-eap-tls-asymmetric'
charon: 12[IKE] loading EAP_TLS method failed

ls -l /usr/lib/ipsec/plugins/libstrongswan-eap-identity.so
ls: impossible d'accéder à '/usr/lib/ipsec/plugins/libstrongswan-eap-identity.so': Aucun fichier ou dossier de ce type

Il faut compiler avec ces options…

./configure [...] --enable-eap-identity --enable-eap-mschapv2

OK ! C’est bon, j’ai modifié le commentaire avec l’installation de strongSwan v6 Post Quantum.

ls -l /usr/lib/ipsec/plugins/libstrongswan-eap-identity.so
-rwxr-xr-x 1 root root 180872 nov.   5 15:16 /usr/lib/ipsec/plugins/libstrongswan-eap-identity.so

---

J’ai modifié la conf du fichier /etc/strongswan.conf, et les modules se chargent bien.

00[DMN] Starting IKE charon daemon (strongSwan 6.0.0beta6, Linux 5.4.203-1-pve, x86_64)
00[LIB] loaded plugins: charon random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pgp dnskey sshkey pem openssl pkcs8 xcbc cmac kdf frodo oqs drbg attr kernel-netlink resolve socket-default vici updown eap-identity eap-mschapv2

---

Pour infos dans Windows (RienÀVoir) :

Windows 11 : Accéder aux Networks : Touches Windows + r → ncpa.cpl
Windows 11 : Accéder au Gestionnaire des certificats : Touches Windows + r → Certmgr.msc

• Falcon1024 to Falcon1024 → Algorithme de signature : 1.3.9999.3.4 (Falcon1024) - Clef Publique : 1.3.9999.3.4 (0 bits) devrait retourner 14344 bits.
• Dilitium5 : 1.3.6.1.4.1.2.267.7.8.7
  → certificats-in-windows11.txt

J’ai vu des certificats de plus de 30 000 bits, mais je ne sais plus en quel algorithme et en plus je ne sais pas si cela est important - Parcequ’il y a des certificats de 15360bits mais qui sont en TLS 1.2 alors que d’autres de 3072 bits sont de sécurité TLS 1.3

Pour informations complémentaires liés aux certificats SSL/TLS conventionnels.

TLS 1.3

• TLS_AES_256_GCM_SHA384 (0x1302) – ECDH x25519 (eq 3072 bits RSA) FS
• TLS_AES_128_GCM_SHA256 (0x1301) – ECDH x25519 (eq 3072 bits RSA) FS
• TLS_CHACHA20_POLY1305_SHA256 (0x1303) – ECDH x25519 (eq 3072 bits RSA) FS

TLS 1.2

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA284 (0xc02c) – ECDH x25519 (eq 3072 bits RSA) FS
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) – ECDH x25519 (eq 3072 bits RSA) FS
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9) – ECDH x25519 (eq 3072 bits RSA) FS
  –
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA284 (0xc02c) – ECDH secp521r1 (eq 15360 bits RSA) FS
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) – ECDH secp521r1 (eq 15360 bits RSA) FS
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9) – ECDH secp521r1 (eq 15360 bits RSA) FS

---

My SSLLabs Reports :

---

@+

Bonne journée à tous.

Romain.

[ZW3B]

Bonjour, j’essaie donc de me connecter avec mon smartphone (pour l’instant je n’y arrive pas).

Voilà ce que j’ai fais :

Le fichier de configuration « conf.d/ikev2-eap-tls-asymmetric.conf » :

ikev2-eap-tls-asymmetric {
        pools = rw_pool, rw_pool-v6

        send_cert = always

        rekey_time = 0s
        fragmentation = yes
#       dpd_delay = 30s

        local {
                auth = pubkey
#               certs = srv.ca.lab3w.com-Cert-falcon1024-sign_ca-rsa_3072.pem
                certs = srv.ca.lab3w.com-Cert-rsa_3072-sign_ca-rsa_3072.pem
                id = srv.ca.lab3w.com
        }
        remote {
#               auth = eap-dynamic
#               auth = eap-mschapv2
                auth = eap-tls
                eap_id = %any
        }
        children {
                ikev2-eap-tls-asymmetric {
                        local_ts = 0.0.0.0/0,::/0

                        esp_proposals = default

                        rekey_time = 0s
                        dpd_action = clear
                        start_action = none
                        close_action = none
                }
        }
        version = 2

        # IKE
        proposals = default

}

J’ai créé un certificat personnel « pksc12 » pour Windows et/ou Android :

root@lab3w:/etc/swanctl # pki --gen --type rsa --size 3072 --outform pem > private/orj-Key-rsa_3072.pem
root@lab3w:/etc/swanctl # pki --req --type priv --in private/orj-Key-rsa_3072.pem \
          --dn "C=FR, O=LAB3W, CN=orj@lab3w.fr" \
          --san orj@lab3w.fr --san orj@lab3w.com --outform pem > tmp/orj-Req.pem

root@lab3w:/etc/swanctl # pki --issue --cacert x509ca/LAB3W_ZW3B-caCert-rsa_3072.pem --cakey private/LAB3W_ZW3B-caKey-rsa_3072.pem \
            --type pkcs10 --in tmp/orj-Req.pem --serial 01 --lifetime 1826 \
            --outform pem > x509/orj-Cert-rsa_3072-sign_ca-rsa_3072.pem

root@lab3w:/etc/swanctl # openssl pkcs12 -export -inkey private/orj-Key-rsa_3072.pem \
               -in x509/orj-Cert-rsa_3072-sign_ca-rsa_3072.pem -name "O.Romain.Jaillet-ramey" \
               -certfile x509ca/LAB3W_ZW3B-caCert-rsa_3072.pem -caname "ZW3B Cyber Root CA : rsa_3072" \
               -out pkcs12/orj-Cert-rsa_3072-sign_ca-rsa_3072.p12

J’ai récupéré le fichier « orj-Cert-rsa_3072-sign_ca-rsa_3072.p12 » et je l’ai installé sur mon smartphone et j’ai testé la connexion (en passant je l’ai viré du répertoire « pksc12/ », ce certificat n’a pas besoin d’être là, mais j’ai une erreur d’authentification.

Je cherche d’où peut venir l’erreur.

J’ai installé l’appli « strongSwan VPN Client » puisque cela ne fonctionnait pas depuis l’interface native de mon smartphone (j’ai les logs clientes avec, c’est mieux), mais çà ne fonctionne pas non plus.

Normalement sans « application cliente » cela doit fonctionner avec les options VPN native de nos appareils.

Quelqu’un connaîtrait ce genre d’authentification depuis un smartphone ?

Merci.

Romain.

[ZW3B]

Salut,

J’ai réussis à me connecter depuis mon smartphone depuis « strongSwan VPN CLient for Android »

Connexion type : IKEv2 EAP-MSCHAPv2 (username/Password) → OK Connected

Le fichier de configuration :

ikev2-eap-mschapv2 {
        version = 2

        pools = rw_pool, rw_pool-v6

        send_cert = always

        rekey_time = 0s
        fragmentation = yes
        dpd_delay = 30s

        # IKE ciphers
        proposals = default

        local {
                auth = pubkey
#               certs = srv.ca.lab3w.com-Cert-falcon1024-sign_ca-rsa_3072.pem
                certs = srv.ca.lab3w.com-Cert-rsa_3072-sign_ca-rsa_3072.pem
                id = srv.ca.lab3w.com
        }
        remote {
                auth = eap-mschapv2
                eap_id = %any
        }
        children {
                ikev2-eap-mschapv2 {
                        local_ts = 0.0.0.0/0,::/0

                        esp_proposals = default

                        rekey_time = 0s
                        dpd_action = clear
                        start_action = none
                        close_action = none
                }
        }
}

J’essaie d’autres mode de connexion plus sûr (pour l’instant je ne trouve pas AUTH_FAILED)

Je met la configuration par ici (strongSwan-config-EAP-XXX+LOGs-strongswanClientAndroid.txt)… (par contre je n’ai pas configurer les routes pour sortir - y’a une option dans advanced du client…)

J’ai modifié la commande pour l’installation ./Configure plus haut.

# strongSwan will be built with the following plugins
# -----------------------------------------------------
# libstrongswan: random nonce x509 revocation pubkey pkcs1 pkcs7 pgp dnskey sshkey pem openssl pkcs8 xcbc cmac kdf frodo oqs drbg
# libcharon:     attr kernel-libipsec kernel-netlink resolve socket-default vici updown eap-identity eap-md5 eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth-eap dhcp certexpire radattr addrblock unity
# libtnccs:      tnc-tnccs
# libtpmtss:

Nov  6 16:57:09 00[DMN] Starting IKE charon daemon (strongSwan 6.0.0beta6, Linux 5.4.203-1-pve, x86_64)
Nov  6 16:57:09 00[CFG] install DNS servers in '/etc/resolv.conf'
Nov  6 16:57:09 00[KNL] unable to create IPv4 routing table rule
Nov  6 16:57:09 00[KNL] unable to create IPv6 routing table rule
Nov  6 16:57:09 00[CFG] loaded 0 RADIUS server configurations
Nov  6 16:57:09 00[LIB] loaded plugins: charon random nonce x509 revocation pubkey pkcs1 pkcs7 pgp dnskey sshkey pem openssl pkcs8 xcbc cmac kdf frodo oqs drbg attr kernel-netlink resolve socket-default vici updown eap-identity eap-md5 eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth-eap tnc-tnccs dhcp certexpire radattr addrblock unity

Bonne journée.

[ZW3B]

Salut,

Pour « analyse » de l’adressage IP dans strongSwan :

Adressage « automatique » des clients en IPv4 d’adresses entre « 100 » et « 110 » → OK :

addrs = 172.16.8.100-172.16.8.110

Comment peut-on ajouter en plus un masque (longueur de préfixe) ?

• IPv4 : Longueur de « /16 » sur le réseau type de CLASS_B (17.16.0.0/12) (pour n’avoir accés qu’au réseau 172.16.XXX.XXX)

Adressage « automatique » des clients en IPv6 d’adresses (256 IP) IPv6::/120 → KO :

addrs = fec0::eeee:1ab3:00ca:fe.ff-fec0::eeee:1ab3:00ca:fe.00

Erreur

Comment peut-on ajouter en plus un masque (longueur de préfixe) ?

• IPv6 : Longueur de « /104 » pour faire partit du réseau fec0::eeee:1ab3:00ca:0000/104

Et aussi, comment-faire pour attribuer plusieurs adresses IP (par exemple, pour les DNS, chaque DNS est espacé par une virgule)

dns = fc00::15:2:a:1000, 2001:4860:4860::8844

Il faudrait que l’on puisse simplement écrire : « sur le bloc /120 dans le réseau /104 » :

Pour l’IPv6 çà donnerait :

addrs = fec0::eeee:1ab3:00ca:fe.ff-fec0::eeee:1ab3:00ca:fe.00/104

Pour l’IPv4 çà donnerait :

addrs = 172.16.8.100-172.16.8.110/16

Au re-chargement des « pools » :

root@lab3w:/etc/swanctl # swanctl --load-pools
loaded pool 'rw_pool'
loading pool 'rw_pool-v6' failed: invalid addrs value: fec0::eeee:1ab3:00ca:00.ff-fec0::eeee:1ab3:00ca:00.00
loaded pool 'v6-lab3w_home'
loaded pool 'v6_vps-uk'
loaded pool 'v6_vps-de'
loaded 4 of 5 pools, 1 failed to load, 0 unloaded

File →

cat /etc/swanctl/swanctl.conf

pools {

        rw_pool {
                addrs = 172.16.8.100-172.16.8.110
                dns = 10.105.150.1, 8.8.8.8
        }
        rw_pool-v6 {
               addrs = fec0::eeee:1ab3:00ca:00.ff-fec0::eeee:1ab3:00ca:00.00
#                addrs = 2607:5300:0060:9389:0000:1ab3:00ca:0000/104
                dns =   fc00::15:2:a:1000, 2001:4860:4860::8844
        }

        # IP HOME
        v6-lab3w_home {
                addrs = fec1::1/16
        }

        # IP VPS
        v6_vps-uk {
                addrs = fec2::1/128
        }
        v6_vps-de {
                addrs = fec3::1/128
        }
}

@+

---

Donc j’ai essayé comme dans la doc strongSwan > Virtual IP Addresses en ajoutant un « . » :

or as an IP address range

IPv4	IPv6
connections.<conn>.pools = <name>	connections.<conn>.pools = <name>
pools.<name>.addrs = 10.3.0.1-10.3.0.100	pools.<name>.addrs = 2001:db8::3.1-2001:db8::3.100

root@lab3w:/etc/swanctl # swanctl --load-pools
loaded pool 'rw_pool'
loading pool 'rw_pool-v6' failed: invalid addrs value: fec0::eeee:1ab3:00ca:fe.ff-fec0::eeee:1ab3:00ca:fe.00
loaded pool 'v6-lab3w_2home'
loaded pool 'v6_vps-uk'
loaded pool 'v6_vps-de'
loaded 4 of 5 pools, 1 failed to load, 0 unloaded

root@lab3w:/etc/swanctl # swanctl --load-pools
loaded pool 'rw_pool'
loading pool 'rw_pool-v6' failed: invalid addrs value: 2001:db8::3.1-2001:db8::3.100
loaded pool 'v6-lab3w_2home'
loaded pool 'v6_vps-uk'
loaded pool 'v6_vps-de'
loaded 4 of 5 pools, 1 failed to load, 0 unloaded

---

Adressage IPv6 de connexion « opportuniste » (road warrior) → OK :

        rw_pool-v6 {
#                addrs = fec0::eeee:1ab3:00ca:fe.ff-fec0::eeee:1ab3:00ca:fe.00/104
                addrs = fec0::eeee:1ab3:00ca:fe00/104
                dns =   fc00::15:2:a:1000, 2001:4860:4860::8844
        }

root@lab3w:/etc/swanctl # swanctl --load-pools
loaded pool 'rw_pool'
loaded pool 'rw_pool-v6'
loaded pool 'v6-lab3w_home'
loaded pool 'v6_vps-uk'
loaded pool 'v6_vps-de'
successfully loaded 5 pools, 0 unloaded

Me configure sur le client EAP pour la première machine l’adresse « fec0::eeee:1ab3:00ca:fe00/128 » — ca:fe00/128 ?

CF : remote 172.16.8.100/32 fec0::eeee:1ab3:ca:fe00/128

root@lab3w:/etc/swanctl # swanctl --list-sas
ikev2-eap-mschapv2: #25, ESTABLISHED, IKEv2, 262cf867d255bd4f_i 9728f8d9aa142ac3_r*
  local  'srv.ca.lab3w.com' @ 158.69.126.137[4500]
  remote 'orj@lab3w.fr' @ 37.174.70.100[43308] [172.16.8.100 fec0::eeee:1ab3:ca:feff]
  AES_CBC-128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
  established 721s ago
  ikev2-eap-mschapv2: #171, reqid 5, INSTALLED, TUNNEL-in-UDP, ESP:AES_GCM_16-256
    installed 721s ago
    in  c66fbbea, 388011 bytes,  1567 packets,     0s ago
    out 33cdadf1, 323124 bytes,   598 packets,     0s ago
    local  0.0.0.0/0 ::/0
    remote 172.16.8.100/32 fec0::eeee:1ab3:ca:fe00/128

J’ai créé un sujet sur les discussions strongSwan dans GitHub : IPv6 address range (road warrior pools configuration) · strongswan/strongswan ·…

Romain

[ZW3B]

Salut,

J’ai mon VPN IPv4/v6 version PostQuantum strongSwan connecté à mes serveurs depuis mon smartphone, ordinateur portable depuis n’importe quel endroit sur Terre

Bonne journée.

---

À titre d’information, en natif depuis Android , avec les mêmes paramètres je n’arrive pas à me connecter à mon VPN Type de connexion : IKEv2 MSCHAPv2.

• Versison Android 12 (mise à jour : 5 juillet 2024)
• Version Color OS : V12.1
• Appareil : OPPO A53s - Modèle CPH2135
• Version noyeau : 4.1.19.152-perf+

Discuss GitHub : In the native VPN option from Android, i cannot connect to my VPN ? · strongswan/strongswan · Discussion #2528 · GitHub

En natif (option VPN du smartphone) → KO (IP field servername) :

Nov  8 15:12:26 12[NET] <65> received packet: from 78.242.194.44[1620] to 158.69.126.137[500] (1072 bytes)
Nov  8 15:12:26 12[ENC] <65> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) ]
Nov  8 15:12:26 12[IKE] <65> 78.242.194.44 is initiating an IKE_SA
Nov  8 15:12:26 12[CFG] <65> selected proposal: IKE:AES_CTR_256/HMAC_SHA2_512_256/PRF_HMAC_SHA1/MODP_4096
Nov  8 15:12:26 12[IKE] <65> remote host is behind NAT
Nov  8 15:12:26 12[IKE] <65> sending cert request for "C=FR, O=LAB3W, CN=ZW3B Cyber Root CA : rsa_3072"
Nov  8 15:12:26 12[ENC] <65> generating 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) V ]
Nov  8 15:12:26 12[NET] <65> sending packet: from 158.69.126.137[500] to 78.242.194.44[1620] (773 bytes)
Nov  8 15:12:27 14[NET] <65> received packet: from 78.242.194.44[1621] to 158.69.126.137[4500] (488 bytes)
Nov  8 15:12:27 14[ENC] <65> parsed IKE_AUTH request 1 [ IDi IDr SA TSi TSr CPRQ(ADDR ADDR6 DNS DNS6 MASK VER) ]
Nov  8 15:12:27 14[CFG] <65> looking for peer configs matching 158.69.126.137[158.69.126.137]...78.242.194.44[orj@lab3w.fr]
Nov  8 15:12:27 14[CFG] <65> no matching peer config found
Nov  8 15:12:27 14[ENC] <65> generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
Nov  8 15:12:27 14[NET] <65> sending packet: from 158.69.126.137[4500] to 78.242.194.44[1621] (81 bytes)

En natif (option VPN du smartphone) → KO (FQDN field servername) :

Nov  8 15:54:18 07[NET] <70> received packet: from 78.242.194.44[1747] to 158.69.126.137[500] (1072 bytes)
Nov  8 15:54:18 07[ENC] <70> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) ]
Nov  8 15:54:18 07[IKE] <70> 78.242.194.44 is initiating an IKE_SA
Nov  8 15:54:18 07[CFG] <70> selected proposal: IKE:AES_CTR_256/HMAC_SHA2_512_256/PRF_HMAC_SHA1/MODP_4096
Nov  8 15:54:18 07[IKE] <70> remote host is behind NAT
Nov  8 15:54:18 07[IKE] <70> sending cert request for "C=FR, O=LAB3W, CN=ZW3B Cyber Root CA : rsa_3072"
Nov  8 15:54:18 07[ENC] <70> generating 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) V ]
Nov  8 15:54:18 07[NET] <70> sending packet: from 158.69.126.137[500] to 78.242.194.44[1747] (773 bytes)
Nov  8 15:54:18 05[NET] <70> received packet: from 78.242.194.44[1748] to 158.69.126.137[4500] (504 bytes)
Nov  8 15:54:18 05[ENC] <70> parsed IKE_AUTH request 1 [ IDi IDr SA TSi TSr CPRQ(ADDR ADDR6 DNS DNS6 MASK VER) ]
Nov  8 15:54:18 05[CFG] <70> looking for peer configs matching 158.69.126.137[srv.ca.lab3w.com]...78.242.194.44[orj@lab3w.fr]
Nov  8 15:54:18 05[CFG] <ikev2-eap|70> selected peer config 'ikev2-eap'
Nov  8 15:54:18 05[IKE] <ikev2-eap|70> peer requested EAP, config unacceptable
Nov  8 15:54:18 05[CFG] <ikev2-eap|70> switching to peer config 'ikev2-eap-mschapv2'
Nov  8 15:54:18 05[IKE] <ikev2-eap-mschapv2|70> initiating EAP_IDENTITY method (id 0x00)
Nov  8 15:54:18 05[IKE] <ikev2-eap-mschapv2|70> authentication of 'srv.ca.lab3w.com' (myself) with RSA_EMSA_PSS_SHA2_256_SALT_32 successful
Nov  8 15:54:18 05[IKE] <ikev2-eap-mschapv2|70> sending end entity cert "C=FR, O=LAB3W, CN=srv.ca.lab3w.com"
Nov  8 15:54:18 05[ENC] <ikev2-eap-mschapv2|70> generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
Nov  8 15:54:18 05[ENC] <ikev2-eap-mschapv2|70> splitting IKE message (1759 bytes) into 2 fragments
Nov  8 15:54:18 05[ENC] <ikev2-eap-mschapv2|70> generating IKE_AUTH response 1 [ EF(1/2) ]
Nov  8 15:54:18 05[ENC] <ikev2-eap-mschapv2|70> generating IKE_AUTH response 1 [ EF(2/2) ]
Nov  8 15:54:18 05[NET] <ikev2-eap-mschapv2|70> sending packet: from 158.69.126.137[4500] to 78.242.194.44[1748] (1448 bytes)

Avec « strongSwan VPN client for Android » → OK :

Nov  8 15:17:30 13[NET] <67> received packet: from 78.242.194.44[1710] to 158.69.126.137[500] (948 bytes)
Nov  8 15:17:30 13[ENC] <67> parsed 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) ]
Nov  8 15:17:30 13[IKE] <67> 78.242.194.44 is initiating an IKE_SA
Nov  8 15:17:30 13[CFG] <67> selected proposal: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
Nov  8 15:17:30 13[IKE] <67> remote host is behind NAT
Nov  8 15:17:30 13[IKE] <67> sending cert request for "C=FR, O=LAB3W, CN=ZW3B Cyber Root CA : rsa_3072"
Nov  8 15:17:30 13[ENC] <67> generating 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) V ]
Nov  8 15:17:30 13[NET] <67> sending packet: from 158.69.126.137[500] to 78.242.194.44[1710] (325 bytes)
Nov  8 15:17:31 01[NET] <67> received packet: from 78.242.194.44[1713] to 158.69.126.137[4500] (480 bytes)
Nov  8 15:17:31 01[ENC] <67> parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ IDr CPRQ(ADDR ADDR6 DNS DNS6) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
Nov  8 15:17:31 01[IKE] <67> received cert request for "C=FR, O=LAB3W, CN=ZW3B Cyber Root CA : rsa_3072"
Nov  8 15:17:31 01[CFG] <67> looking for peer configs matching 158.69.126.137[srv.ca.lab3w.com]...78.242.194.44[orj@lab3w.fr]
Nov  8 15:17:31 01[CFG] <ikev2-eap|67> selected peer config 'ikev2-eap'
Nov  8 15:17:31 01[IKE] <ikev2-eap|67> peer requested EAP, config unacceptable
Nov  8 15:17:31 01[CFG] <ikev2-eap|67> switching to peer config 'ikev2-eap-mschapv2'
Nov  8 15:17:31 01[IKE] <ikev2-eap-mschapv2|67> initiating EAP_IDENTITY method (id 0x00)
Nov  8 15:17:31 01[IKE] <ikev2-eap-mschapv2|67> peer supports MOBIKE
Nov  8 15:17:31 01[IKE] <ikev2-eap-mschapv2|67> authentication of 'srv.ca.lab3w.com' (myself) with RSA_EMSA_PSS_SHA2_256_SALT_32 successful
Nov  8 15:17:31 01[IKE] <ikev2-eap-mschapv2|67> sending end entity cert "C=FR, O=LAB3W, CN=srv.ca.lab3w.com"
Nov  8 15:17:31 01[ENC] <ikev2-eap-mschapv2|67> generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
Nov  8 15:17:31 01[ENC] <ikev2-eap-mschapv2|67> splitting IKE message (1760 bytes) into 2 fragments
Nov  8 15:17:31 01[ENC] <ikev2-eap-mschapv2|67> generating IKE_AUTH response 1 [ EF(1/2) ]
Nov  8 15:17:31 01[ENC] <ikev2-eap-mschapv2|67> generating IKE_AUTH response 1 [ EF(2/2) ]
Nov  8 15:17:31 01[NET] <ikev2-eap-mschapv2|67> sending packet: from 158.69.126.137[4500] to 78.242.194.44[1713] (1444 bytes)
Nov  8 15:17:31 01[NET] <ikev2-eap-mschapv2|67> sending packet: from 158.69.126.137[4500] to 78.242.194.44[1713] (388 bytes)
Nov  8 15:17:31 07[NET] <ikev2-eap-mschapv2|67> received packet: from 78.242.194.44[1713] to 158.69.126.137[4500] (96 bytes)
Nov  8 15:17:31 07[ENC] <ikev2-eap-mschapv2|67> parsed IKE_AUTH request 2 [ EAP/RES/ID ]
Nov  8 15:17:31 07[IKE] <ikev2-eap-mschapv2|67> received EAP identity 'orj@lab3w.fr'
Nov  8 15:17:31 07[IKE] <ikev2-eap-mschapv2|67> initiating EAP_MSCHAPV2 method (id 0x28)
Nov  8 15:17:31 07[ENC] <ikev2-eap-mschapv2|67> generating IKE_AUTH response 2 [ EAP/REQ/MSCHAPV2 ]
Nov  8 15:17:31 07[NET] <ikev2-eap-mschapv2|67> sending packet: from 158.69.126.137[4500] to 78.242.194.44[1713] (112 bytes)
Nov  8 15:17:31 12[NET] <ikev2-eap-mschapv2|67> received packet: from 78.242.194.44[1713] to 158.69.126.137[4500] (144 bytes)
Nov  8 15:17:31 12[ENC] <ikev2-eap-mschapv2|67> parsed IKE_AUTH request 3 [ EAP/RES/MSCHAPV2 ]
Nov  8 15:17:31 12[ENC] <ikev2-eap-mschapv2|67> generating IKE_AUTH response 3 [ EAP/REQ/MSCHAPV2 ]
Nov  8 15:17:31 12[NET] <ikev2-eap-mschapv2|67> sending packet: from 158.69.126.137[4500] to 78.242.194.44[1713] (144 bytes)
Nov  8 15:17:31 10[NET] <ikev2-eap-mschapv2|67> received packet: from 78.242.194.44[1713] to 158.69.126.137[4500] (80 bytes)
Nov  8 15:17:31 10[ENC] <ikev2-eap-mschapv2|67> parsed IKE_AUTH request 4 [ EAP/RES/MSCHAPV2 ]
Nov  8 15:17:31 10[IKE] <ikev2-eap-mschapv2|67> EAP method EAP_MSCHAPV2 succeeded, MSK established
Nov  8 15:17:31 10[ENC] <ikev2-eap-mschapv2|67> generating IKE_AUTH response 4 [ EAP/SUCC ]
Nov  8 15:17:31 10[NET] <ikev2-eap-mschapv2|67> sending packet: from 158.69.126.137[4500] to 78.242.194.44[1713] (80 bytes)
Nov  8 15:17:31 14[NET] <ikev2-eap-mschapv2|67> received packet: from 78.242.194.44[1713] to 158.69.126.137[4500] (112 bytes)
Nov  8 15:17:31 14[ENC] <ikev2-eap-mschapv2|67> parsed IKE_AUTH request 5 [ AUTH ]
Nov  8 15:17:31 14[IKE] <ikev2-eap-mschapv2|67> authentication of 'orj@lab3w.fr' with EAP successful
Nov  8 15:17:31 14[IKE] <ikev2-eap-mschapv2|67> authentication of 'srv.ca.lab3w.com' (myself) with EAP
Nov  8 15:17:31 14[IKE] <ikev2-eap-mschapv2|67> peer requested virtual IP %any
Nov  8 15:17:31 14[CFG] <ikev2-eap-mschapv2|67> reassigning offline lease to 'orj@lab3w.fr'
Nov  8 15:17:31 14[IKE] <ikev2-eap-mschapv2|67> assigning virtual IP 172.16.8.100 to peer 'orj@lab3w.fr'
Nov  8 15:17:31 14[IKE] <ikev2-eap-mschapv2|67> peer requested virtual IP %any6
Nov  8 15:17:31 14[CFG] <ikev2-eap-mschapv2|67> reassigning offline lease to 'orj@lab3w.fr'
Nov  8 15:17:31 14[IKE] <ikev2-eap-mschapv2|67> assigning virtual IP fec0::eeee:1ab3:ca:feff to peer 'orj@lab3w.fr'
Nov  8 15:17:31 14[IKE] <ikev2-eap-mschapv2|67> IKE_SA ikev2-eap-mschapv2[67] established between 158.69.126.137[srv.ca.lab3w.com]...78.242.194.44[orj@lab3w.fr]
Nov  8 15:17:31 14[CFG] <ikev2-eap-mschapv2|67> selected proposal: ESP:AES_GCM_16_256/NO_EXT_SEQ
Nov  8 15:17:31 14[IKE] <ikev2-eap-mschapv2|67> CHILD_SA ikev2-eap-mschapv2{1677} established with SPIs c1900ab9_i 8f10373c_o and TS 0.0.0.0/0 ::/0 === 172.16.8.100/32 fec0::eeee:1ab3:ca:feff/128
Nov  8 15:17:31 14[ENC] <ikev2-eap-mschapv2|67> generating IKE_AUTH response 5 [ AUTH CPRP(ADDR ADDR6 DNS DNS DNS6 DNS6) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_6_ADDR) N(ADD_6_ADDR) N(ADD_6_ADDR) N(ADD_6_ADDR) N(ADD_6_ADDR) N(ADD_6_ADDR) N(ADD_6_ADDR) ]
Nov  8 15:17:31 14[NET] <ikev2-eap-mschapv2|67> sending packet: from 158.69.126.137[4500] to 78.242.194.44[1713] (560 bytes)

---

Bizarre le traceroute vers le dns.google (j’arrive en VPN au Canada, j’ai sort par la passerelle de mon serveur, puis les 2 adresses sont « taguées française » puis je retourne au Canada, puis j’arrive aux USA) :

La configuration vu depuis mon smartphone :

Le software « Network Analyzer » :

[AnonymousCoward]

@ZW3B

Bizarre le traceroute vers le dns.google (j’arrive en VPN au Canada, j’ai sort par la passerelle de mon serveur, puis les 2 adresses sont « taguées française » puis je retourne au Canada, puis j’arrive aux USA) :

Si l’on vérifié l’adresse IP 2001:41d0:0:50::2:15c dans la Routing Assets Database (le successeur de whois), on voit que c’est une IP appartenant à OVH.

Je pense donc que c’est une IP utilisée par OVH sur leur réseau au Canada et que l’information affichée par ton appli sur smartphone n’est pas bonne.

Avec le système du genre Traffic Manager, l’adresse IP correspondant au nom de domaine (ici dns.google.com) dépend de l’emplacement géographique de ton serveur DNS.
En utilisant un serveur DNS situé au Canada, tu récupères une IP au Canada ou aux US.

–
AnonymousCoward

[ZW3B]

RienÀVoir :

root@lab3w:/etc/swanctl # scan6 -L -i vmbr0 -e --print-type all
fe80::3e26:e4ff:fe2a:b91b @ 3c:26:e4:2a:b9:1b
fe80::3e26:e4ff:fe31:7f63 @ 3c:26:e4:31:7f:63
2607:5300:60:93ff:ff:ff:ff:fe @ 3c:26:e4:2a:b9:1b
2607:5300:60:93ff:ff:ff:ff:fd @ 3c:26:e4:31:7f:63

root@lab3w:/etc/swanctl # ip -6 neighbor show dev vmbr0 | grep router
fe80::3e26:e4ff:fe31:7f63 lladdr 3c:26:e4:31:7f:63 router STALE
2607:5300:60:93ff:ff:ff:ff:fe lladdr 3c:26:e4:2a:b9:1b router REACHABLE
fe80::3e26:e4ff:fe2a:b91b lladdr 3c:26:e4:2a:b9:1b router STALE
2607:5300:60:93ff:ff:ff:ff:fd lladdr 3c:26:e4:31:7f:63 router STALE

@AnonymousCoward

on voit que c’est une IP appartenant à OVH.

Je pense donc que c’est une IP utilisée par OVH sur leur réseau au Canada et que l’information affichée par ton appli sur smartphone n’est pas bonne.

oui, tenez le VMS (Visual Monitoring System) - Realtime status of OVHcloud datacenters : http://vms.status-ovhcloud.com/ ; j’aime bien cette page d’accueil

Je crois que c’est nouveau, (mes anciens traceroute6 n’affichaient pas çà – avec le même soft) ^^
Serais-ce parce que je suis client FRançais qui loue un serveur OVH au CAnada, donc ils auraient peut-être fait une routine comme celle-ci, je ne sais pas trop.