Panorama des solutions

Pour réellement bénéficier du cloud, il est nécessaire d'y accéder de manière sécurisée et donc de monter des tunnels VPN entre le SI local et le fournisseur cloud.

Nous présentons dans ce blog et les suivants un exemple de configuration entre un ASA 5506 sous FTD et AWS, en commençant par quelques rappels concernant les VPNs pour rentrer ensuite dans la configuration concrète.

Différents modes de connexion VPN

Trois modes de connexion VPN existent. Ils correspondent à des niveaux d'intégration différents entre les réseaux :

• GRE, Generic Routing Encapsulation, est un protocole générique d'encapsulation qui correspond à l'idée intuitive, vu comme un tunnel monté à travers Internet à travers lequel on fait transiter du trafic. On ne le rencontre pas si souvent en entreprise. Le cas d'usage historique est de monter une liaison point à point entre deux routeurs à travers un réseau IP, en encapsulant le trafic dans une trame IP.
• Lan to Lan : c'est le cas d'usage habituel du VPN site à site. A la différence du GRE, le trafic transitant entre les deux sites est bien identifié, par des sous-réseaux bien définis, et il n'est pas recommandé d'envoyer du trafic générique avec ce protocole, c'est pourquoi nous l'appelons LAN to LAN plutôt que site à site
• Client : c'est la solution pour intégrer un client distant dans un réseau local, souvent via Internet. Cette configuration a deux spécificités, d'attribuer une adresse LAN au client distant et de définir des règles (traffic split) pour choisir le traffic qui transitera par l'interface VPN. Deux cas d'usage de cette solution sont le télétravail à domicile ou en mobilité et l'accès au réseau admin pour administrateurs système

Notons que le niveau d'intégration croit entre le GRE qui peut être utilisé entre des routeurs qui "ne se connaissent pas", le LAN-TO-LAN qui interconnectent des réseaux LAN bien identifiés et le VPN client qui intègre un client dans un réseau LAN.

Pour le VPN site à site, la technologie par défaut est IPSec. C'est presque un standard de fait même si des solutions propriétaires émergent notamment avec le développement du SD-WAN.

Pour le VPN client, de nombreuses solutions sont disponibles, SSL VPN (anyconnect ou openVPN par exemple), L2TP (Microsoft), PPTP... Vous trouverez facilement des ressources sur le web à ce sujet.

Complexité de la configuration VPN

Configurer le VPN est une opération complexe :

• les technologies sont opaques, par définition :-), reposant sur des bases mathématiques avancées et des travaux dont la divulgation est récente (postérieure aux années 1980)
• le trafic est chiffré; le debuggage est donc plus difficile. En monitorant le trafic, on a une visibilité très limitée sur le contenu du trafic. Il faut impérativement utiliser le mode debug, lorsqu'il est disponible sur les end points, pour s'en sortir;
• la sécurité n'accepte pas l'à-peu-près. De même qu'un mot de passe avec un espace en plus n'est pas accepté pour s'authentifier, la modification d'une trame ÏP/VPN peut être rejetée si elle peut correspondre à un mode d'attaque, mode d'attaque dont la liste est longue et que l'on ne connaît pas lorsque l'on a juste besoin de configurer une connexion. Une modification, par exemple NAT traversal, suffit à faire bloquer l'établissement de la connexion et est parfois impossible à contourner.
• le VPN agit sur toutes les couches du réseau, attribution d'adresses, routage, encapsulation, chiffrement.
• les options de configuration sont nombreuses et doivent être cohérentes entre les deux points de connexion

En conclusion, quand cela ne fonctionne pas tout de suite, il est possible de passer beaucoup de temps avant de trouver la solution. Il est donc impératif d'employer les outils à disposition et notamment d'analyser le traffic et le mode debug et les traces des passerelles VPN.

Spécificités constructeurs

Nous ne présentons que les configurations que nous avons testées.

Cisco

Quelques points à retenir :

• La manière de configurer le VPN est différente sur les parefeux ASA, sur les nouvelles versions FTD et les routeurs.
• L'évolution des technologies de chiffrement a rendu obsolètes certains équipements anciens, du moins pour faire du VPN. Cisco ne propose malheureusement pas d'évolution de ces équipements (SHA1, ...).
• En VPN client, les solutions les plus simples sont payantes (anyconnect). Sur les anciennes versions des équipements, deux licences anyconnect sont fournies. Sur les ASA FTD, le VPN client est payant dans son ensemble et la seule option possible est d'utiliser anyconnect.

Sur les Cisco FTD, le support du VPN est récent et certains paramètres ne peuvent pas être configurés même en Flex Config.

Microsoft : PPTP et L2TP

Microsoft reste très présent, côté client, dans l'accès remote, avec L2TP. En fonction de la couche de chiffrement, L2TP ne correspond plus aux standards de chiffrement mais la même remarque pourrait être faite pour IPSEC/Ike dès lors que l'on utilise SHA1.

PPTP est faible en terme de sécurité. Il ne devrait plus être utilisé mais reste présent comme un existant.

Le principal avantage de L2TP est sa présence sur les OS Windows par défaut. Ce que l'on peut en retenir :

• les messages de debuggage ne sont pas simples à interpréter
• le NAT traversal est parfois mal supporté, notamment avec un client derrière des ASA FTD où la configuration du NAT traversal est très difficile voir impossible dans certains cas
• le changement d'OS, entre Win 7, 8 et 10, peut créer des problèmes
• certaines mises à jour Windows ont (par le passé) cassé la configuration VPN et nécessité des investigations longues.

OpenVPN

C'est la solution qui monte en terme de VPN clients. Il s'agit d'un VPN SSL, capable de traverser la plupart des pare feux et des box Internet. Le client se configure via un fichier de configuration texte contenant l'ensemble des paramètres de connexion.

Nous l'avons testée dans plusieurs configurations :

• sur des NAS où la configuration était complexe du fait du linux custom du NAS et de la GUI associée : accès difficile aux paramètres, blocage de certains fonctionnalités
• sur des clients Windows où le service fonctionnait correctement. Cependant, le client souhaitait que le PC se connecte automatiquement avant ouverture de session. Cette configuration était plus complexe à mettre en place.
• chez un client, équipé d'un Cisco SMB RV320, où le VPN fonctionnait sans problème, associé à un fichier de configuration déployé sur les postes clients.

En synthèse

En VPN LAN to LAN, IPSec est devenu un standard, interopérable entre les constructeurs.

Lorsque le LAN to LAN devient trop complexe du fait du nombre de réseaux à interconnecter, GRE est une solution intéressante.

En VPN client, les solutions gratuites sont largement utilisées. Dans certains cas, elles fonctionnent très bien. Dans d'autres, leur configuration s'avère complexe, en particulier lorsqu'elles ont été repackagées par un éditeur intermédiaire pour l'intégrer à sa solution (NAS, parefeu...).

Les solutions propriétaires des constructeurs de passerelles et parefeux sont généralement plus simples à configurer, à déployer et administrer. Ils gardent donc un premium et font payer les licences correspondantes.