VPn ikev2 soucis Macos
-
Bonjour,
Nous rencontrons un soucis pour se connecter a un vpn ikev2 depuis les produit apple (MacosX 10.13 et ios10).
Nous avons créer un vpn ikev2 avec une Methode d'authentification en EAP-RADIUS pour synchroniser avec un radius lui meme synchro avec un AD, le vpn est chiffré AES 256 , SHA256 et DH 1024.
Sur les clients windows le VPN fonctionne sans soucis.et lors de la connexion nous avons ces logs:
Jul 12 10:59:44 charon 13[NET] <604> received packet: from x.x.x.x[500] to x.x.x.x[500] (304 bytes)
Jul 12 10:59:44 charon 13[ENC] <604> parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
Jul 12 10:59:44 charon 13[IKE] <604> x.x.x.x is initiating an IKE_SA
Jul 12 10:59:44 charon 13[IKE] <604> remote host is behind NAT
Jul 12 10:59:44 charon 13[IKE] <604> sending cert request for "C=FR, ST=x.x.x.x, L=x.x.x.x, O=Ox.x.x.x, E=ix.x.x.x, CN=internal-ca"
Jul 12 10:59:44 charon 13[ENC] <604> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(MULT_AUTH) ]
Jul 12 10:59:44 charon 13[NET] <604> sending packet: from x.x.x.x[500] to x.x.x.x[500] (345 bytes)
Jul 12 10:59:44 charon 13[NET] <604> received packet: from x.x.x.x[4500] to x.x.x.x[4500] (352 bytes)
Jul 12 10:59:44 charon 13[ENC] <604> unknown attribute type (25)
Jul 12 10:59:44 charon 13[ENC] <604> parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) N(MOBIKE_SUP) IDr CPRQ(ADDR DHCP DNS MASK ADDR6 DHCP6 DNS6 (25)) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr ]
Jul 12 10:59:44 charon 13[CFG] <604> looking for peer configs matching x.x.x.x[vpn.domain.com]...x.x.x.x[10.0.10.172]
Jul 12 10:59:44 charon 13[CFG] <con1|604> selected peer config 'con1'
Jul 12 10:59:44 charon 13[IKE] <con1|604> initiating EAP_IDENTITY method (id 0x00)
Jul 12 10:59:44 charon 13[IKE] <con1|604> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Jul 12 10:59:44 charon 13[IKE] <con1|604> peer supports MOBIKE, but disabled in config
Jul 12 10:59:44 charon 13[IKE] <con1|604> authentication of 'vpn.domain.com' (myself) with RSA signature successful
Jul 12 10:59:44 charon 13[IKE] <con1|604> sending end entity cert "C=FR, ST=x.x.x.x, L=x.x.x.x, O=Ox.x.x.x, E=ix.x.x.x, CN=vpn.domain.com"
Jul 12 10:59:44 charon 13[ENC] <con1|604> generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
Jul 12 10:59:44 charon 13[ENC] <con1|604> splitting IKE message with length of 1680 bytes into 2 fragments
Jul 12 10:59:44 charon 13[ENC] <con1|604> generating IKE_AUTH response 1 [ EF(1/2) ]
Jul 12 10:59:44 charon 13[ENC] <con1|604> generating IKE_AUTH response 1 [ EF(2/2) ]
Jul 12 10:59:44 charon 13[NET] <con1|604> sending packet: from x.x.x.x[4500] to x.x.x.x[4500] (1236 bytes)
Jul 12 10:59:44 charon 13[NET] <con1|604> sending packet: from x.x.x.x[4500] to x.x.x.x[4500] (532 bytes) -
Les joies d'Ipsec entre des plateformes différentes !
Je n'ai pas de solution à ce problème de connectivité parce que les logs ne montrent rien de flagrants et je n'ai pas le temps d'aller plus loin. Deux commentaires cependant :AES 256 est superfétatoire très probablement dans votre cas. AES 128 suffit et économise des ressources CPU.
Par contre le Diifie Hellman 1024 est insuffisant. Le 20148 est nécessaire aujourd'hui.Autre commentaire : pourquoi avoir choisi IpSec pour connecter des clients distants ? Un vpn SSL (OpenVPN) est beaucoup plus tolérant dans la gestion d’environnement multi plateformes, multi constructeurs. IPSec est connu pour sa susceptibilité.
-
Bonjour ,
Le client final souhaite utiliser le client vpn intégrer à windows pour se connecter au VPN. OR le client windows ne permet de pas de se connecter a des VPN OPEN VPN. Aussi windows 10 ne gère pas le Diifie Hellman 2048. ( hormis modification de base de registre)
-
Les clients ont parfois besoin de conseils ...
Aussi windows 10 ne gère pas le Diifie Hellman 2048. ( hormis modification de base de registre)
Informez-vous : https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2016/3174644 :
All versions of Windows 10 support the new DH modulus settings and use 2048 as the DH modulus default setting. -
L'ANSSI certifie Stormshield comme firewall (hardware).
Or les VPN (roadwarrior) supportés par Stormshield sont IPSEC et OpenVPN (même si le firewall Stormshield indique 'VPN SSL' c'est OpenVPN qui est derrière, et la config n'utilise que peu de directives OpenVPN).Donc OpenVPN est, AMHA, parfaitement valide à être utilisé pour un groupe sérieux et multi-client (Windows, Mac, Android, iphone), même au prix de l'ajout du client.
Depuis Windows 2000, je ne suis guère séduit par les VPN standard et intégrés à Windows (L2TP). Il était aisé de créer un serveur PPTP mais ce protocole n'est vraiment plus à utiliser car totalement obsolète et unsecure ... (pfSense l'a retiré de son interface, me trompe-je ?)
-
En effet Pfsense ne supporte plus Pptp à cause de son obsolescence. L2TP est particulièrement peu efficace du fait de la forte surcharge protocolaire qu'il induit. La grande majorité des entreprises n'utilisent pas les clients vpn de Microsoft.
-
salut salut
petit aparté qui n'est pas la pour résoudre le problème évoqué, mais pour abondé dans le sens de jdh
dans la boite du client chez qui je suis, des tests ont été pratiqués pour ne plus se servir de client libre ou pas sur une période de trois mois, le résultat fut que nous (tester et gens du projet) n'avons jamais pu avoir une connexion stable et inter connexion sur un environnement multi plateforme.
les solutions qui ont été retenues furent , en hardware avec fortinet cisco norton et en software openvpn sur machine dédiée.
je ne parle pas de pfsense parce que le sujet est le vpn, en multi site en interne, et mutli site satellite, sans oublier les clients mobiles en ios android windows. un joli casse tête.
et personnellement je suis pour que la partie vpn ne soit pas sur le pfsense ou tout autre pare-feu.bon courage.
-
@tatave said in VPn ikev2 soucis Macos:
pour ne plus se servir de client libre ou pas sur une période de trois mois
Je ne comprend pas ce que cela signifie.
hardware avec fortinet cisco norton et en software openvpn sur machine dédiée.
En ipsec ou SSL ?
je suis pour que la partie vpn ne soit pas sur le pfsense ou tout autre pare-feu.
Si on veut faire les choses en toute rigueur c'est nettement préférable afin de faire se terminer le tunnel vpn dans une zone réseau spécifique, puis de là déterminer où l'on peut ensuite aller.
-
Concernant le VPN, il y a 2 possibilités (distinctes) :
- le serveur VPN est sur le firewall,
- le serveur VPN n'est pas sur le firewall,
Le fait d'avoir le serveur VPN sur le firewall impacte celui-ci sur la performance mais c'est la place logique et naturelle pour filtrer les users VPN.
Inversement, si le serveur VPN est une machine interne, il faut intégrer à cette place le filtrage des machines accédées user par user, ce qui est moins simple.
De plus, quid du routage retour vers le client VPN ? Le site OpenVPN ou les tutos que l'on trouve pour créer un serveur OpenVPN interne (sous Linux) incluent souvent des lignes " iptables postrouting -j MASQUERADE" pour résoudre le problème de routage, ce qui est très loin d'être idéal !
Je préfère donc nettement la solution serveur VPN sur le firewall. (Même si je pratique aussi l'autre ...)