L2TP/IPSec

Tunnel L2TP/IPsec


Un des derniers de type de tunnel configurable sur CISCO qui manquait à mon blog


Théorie du complot


Très rapide, je détaillerai les commandes en cours de route.

Le protocole L2TP est un dérivé du PPTP, mixé a L2F. Il consiste à créer des tunnels en encapsulant des trames PPP. Attention, cette version n'est pas sécurisée, on ne peut pas parler de VPN en tant que tel.
Pour palier cette limitation, nous utiliserons une variante L2TP/IPsec.

Le modèle de fonctionnement est basé sur un LAC et un LNS. Je dois bien avouer avoir encore des doutes à savoir qui fait quoi, surtout sur un routeur Cisco qui me semble cumuler en partie les deux rôles. Mais qu'importe !! il ne faut pas être étonné de trouvé des commandes qui font penser à des appels téléphoniques dans la configuration qui va suivre.

Je vous laisse à Wikipedia pour tous les aspects théoriques de la chose. Il est intéressant de voir l'empilement d'encapsulation, d'en-tête IPSEC, IP, UDP, L2TP, PPP, ....

Passons aux avantages :

1. Natif sur une majorité de systèmes, Windows ou androïde
2. Facilité de configuration
3. Pris en charge par le module de cryptage embarqué (on board encryption card) de certains routeurs.

Pour les inconvénients :

1. Contrairement aux tunnels SSL, nécessite l'ouverture de quelques ports supplémentaires sur les firewalls.
2. Limitations des options de chiffrement sous Windows : utilisation de 3DES, DH groupe à 2 ...
3. Vieillissant ? 

Plate-forme de test

Les clients 1 et 2 fonctionnent respectivement sous Windows 7 et 8.1.

Mon routeur R2 est un 7200 qui simule une box individuelle (Nat)

R1 est un 7200 sur lequel L2TP/IPsec est paramétré

Nous allons donc monter un VPN entre les clients et R1.

Les connections seront authentifiées par une clef partagée (comme sur un VPN site à site). 

Les utilisateurs seront authentifiés via la base locale du routeur. J'ai actuellement cette connexion en fonctionnement chez moi mais j'utilise RADIUS pour l'authentification : si c'est le cas utiliser la commande aaa authorization default if-authenticated.

Configuration du routeur

Pour authentifier les utilisateurs :

aaa authentication ppp VPDN_AUTH local

On oublie pas de créér des utilisateurs ...

Texto de chez Cisco :

A virtual private dial-up network (VPDN) allows a private network dial in service to span across to remote access servers (defined as the L2TP Access Concentrator [LAC]).

When a Point-to-Point Protocol (PPP) client dials into a LAC, the LAC determines that it should forward that PPP session on to an L2TP Network Server (LNS) for that client. The LNS then authenticates the user and starts the PPP negotiation. Once PPP setup has completed, all frames are sent through the LAC to the client and the LNS.

Vous voyez maintenant pourquoi je disais que le routeur officie à la fois en tant que LAC et LNS ?

Ce qui nous donne en config :

vpdn enable

!

vpdn-group L2TP

 ! Default L2TP VPDN group

 accept-dialin On accepte les appels rentrants

  protocol l2tp On utilise le protocole L2TP

  virtual-template 10 référence à l'interface Template 10

 no l2tp tunnel authentication Celle-ci sera effectuée via IPsec

Pour la partie ISAKMP/IPsec:

crypto isakmp policy 1

 encr 3des sniff, uniquement 3DES est pris en charge par Windows

 authentication pre-share utilisation d'une clef partagée

 group 2 sniff, uniquement DH 2 est pris en charge par Windows

!

crypto isakmp key BLABLA address 0.0.0.0 Définition de la clef partagée, qqch de méga FORT !!

!

!

crypto ipsec transform-set L2tp esp-3des esp-sha-hmac Définition des protocoles IPsec

 mode transport transport et pas tunnel !!!!!!!!!

!

!

crypto dynamic-map dyn-map 10 Création du dynamic-map 

 set nat demux support du Nat pour client windows

 set transform-set L2tp utilisation du transform-set créé juste au dessus

!

!

crypto map outside_map 65535 ipsec-isakmp dynamic dyn-map 

Pour des infos complètes :

http://www.cisco.com/c/en/us/td/docs/ios/12_4t/12_4t2/pt_wnlns.html

Voici la configuration de notre interface Template 10 :

interface Virtual-Template10

 ip unnumbered Loopback100 qui elle a une adresse en 10.3.20.1

 no ip redirects option

 no ip unreachables option

 no ip proxy-arp option

 zone-member security Tunnel ahh à voir dans un prochain article, ça va faire trop long ...

 peer default ip address pool SSL lié au pool d'adresses IP SSL pour nos clients

 ppp authentication ms-chap-v2 VPDN_AUTH authentification des utilisateurs

Application de notre crypto map sur notre interface WAN :

interface FastEthernet0/0

 ip address 10.10.10.1 255.255.255.252

 no ip unreachables

 no ip proxy-arp

 zone-member security out

 duplex full

 crypto map outside_map

Création de notre pool d'adresses IP :

IP local pool SSL 10.3.20.1 10.3.20.10

Configuration de Windows :

Procédure sous Windows 7, idem pour Windows 8.1

Ici, un nom de domaine fait parfaitement l affaire

Utilisateur et mot de passe correspondent aux comptes créés sur le routeur.

Type : L2TP
Chiffrement : exiger
Authentification : MS-CHAP V2

On oublie pas de rentrer la clef BLABLA



Verification 

R1#sh crypto isakmp sa detail

Codes: C - IKE configuration mode, D - Dead Peer Detection

       K - Keepalives, N - NAT-traversal

       T - cTCP encapsulation, X - IKE Extended Authentication

       psk - Preshared key, rsig - RSA signature

       renc - RSA encryption

IPv4 Crypto ISAKMP SA

C-id  Local           Remote          I-VRF  Status Encr Hash   Auth DH Lifetime Cap.

1007  10.10.10.1      192.168.2.2            ACTIVE 3des sha    psk  2  07:59:36

       Engine-id:Conn-id =  SW:7

IPv6 Crypto ISAKMP SA

Bon clic à tous,

WEBVpn, SSL/TLS et certificat tiers

Bonjour,

Dans l'article WEBVpn, SSL/TLS en action, nous avons traité de la configuration d'un tunnel VPN entre une station et un routeur grâce aux protocoles SSL/TLS. Le certificat servant à authentifier le routeur vis à vis du client était un self-signed stocké sur le routeur.

Cette fois-ci nous allons utiliser un serveur de PKI tiers qui va fournir les certificats au routeur.

L'utilisateur qui va se connecter via le portail VPN ne sera plus authentifié via la base de données internes au routeur mais via AD. Pas d'inquiétude, le principe est le même que quand on configure l'authentification au routeur via Radius.

Dans une deuxième partie, (et donc dans un article qui arrivera plus tard) nous pousserons le vis plus loin. Nous custumiserons l'interface web et nous utiliserons des attributs radius pour une page web différente par groupe de clients.

Haut les cœurs !!

Présentation de la plate forme.

Attention, elle ne me sert pas que pour ce lab est pas mal d'autres choses sont configurées qui n'ont aucun rapport ; Toutefois, si vous êtes intéressés pour un aperçu de BGP, elle peut être aussi un bon point de départ.

A tous ceux qui téléchargerons la topology, je vous invite à tout d'abord régler l'heure sur R1, R10 et R8. Les routeurs sont connectés via BGP, attention la redistribution au niveau du LAN se fait via R4, penser bien à l'allumer !

Nous avons un client Admin qui va se connecter via un tunnel SSL/TLS au routeur R10. A savoir que l'on pourrait utiliser les protocole HSRP sur R10 et R8 pour offrir un minimum de redondance au système. Le but étant de pouvoir surfer sur une page du serveur 2012_01 dans le domaine lanwan.com.

Le serveur SRV2-CA est notre serveur PKI dans le domaine xavon.com.

Configuration du serveur PKI.

Première chose à faire, installation du rôle Active Directory Domain Services (nouveau DC promo). Configuration, redémarrage et nous voilà prêt.

On peur maintenant créer un utilisateur et le mettre dans le groupe IIS_IUSRS et dans Domain Admins.

Vient ensuite l'installation du rôle Active Directory Certificate Services. En fait, même si ça paraît différent aux premiers abords, la configuration est quasi la même que Serveur 2008 (voir ici). Pour ceux qui auraient besoin de plus de détails, n'hésitez pas à demander.

Ici j'ai galérer, et je misère encore. Si l'on s'en tient là, on va pouvoir pousser un certificat à notre routeur. Le problème est que quand je vais vouloir me connecter avec mon client, je vais avoir une erreur du type CERTIFICATE MAL-FORMED. Ma solution (qui marche mais mal) et de créer un template de certificat à partir de l'IPSEC.

Mise à jour : ça fonctionne, le reste du blog a été mis à jour !

Pour cela, allez dans Action et Manage. Cliquez ensuite sur le certificat IPSEC et dupliquer le.

J'ai nommé mon certificat XavonSec, ceux qui me connaissent seront pas surpris …

Pour la configuration de celui-ci :

Onglet CRYPTOGRAPHY.

Onglet Security

Attention à bien ajouter votre utilisateur !!!

Onglet Subject Name

Alors j'imagine qu'il a des tas d'autres possibilités pour rendre la chose plus sécurisée, En attendant de m'acheter un bouquin sur les certificats sous Windows 2012, faites preuve d'un peu de patience !!!

Le certificat est terminé, ne pas oublier de l'ajouter aux templates actifs.

On passe au registre.

En effet, si l'on veut utiliser notre template nous devons modifier quelques clefs.

Attention à bien donner les droits à votre utilisateur sur le dossier MSCEP.

Et voilà pour le serveur !

Quand est-il du routeur ?

Petit rappel sur le trustpoint à configurer :

crypto pki trustpoint SRV2-CA

enrollment mode ra

enrollment url http://80.12.10.2:80/certsrv/mscep/mscep.dll

fqdn none

subject-name CN=r10.lanwan.com, OU=lanwan, C=FR

revocation-check none

source interface Loopback2

rsakeypair VPN

L'option  none du fqdn permet de ne pas générer d'erreur au niveau du certificat.
Attention au subject-name, c'est sensible à la casse !

Au niveau de passerelle VPN, rien de neuf sous le soleil mais on utilise le trustpoint SRV2-CA :

webvpn gateway Wg

hostname Wg

ip address 2.2.2.2 port 443

ssl encryption rc4-md5

ssl trustpoint SRV2-CA

logging enable

inservice

Passons maintenant à l'authentification du client via AD.

On commence par créer une méthode d'accès AAA :

aaa authentication login ACCdistant group radius

On pourrait spécifier local après radius, en cas de pépins du serveur par exemple mais je trouve pas ça glop.

On configure la partie radius de l'affaire :

radius server AccDistant

address ipv4 219.42.36.1 auth-port 1645 acct-port 1646

key radius

Rien de bien complexe ici, attention à la clef qui devra être identique dans le serveur.

La source :

ip radius source-interface Loopback2

Pourquoi cette commande ?

Elle me simplifie grandement la vie !! En effet, entre les tunnels configurés, les interfaces sources BGP, … je trouve beaucoup plus facile d'utiliser une même et seule adresse pour toutes les tâches administratives du routeur.

On est pas mal au niveau du routeur, terminons la configuration de notre serveur 2012_01.

Idem que pour le serveur de certificats, on commence par promulguer notre serveur en tant que domaine contrôleur.

On installe ensuite le rôle Network Policy and Access Services

On configure ensuite notre client radius, qui sera le routeur :

Petit rappel pour les mous du bulbe : la clef est la même que celle configurée sur le routeur !

Vient ensuite une network policy :

J'utilise ici un groupe de sécurité configuré précédemment.

Attention à bien spécifier la méthode Unencrypted pour l'authentification.

Au niveau de la station, on installe le certificat de SRV2-CA dans les trusted machin choses. (via http://80.12.10.2/certsrv/ pour notre exemple)

Il ne reste plus qu'à tester à partir de notre station cliente !!

Liens externes :

Horizon du Web

Bon clic à tous,

WEBVpn, SSL/TLS en action

Topic présentant un peu de théorie sur les tunnels SSL/TLS et Ipsec configurables entre un client et un routeur CISCO.

Pourquoi et pourquoi faire ?

Imaginons un utilisateur connecté sur une borne WIFI dans une gare, Il doit impérativement accéder à des documents se trouvant sur le serveur de fichiers de son entreprise. Comment le faire de manière sécurisée : au moyen d'un tunnel VPN entre son ordinateur et le routeur ou firewall qui est le point d'entrée dans l'entreprise. En fonction de la politique de sécurité, de l'environnement logiciel et matériel mais aussi des droits accordés aux utilisateurs il va falloir déployer ces technologies VPN de manière différente.

La théorie du complot.

On trouve deux grandes familles de tunnels VPN : les tunnels utilisant les protocoles TLS/SSL et ceux utilisant IPsec. Les deux fournissent les mêmes capacités en termes de protection des données.

On trouve ensuite deux grands modes d'encapsulation des données.

Clientless VPN.

Aucun software n'est installé sur la machine cliente. L'utilisateur va utiliser un navigateur web pour accéder au router WebVPN. Celui-ci va proposer une page web contenant des liens et des bookmarcks vers différents services dans le LAN.

FullTunneling VPN.

Un software, dans notre cas ce sera CISCO AnyConnect, est installé sur la machine du client ou nous disposons d'un routeur (comme dans une configuration site à site). Contrairement au clientless VPN qui va se limiter à un accès via http, nous avons ici un accès complet à toutes les ressources de notre LAN.

Pour résumer nous pouvons configurer :

Un tunnel clientless TLS/SSL.

Avantages : facile à configurer et pas de soucis de pare feu, la technologie utilisant le protocole https.

Problèmes : ne supporte pas toutes les applications IP, les clients peuvent utiliser des ordinateurs non sécurisés pour accéder au réseau

Après une authentification bi-directionnelle le client arrive sur une page web fournie par le routeur. On accède ainsi aux ressources : page web ou partage de fichier. Il est possible via JAVA d accéder à de plus amples services.

Un tunnel FullTunneling TLS/SSL

Avantages : accès à toutes les ressources du réseau, pas de soucis de pare feu.

Problèmes : nécessite l'installation d un software.

Le principe de ce tunnel est que le routeur devient transparent une fois le tunnel VPN actif, le client se retrouve dans la plage d adresse IP du LAN, ce qui lui donne accès à toutes les ressources disponibles.

Un tunnel FullTunneling IPsec

Avantages : accès à toutes les ressources du réseau

Problèmes : nécessite l'installation d un software /mise en place d'un routeur, difficulté à traverser des pare feu.

Les fonctionnalités sont identiques au FullTunneling TLS/SSL. Attention à ne pas s arracher les cheveux avec les pare feu, le NAT … c'est une vraie misère !!!! Le VPN utilise le protocole IPsec, la configuration est quasi-similaire à une tunnel site a site, profil ISAKMP et IPsec, attention cependant à X-AUTH.

Mise en pratique : WebVPN clientless TLS/SSL

Place a la configuration !!!

Nous allons dans ce topic configurer un tunnel entre une station client Seven et notre réseau d' entreprise. Le but est de pouvoir accéder au serveur IIS héberge sur une plate-forme 2012. Nous afficherons également un message bonjour aux utilisateurs qui se connectent au portail.

Dans un premier temps nous allons utiliser un self-signed certificate pour authentifier notre routeur auprès du client. Cette méthode requiert très peu de configuration, cependant, elle n'est pas la plus sûre (vous verrez pourquoi dans la suite),

Voici la configuration de la passerelle (ici R6) :

Ssl trustpoint pointe vers notre self-signed certicate

Pour info, le trustpoint associé est visible via un show run classique :

Inservice va activer la fonctionnalité WebVPN

On peut changer les paramètres des protocoles utilises en utilisant la commande ssl encryptions

Passons maintenant à la configuration des context et des policies.

Un context, lié à une passerelle, va contenir plusieurs policies qui vont être appliquées aux utilisateurs qui tentent de se connecter. On peut citer « comment authentifier l utilisateur », « quels bookmarks vont apparaître sur notre passerelle », …

Dans mon exemple nous allons utiliser la manière la plus simple d'authentifier un utilisateur, en utilisant la base locale de notre routeur. Dans un prochain topic, nous utiliserons notre AD pour effectuer cette tache.

Tout d abord la création du context

Ici, on lie notre contexte à notre passerelle. Nous l'activons via la commande inservice.

Les polices.

Chose à savoir : il existe une police par défaut. On peut appliquer une police en se basant sur des RADIUS-Assigned Session Attributes. Ceci sera développé dans un prochain topic, conjointement avec la mise en place d'une authentification des users via AD.

Voici la configuration :

Création dans un premier temps d' un utilisateur sur notre routeur avec les privilèges les plus bas.

Attention à ne pas donner de droits d administrations !!!!

Nous configurons dans un second temps l'accès au routeur via un aaa new-model et une authentication locale (ici nommée VPN). Attention à bien en créer une spécifique à l'accès WEBVpn, n'utiliser pas celle par défaut.

En fonction de l'IOS qui tourne sur le routeur, le résultat d'un show run va être différent. Si j'applique par exemple mon aaa authentication list VPN dans ma police par défaut, le résultat s'affichera directement sous le context.

Le grand test !

Avec le navigateur de votre choix, accéder à votre WEBVpn via https. Ici l'adresse configurée est 212.49.64.2

Constat : le navigateur affiche une erreur de sécurité, il ne peut pas vérifier le certificat affiché par le routeur !

Nous entrons maintenant sur le portail en utilisant notre compte utilisateur sans droit créé précédemment.

Nous n'avons créer aucun bookmarck, ce sera pour un prochain topic. Néanmoins nous pouvons naviguer dans notre LAN. Mon serveur IIS a pour adresse 192.168.1.100, je tape celle-ci dans le champs URL. ET là, la magie du VPN opère : nous nous connectons sur notre serveur à travers le routeur, pour preuve, checker l'URL dans la barre de navigation !

Moui, c'est un peu petit pour voir l'URL : https://213.49.64.2/http:/0/192.168.1.100/

Bon clic à tous,