Cisco ASA – VPN Remote Access IPsec

Dans cet article nous verrons comment configurer un VPN Remote Access IPsec, permettant à des clients de se connecter à distance au réseau local de l’ASA. Contrairement à l’AnyConnect qui repose sur SSL, celui-ci utilise l’IPsec, comme son nom l’indique. La solution possède des avantages et des inconvénients. La raison principale du choix d’un VPN Remote Access plutôt qu’un AnyConnect est le coût des licences.

Voyons comment mettre en place cette solution.

 Configuration

 Comme toujours pour les VPN, le plus simple est d’utiliser le Wizard pour la première configuration.

Il est possible d’utiliser une authentification par clé partagée ou par certificat. Le plus simple est d’utiliser la clé partagée. L’authentification par certificat est bien entendu la méthode la plus sécurisée.

L’authentification peut se faire à l’aide de la base d’utilisateur locale ou bien à l’aide d’un serveur d’authentification.

Il convient ensuite de définir un pool DHCP pour les clients.

Le NAT exempt permet de choisir le ou les réseaux locaux à exposer, si ceux-ci sont normalement natés lors d’une communication vers l’extérieur. Il est possible de modifier cette configuration par la suite depuis l’écran de paramétrage du NAT (notamment si d’autres réseaux doivent être exposés).

Enfin, il est possible d’activer le Split Tunneling.

Sans Split Tunneling, tout le trafic du client est envoyé dans le VPN. C’est-à-dire que même le trafic à destination d’internet remonte dans le VPN, pour ressortir par l’ASA.

Cela peut être intéressant pour sécuriser la connexion.

Test du VPN

 La configuration est à présent terminée.

 Le client IPsec Cisco n’étant plus maintenu, il est peut être nécessaire de se tourner vers une autre solution.

Ici je vous propose la configuration du client ShrewVPN permettant de se connecter au VPN précédemment configuré.

Troubleshooting et configuration additionnelle

Enfin, si vous ne parvenez pas à initier le VPN, ou si vous souhaitez modifier certains paramètres, je vous invite à consulter la dernière partie de l’article sur le VPN Any Connect. Les explications s’appliquent aussi pour le VPN IPsec.

Principes de la sécurisation des connexions dans un réseau câblé, par authentification de l'utilisateur et affectation dynamique au VLAN. Protocole 802.1x. (Source http://www.reseaucerta.org)

Cet article vise à la découverte des principes et techniques associés à l'authentification des connexions dans les réseaux câblés Ethernet. En particulier, il traitera du protocole 802.1x et des serveurs d'authentification RADIUS associés.
Si les réseaux Wifi utilisés dans les entreprises voient désormais leurs accès relativement sécurisés (par du chiffrement WPA2 par exemple) et si les accès depuis l'Internet font l'objet de technologies sécuritaires bien établies (DMZ, pare-feux, UTM ...), les prises murales sur lesquelles sont connectés les postes fixes des espaces de travail sont, dans la majorité des entreprises, "ouvertes à tous les vents" et toute personne circulant dans l'entreprise peut s'y connecter et s'introduire sur tout ou partie du réseau.
L'objectif final visé par la mise en place du couple de technologies 802.1x / RADIUS va au delà de la simple sécurisation des accès par une authentification "forte" de la personne qui cherche à se connecter sur un port réseau. Cet objectif pourra aller jusqu'à la banalisation de toutes les prises réseau filaires de l'entreprise. Une prise réseau quelconque ne sera plus affectée à tel ou tel VLAN. C'est à partir de l'authentification de la personne qui cherche à se connecter au réseau que l'on va déduire le périmètre de sécurité dans lequel la placer :

• Un refus pur et simple de connexion : aucun placement ;
  
• Le placement dans un VLAN invité ("guest") avec des prérogatives minimales,
  comme la simple obtention d'une adresse IP et d'un accès à Internet ;
  
• Le placement dans un VLAN dédié, choisi en fonction notamment du service
  ou du groupe auquel appartient la personne ;
  
• 
  

Le placement dans un VLAN à prérogatives importantes, comme un VLAN

d'administration. 

Il existe des technologies de filtrage sur les adresses MAC : soit circonscrites à un commutateur (doté pour chacun de ses ports, d'une liste d'adresses MAC autorisées) ou même centralisées dans un serveur RADIUS. On sait maintenant que l'adresse MAC n'est plus un élément d'authentification fiable. Pour cette raison et pour le côté malaisé de la manipulation, et surtout de la récupération des adresses MAC (particulièrement quand il s'agit de postes appartenant à des personnes extérieures à l'entreprise), on laissera ces technologies de côté dans ce document. 

I. Principes généraux de l'authentification 802.1x

De façon imagée, l'utilisateur qui veut entrer sur le réseau va s'adresser à un "gardien" (un équipement de réseau) qui lui demande alors de décliner son identité, qui va vérifier, auprès d'un poste de sécurité central, que l'on peut effectivement le laisser entrer et qui prendra connaissance des prérogatives qui seront accordées à l'utilisateur après son admission. 

L'ordinateur sur lequel un utilisateur cherche à se connecter au réseau est appelé le "supplicant". Il est le "client final" de la demande de connexion. Ce peut-être avec toute forme de terminal portable, de téléphone IP ou d'ordinateur fixe. Dans la suite, nous garderons l'expression française "client final" à la place de "supplicant". L'équipement de réseau sur lequel le client final se connecte (un commutateur - ou une borne Wifi - compatible 802.1x) relaye, en tant que client RADIUS, cette demande de connexion à un serveur d'authentification, le serveur RADIUS, qui va, par exemple, identifier la personne en rapprochant le nom de connexion et le mot de passe de ceux stockés dans un annuaire LDAP ou encore une base de données SQL.

Si l'identification réussit, l'accord est transmis au client RADIUS qui "ouvrira" alors le port de connexion.

Synonymes des termes désignant les acteurs de la connexion 802.1x : 

Supplicant : on trouve aussi les expressions "client demandeur" ou "client final".
Serveur d'authentification : on parle quelquefois de serveur d'identification.
Client RADIUS : on trouve également les synonymes suivants : "Authenticator" ou NAS (Network Access Server) ou encore "contrôleur d'accès"

I.2 Le protocole 802.1x 

Le protocole 802.1x est une solution standard de sécurisation de réseaux mise au point par l'IEEE en 2001.
802.1x permet d'authentifier un utilisateur souhaitant accéder à un réseau (câblé ou Wifi) grâce à un serveur central d'authentification. L'autre nom de 802.1x est "Port-based Network Access Control" ou "User Based Access Control". 802.1x permet de sécuriser l'accès à la couche 2 (liaison de donnée) du réseau.

Ainsi, tout utilisateur, qu'il soit interne ou non à l'entreprise, est dans l'obligation de s’authentifier avant de pouvoir faire quoi que soit sur le réseau. Certains équipements de réseau compatibles 802.1x peuvent réserver un traitement particulier aux utilisateurs non authentifiés, comme le placement dans un VLAN "guest", une sorte de quarantaine sans danger pour le reste du réseau.

802.1x a recours au protocole EAP (Extensible Authentification Protocol) qui constitue un support universel permettant le transport de différentes méthodes d'authentification qu'on retrouve dans les réseaux câblés ou sans-fil. 802.1x nécessite donc la présence d'un serveur d'authentification qui peut être un serveur RADIUS : un serveur Microsoft, Cisco (...) ou un produit libre comme FreeRADIUS) ou encore un serveur TACACS dans le monde fermé des équipements Cisco.
Un port d'un commutateur réglé en mode 802.1x peut se trouver dans deux états distincts :

• État "contrôlé" si l’authentification auprès du serveur RADIUS a réussi. 
• État "non contrôlé" si l’authentification a échoué. 

La réussite ou l'échec de l'authentification va donc ouvrir ou fermer le port à toute communication. Un port ouvert va, par exemple, permettre au client final d'obtenir une adresse IP auprès d'un serveur DHCP. Dans des implémentations plus cloisonnées, le serveur RADIUS indiquera par exemple au client RADIUS dans quel VLAN placer le client final.

I.3 RADIUS

RADIUS (acronyme de Remote Authentication Dial-In User Service) est un protocole client-serveur permettant de centraliser des demandes d'authentification relayées par des équipements de réseau, comme des commutateurs ou bornes Wifi, considérés alors comme ses clients. 

Par extension, un serveur qui centralise des demandes d'authentification et les soumet à un service d'annuaire LDAP ou à un service de base de données SQL est appelé serveur RADIUS.

RADIUS interroge une base de données d'authentification et d'autorisation qui peut être un domaine Active Directory, une base LDAP ou une base de données SQL. Ces bases ou annuaires peuvent se trouver sur le serveur lui-même ou sur un serveur tiers. Certaines implémentations de RADIUS disposent d'une base de données en propre. 

A l'origine, RADIUS était surtout utilisé pour l'identification des clients des FAI, ses capacités de comptabilisation des accès (accounting) permettant notamment la journalisation des accès et leur facturation. RADIUS a été utilisé par la suite en entreprise pour l'identification des clients finals WIFI et pour l'identification des clients finals câblés. 

• Rôles du serveur RADIUS 

En premier lieu, RADIUS doit authentifier les requêtes qui sont issues des clients finals, via les clients RADIUS.

 Cette authentification se basera soit sur un couple identifiant/mot de passe, soit sur un certificat. Cela dépendra du protocole d'authentification négocié avec le client final. 

En deuxième lieu, RADIUS a pour mission de décider quoi faire du client authentifié, et donc de lui délivrer une autorisation, un "laissez-passer". Pour ce faire, RADIUS envoie des informations (on parle "d'attributs") aux clients RADIUS. Un exemple typique d'attribut est un numéro du VLAN dans lequel placer le client authentifié et autorisé. 

Enfin, en bon gestionnaire, RADIUS va noter plusieurs données liées à la connexion, comme la date et l'heure, l'adresse MAC de l'adaptateur réseau du client final, le numéro de VLAN...). C'est son rôle comptable ou "d'accounting". RADIUS est donc un serveur d'authentification, d'autorisation et de comptabilité. 

De façon imagée, c'est le "chef d'orchestre" des connexions 802.1X et les clients RADIUS sont ses sbires... En ce sens, il se range dans le modèle AAA (Authentication, Authorization, Accounting).

 NPS (Network Policy Server) est le nom du service RADIUS des systèmes Microsoft Windows 2008 Server, en remplacement du "Service d'Authentification Internet" de Windows 2003 Server. D'autres solutions propriétaires existent, comme CISCO ACS (Access Control Server). Différentes versions libres de RADIUS existent également, comme FreeRADIUS (sous Linux ou Windows) ou OpenRADIUS (sous Linux). 

RADIUS peut aussi servir à centraliser les accès sécurisés aux pages ou aux terminaux de paramétrage de tous les équipements réseau : commutateurs, routeurs, bornes wifi, contrôleurs wifi, etc.

I.4 Le client RADIUS 

Dans le schéma général d'une connexion 802.1x, l'élément central est l'équipement de réseau (commutateur, borne wifi, ...) désigné comme client RADIUS. Cet équipement doit donc être en capacité de gérer le protocole 802.1x et le protocole d'authentification EAP. 

I.5 Le client final (ou supplicant)

Depuis Windows XP-SP3, les systèmes d'exploitation Microsoft disposent d'une couche "supplicante" logicielle 802.1x. Les distributions Linux disposent de paquetages comme "Xsupplicant". Dans Windows, pour activer cette couche logicielle, il faut lancer le service de configuration automatique de réseau câblé.

Commentaire associé à ce service:

 "Le service Wired AutoConfig (DOT3SVC) est responsable de l’exécution de l’authentification IEEE 802.1X sur les interfaces Ethernet. Si votre déploiement de réseau câblé actuel applique l’authentification 802.1X, le service DOT3SVC doit être configuré de façon à s’exécuter pour l’établissement de la connectivité de Couche 2 et/ou fournir l’accès aux ressources réseau. Les réseaux câblés qui n’appliquent pas l’authentification 802.1X ne sont pas concernés par le service DOT3SVC." 

La mise en route du service provoque l'apparition de l'onglet [Authentification] dans les propriétés de la carte réseau.

Signification des coches 

• "Revenir à un accès réseau non autorisé" 

On coche cette option si on veut que, dans le cas où le système du client final ne répondrait plus aux règles (de pare-feu, de mises à jour système, d'antivirus), sa connexion soit coupée. Ces règles d'acceptation font partie des exigences que l'on peut paramétrer dans le service RADIUS Microsoft NPS.

 "Mémoriser mes informations d'identification..." 

Mise en cache du couple identifiant/mot de passe. Cette mise en cache peut être intéressante pour une machine non intégrée dans un domaine, pour éviter de devoir se ré-authentifier. Pour nos TP, il est plus utile, pour observer ce qui se passe, de décocher cette option. Un poste intégré dans un domaine pourra utiliser les informations d'ouverture de session Windows pour l'authentification 802.1x. Ce ne sera pas demandé une seconde fois. Ouvrons l'écran des propriétés EAP protégées en cliquant sur [Paramètres] à côté du choix [Microsoft PEAP (Protected EAP]

 "Valider le certificat du serveur" 

Cette coche n'est pas utile dans notre cas. Dans la méthode d'authentification, 

on va utiliser "EAP-MSCHAP version 2".

Note : c'est par le bouton [Configurer] de l'écran ci-dessus qu'on indique si on veut utiliser - ou non - le nom et le mot de passe d'ouverture de session Windows dans le dialogue 802.1x.

Dans les phases de test, on peut relancer le mécanisme d'authentification en désactivant/réactivant la carte réseau, mais tout le dialogue ne serait pas visible dans un analyseur de trames. Il vaut mieux décocher/cocher "Activer l'authentification 802.1X" pour observer tout ce qui se passe.

I.6 Les protocoles d'authentification 

EAP est la couche protocolaire de base de l'authentification. Elle va servir à faire passer un dialogue d'authentification entre le client final et le serveur RADIUS alors que le port de connexion est fermé à toute autre forme de communication.
C'est un protocole extensible, au sens où il va permettre l'évolution de méthodes d'authentification transportées, de plus en plus sûres au cours du temps.

Quelles ont été - et quelles sont - ces méthodes d'authentification ?

Le premier protocole a été PAP (Password Authentification Protocol) avec lequel les mots de passe circulaient en clair. La sécurité proposée par ce protocole est faible.

Le second protocole qu'ont utilisé les serveurs RADIUS a été CHAP (Challenge Handshake Authentication Protocol). Il est défini dans la RFC 1994. Avec CHAP, il n'y a pas d'échange de mots de passe sur le réseau.

Les deux interlocuteurs, qui disposent donc de la même chaîne de caractère secrète, s'authentifient sans échange du mot de passe par une technique de "challenge" (ou "défi") basée sur une fonction de hachage à sens unique du secret partagé, telle que MD5. Cette méthode était disponible avec le couple XP/Windows-2003-Server, mais ne l'est plus en génération Seven/2008.

Au début de la connexion, le serveur réclame la preuve de l’identité du client, en lui demandant de chiffrer une information. Le client ne peut relever le défi que s’il possède effectivement la clé unique et secrète partagée. Dialogue client-serveur avec CHAP

 A. Après l'établissement de la connexion, l'authentificateur envoie une valeur aléatoire xxxxxx au client.
B. Le client concatène cette valeur xxxxxx au secret partagé, applique une fonction de hachage (telle que MD5) sur la chaîne obtenue et retourne le résultat.
 C. Le serveur effectue la même opération et compare avec le résultat reçu. La connexion n'est acceptée que si le résultat est identique.
D. A intervalle régulier, il y a un nouveau défi à relever pour pérenniser la connexion.

Microsoft a développé une variante de CHAP appelée MS-CHAP qui ajoute une authentification mutuelle, MSCHAP-V1, puis MSCHAP-V2. Dialogue client-serveur avec MSCHAP-V2.

A. Le serveur envoie au client une chaîne composée d'un identifiant de session et une chaîne aléatoire xxxxx.
B. Le client renvoie son nom d'utilisateur et le résultat d'un hachage de la chaîne aléatoire xxxxx + l'identifiant de session + le mot-de-passe, et une seconde chaîne aléatoire yyyyy.
C. Le serveur vérifie le résultat (succès/échec) et retourne celui-ci, avec un hachage de la chaîne yyyyy et du mot de passe utilisateur.
D. Le client vérifie enfin la correspondance entre les chaînes.
E. La connexion est établie

Articulation EAP / PEAP / MSCHAP-V2 

• EAP est le mécanisme permettant à un client final de pouvoir communiquer sur un port 802.1x fermé à toute autre forme de communication. 
• PEAP ajoute la notion de protection des échanges par tunnel à ce mécanisme 
• MSCHAP est la méthode de reconnaissance mutuelle du client serveur et du serveur RADIUS qui passe par ce tunnel.

I.7 Les différentes phases (simplifiées) d'une connexion 802.1x 

Au démarrage de la communication, le client final est prié d'envoyer ses identifiants au serveur RADIUS. Or, à ce moment là, le client final ne connaît pas l'adresse du - ou des - serveurs RADIUS du réseau. Il ne dispose peut-être même pas d'adresse IP. 

De même, le port du commutateur sur lequel il est connecté est censé être fermé (état non contrôlé). En réalité, le port contrôlé du commutateur n'est pas totalement fermé. Il va laisser passer le protocole EAP (Phase 1 sur le schéma suivant). Cette communication ne peut donc se faire que par des trames Ethernet de base et non par des paquets IP.

Le client final peut donc envoyer son identité dans un paquet EAP au commutateur. 

Celui-ci le retransmet, encapsulé dans un paquet au format RADIUS, au premier serveur RADIUS de sa liste (s'il en connaît plusieurs) (Phase 2).

Le serveur RADIUS reçoit le paquet et interroge sa base de données (Phase 3). Il renvoie le résultat de cette interrogation au commutateur (Phase 4), sous forme d'un commandement d'ouverture du port, éventuellement assorti d'un numéro de VLAN dans lequel placer le client final. 

A partir de ce moment seulement, il peut y avoir d'autres trames échangées entre le client final et le reste du réseau, comme une trame de requête DHCP par exemple. 

Avant authentification

                                       Le port ne laisse passer que des trames EAP.

Après authentification

                                        Le port laisse passer tous les types de trames.

Conséquence de ce fonctionnement général. 
L'équipement réseau ne connaît que le protocole RADIUS. Le protocole d'authentification entre le client final et le serveur RADIUS pourra varier sans que cela soit un blocage pour l'équipement. En ce sens, on dit que le client RADIUS est "transparent".

I.8 Et que faire des périphériques non 802.1x ? 

L'objectif de contrôler toutes les prises réseau d'une entreprise en y imposant une authentification peut se heurter au fait que certains périphériques qui y sont connectés (comme des imprimantes, des vidéoprojecteurs ...) n'implémentent pas 802.1x. Il faut donc trouver d'autres solutions pour protéger ces prises : un VLAN spécifique par exemple réunissant les imprimantes, avec un serveur d'impression situé dans un autre VLAN joignable au travers d'un routeur filtrant, une protection des ports par adresse MAC, ou encore une connexion sans-fil des vidéoprojecteurs dans une technologie de cryptage comme WPA2.

II. Fonctionnement détaillé

Étape 1 - identité externe 

1.1 L'équipement demande au client final de décliner son identité (trame EAPRequest-Identity)

 1.2 Le client répond par une trame EAP contenant son nom d'utilisateur (trame EAP-Response-Identity). Ca tombe bien, les trames EAP sont les seules autorisées à entrer dans l'équipement. L'équipement fabrique un paquet IP [access-request] encapsulant la trame [EAPresponse-Identity]. Il ajoute d'autres informations comme l'adresse MAC du client final. Ce paquet IP est envoyé au serveur RADIUS.

Étape 2 - Négociation de protocole. 

Le serveur RADIUS reçoit le paquet [Access-Request] et fabrique un paquet [Access-challenge] encapsulant une trame [EAP-Request] contenant une proposition de protocole d'identification, comme PEAP. 

L'équipement décapsule le paquet pour transmettre la trame EAP au client final.

 Le client final répond dans une trame [EAP-response] transmis de la même manière - indirecte par encapsulation - au serveur RADIUS. 

Le client et le serveur étant tombés d'accord sur le protocole d'authentification, on passe à l'étape suivante.

Étape 3 - TLS handshake 

Le serveur RADIUS envoie au client une requête de démarrage [PEAP-START] toujours par le mécanisme d'encapsulation d'une trame EAP. 

Le client final répond par un message [client hello] avec la liste des algorithmes de chiffrement qu'il connait. 

Le serveur envoie son choix d'algorithme, ainsi que son certificat et sa clé publique au client final. Le client final authentifie le serveur. Il génère une "pré-master-key" avec la clé publique du serveur. 

Le serveur fait de même et un tunnel chiffré est établi entre eux. 

Le tunnel sert à protéger l'échange du mot de passe par rapport à une authentification EAP simple. 

Rappel : le client final n'a pas de certificat (PEAP). Attention, bien qu'on utilise TLS, on n’est pas dans "EAP-TLS", méthode utilisant des certificats serveur et client. Étape 4 - TLS record Les échanges liés au protocole de validation du mot de passe vont être effectués dans le tunnel TLS. Avec MSCHAP-V2, il s'agit des échanges vus au point I.7. Le port s'ouvre lorsque le serveur envoie au client final un message [Access-Accept] après avoir vérifié le mot de passe de l'utilisateur et s'être assuré de ses autorisations.

III. Un exemple d'infrastructure 802.1x 

Le serveur RADIUS est connecté dans le VLAN 1 du commutateur, sur le port FA1 par exemple. Il héberge à la fois AD, un service de certificats et le service NPSRADIUS. Le client final "A" est connecté au port n°7 "contrôlé" par 802.1x du commutateur. Son VLAN dépendra de l'authentification de l'utilisateur. Un second client final "B" pourra être connecté sur un port non contrôlé du VLAN 2 ou du VLAN 3 pour vérifier la connectivité intra VLAN 2 ou 3. Dans un premier temps, on peut effectuer nos tests avec des IP fixes sur les postes clients. 

Pour mettre les clients en DHCP, il faudrait disposer d'un service DHCP dans chaque VLAN. Ceci pourrait être fait en connectant un routeur sur un port 802.1q du commutateur. Ce routeur servirait des plages DHCP dans chaque VLAN de travail et même dans le VLAN "guest".

Les paramétrages à effectuer concernent le client final, le client RADIUS et le serveur RADIUS sur lequel on trouve déjà un annuaire Active Directory.

 1. Configurer le client final en 802.1x 

• Service Configuration automatique de réseau câblé 
• Onglet "Authentification" des propriétés de la carte réseau 

2. Paramétrer le commutateur Client RADIUS 

• Création des VLAN 
• Paramétrage général 802.1x - déclaration du serveur RADIUS 
• Paramétrage des ports contrôlés 802.1x avec gestion des accès refusés (placement en VLAN "guest"). 
• Paramétrage des ports utiles non contrôlés 

3. Installation de deux nouveaux services sur le serveur Windows 2008 

• Installation d'une autorité de certification 
• Installation du service NPS - Serveur RADIUS 

4. Paramétrage du service NPS 

• Déclaration d'un client RADIUS : le commutateur 
• Déclaration d'une stratégie de connexion 
• Déclaration d'une stratégie d'accès réseau

III.1 Mise en place du 802.1x dans un commutateur Cisco SF-300 

III.1.1 Cartographie des VLAN 

• VLAN 1 : administration. Le serveur RADIUS est connecté dans le VLAN 1 

• VLAN 2 et 3 : VLAN de travail pour l'affectation dynamique 

• VLAN 99 : VLAN guest (quarantaine des clients non authentifiés)

III.2 Authentification 802.1x dans un commutateur Cisco 2960 

III.2.1 Mise en place de l’authentification 802.1x sur le commutateur A 

- Définir un nouveau modèle d’authentification 

(config)#aaa new-model 

(config)#aaa authentication dot1x default group RADIUS 

(config)#aaa authorization network default group RADIUS 

(config)#dot1x system-auth-control 

B - Définir les informations d’accès au serveur RADIUS 

(config)#RADIUS-server host IpRADIUS auth-port 1812 acct-port 1813 key PwdClientRADIUS 

Exemple: (config)# RADIUS-server host 172.16.0.1 auth-port 1812 acct-port 1813 key toto 

III.2.2 Configuration des ports 

A - Définir l’authentification 802.1x sur un port (mode configuration d’interface) 

(config-if)#switchport mode access 

(config-if)#authentication port-control auto 

(config-if)#dot1x pae authenticator 

B - Éventuellement, affecter le port à un VLAN invité si le poste ne supporte pas le 802.1x 

(config-if)#authentication event no-response action authorize vlan xx 

Exemple: (config-if)#authentication event no-response action authorize vlan 99 

C-Éventuellement, affecter le port à un VLAN xx si l’authentification 802.1x a échoué (config-if)#authentication event fail action authorize vlan xx 

Exemple : (config-if)#authentication event fail action authorize vlan 100 

III.2.3 Relancer l’authentification sur un port particulier

 - Relancer la phase d’authentification 802.1x sur un port 

Switch#dot1x re-authenticate interface f0/1 

III.2.4 Afficher des informations sur l’authentification 802.1x 

Switch#dot1x initialize interface f0/1 

Switch#dot1x test eapol-capable interface f0/1 

Switch#show dot1x all Switch#show authentication interface f0/1

III.2 Mise en place du serveur RADIUS NPS

 La mise en place du service RADIUS NPS sur un serveur Windows 2008-R2 se fait en plusieurs phases. Le serveur est un contrôleur de domaine. Il dispose donc du service Active Directory et de plusieurs utilisateurs et groupes d'utilisateurs. Notre objectif va être d'accepter les connexions 802.1x des utilisateurs qui font partie d'un certain groupe AD et de les placer dans le VLAN 2. Une autre stratégie pourra être de placer les utilisateurs authentifiés d'un autre groupe dans le VLAN 3, etc. 

Les attributs qui vont être délivrés par le serveur RADIUS en cas d'authentification sont les suivants :

 • Tunnel-Type : positionné sur "VLAN" 

• Tunnel-Medium-Type : positionné sur "802" 

• Tunnel-Pvt-Group-ID : positionné sur le n° de VLAN de placement La mise en œuvre de cette partie est décrite dans le document joint "installation-et configuration-nps". 

Note sur NPS 

NPS permet également de mettre en place des règles d'accès réseau portant également sur la "propreté" des clients finals, en termes de mises à jour systèmes, de pare-feux, d'état de l'antivirus, etc.
 Ceci permet de n'accepter sur le réseau que les postes qui présenteraient des garanties de non pollution du reste du réseau.

Protocoles de transition IPv6 : 6to4

Introduction

Comme vous le savez, nous sommes « à court » d’IPv4 publiques depuis le début de l’année.

Autant dire que cet évènement va, je l’espère, accélérer la transition inéluctable vers une architecture plus portée vers l’IPv6.

Maintenant vous pouvez vous poser la question légitimement, comment passer « en douceur » à l’IPv6 sans forcément bannir IPv4 de votre réseau interne et externe et remettre en question votre architecture entière.

C’est là où les protocoles de transition rentrent en jeu et notamment celui que nous allons voir dans ce post : 6to4.

6to4

Le postulat de ces protocoles de transition reste assez simple. Il s’agit de permettre à du traffic de type IPv6 de passer à travers un réseau IPv4 classique. Cela est rendu possible grâce au routeur qui encapsule notre paquet IPv6 dans la zone de données du paquet IPv4(c’est-à-dire le payload) et ainsi l’envoyer à travers un réseau IPv4 dans perdre aucune information IPv6.

Remarquez que l’on pourra aisément distinguer ce type de paquet grâce au Type 41 dans le header de notre paquet IPv4.

6to4 va vous permettre d’établir des tunnels de type point-to-multipoint de façon totalement dynamique.
La force de cette technologie est de pouvoir par exemple, ajouter 100 routeurs dans votre topologie sans pour autant remettre en cause la configuration de vos routeurs existants puisque tout s’établit de façon dynamique!
Ce protocole utilise la range 2002::/16 pour pouvoir fonctionner.

L’inconvénient principal néanmoins de 6to4 est qu’il ne prend pas en charge les IGP, ce qui n’est pas nécéssairement un problème si vous restez dans un environnement 6to4.

Topologie type

Voici la topologie sur lequel notre exemple va se baser:

Ce schéma mérite explication sur de nombreux points que je vais aborder dans la prochaine partie.

Mise en place

Vous avez plusieurs étapes à effectuer pour pouvoir mettre en place cette technologie.

Première étape: choisir des adresses IPv4 de loopback pour les routeurs

Celle-ci n’est pas compliquée en soit mais vous pouvez vous demander pourquoi choisir de définir des IPs de loopback plutôt que des IPs d’interfaces. L’avantage principal de ce choix nous permettra de nous affranchir du possible dysfonctionnement d’une interface physique. Par définition, une interface de Loopback ne pourra jamais se retrouver en état down/down puisque c’est une interface virtuelle.

Deuxième étape: convertir ces adresses en héxadécimal

L’objectif dans cette partie est de créer un subnet général IPv6 qui reflètera notre IP de loopback configurée. Pour la convertir, nous allons partir de l’adresse de base 2002::/16 et y ajouter à la suite les 32 bits de l’adresse IP de loopback sur chaque routeur sous forme héxadécimale.

Ce qui nous donne pour 192.168.1.1 l’adresse IPv6 2002:C0A8:0101::/48.
Cette adresse permettra de pouvoir identifier l’adresse IPv4 de destination.

On applique cette règle sur les deux autres routeurs de la même façon.
Vous pouvez constater la traduction de ces adresses dans le schéma de topologie.

Troisième étape : subnetter le subnet /48 calculé

Une fois les subnets calculés, nous allons pouvoir nous en servir dans les interfaces du routeur. Remarquez que pour le routeur 192.168.1.1, on utilise le subnet 2002:C0A8:0101:1::/64 pour le LAN et 2002:C0A8:0101:0::/64 pour le WAN.

Configuration

Il ne nous reste maintenant qu’à configurer les routeurs pour que les tunnels commencent à se former automatiquement.

! Configuration R1 : 192.168.1.1
! On active le routage IPv6
R1(config)# ipv6 unicast-routing
! On configure notre interface de Loopback
R1(config)# int Loopback0
R1(config-if)# ip add 192.168.1.1 255.255.255.255
! On configure le tunnel
R1(config)# int tunnel 0
! Source : notre Loopback
! Pas de destination à spécifier ici, nous sommes sur du point-to-multipoint
R1(config-if)# tunnel source Loopback0
! On lui précise que le tunnel fera du 6to4
R1(config-if)# tunnel mode ipv6ip 6to4
! Adresse IP du tunnel
R1(config-if)# ipv6 add 2002:C0A8:0101:0::1/128
! Et on configure enfin notre interface LAN
R1(config)# int fa0/0
R1(config-if)# ipv6 add 2002:C0A8:0101:1::1/64
!
! Enfin une route pour déclencher notre tunnel et utiliser celui-ci en cas de sollicitation
R1(config)# ipv6 route 2002::/16 Tunnel0

Cette configuration sera bien entendu à reproduire sur les autres routeurs.

Examen du comportement final

Une fois cette configuration appliquée sur tous les routeurs, vos tunnels se formeront de façon systématique pour pouvoir contacter votre voisin même si il est en IPv6.

Mais comment avec cette configuration, comment le routeur déterminera t-il qu’il a besoin de faire passer l’information dans le tunnel et connaitre l’adresse IP de destination à utiliser?

1) Un PC connecté en IPv6 sur le LAN de R1 cherche à contacter un membre du LAN IPv6 2002:C0A8:0103:1::/64
2) Le routeur grâce à notre route statique routera tous les paquets à destination du tunnel 6to4(dans la range 2002::/16) vers l’interface Tunnel0.
3) Le routeur a besoin de connaitre en IPv4 l’adresse IP de destination. Vous remarquerez ici que le routeur à seulement besoin de convertir les bits de 17 jusqu’à 32 pour obtenir ici l’adresse IP de destination 192.168.1.3 !

Et voilà, vous avez(déjà) terminé la configuration de cette topologie.

J’espère que ce post vous aura plu et vous sera utile.
N’hésitez pas si vous avez des compléments à apporter et des commentaires.

QOS dans le LAN

Qos: Solution de téléphones IP

On trouve aisément des réponses dans le CVD Medianet Campus QoS Design 4.0 qui est la bible pour mettre en place la QoS dans le LAN. Une option élégante consiste à utiliser une fonction de « trust conditionnel ». On ne va prendre en compte le champ COS sur le VLAN voix que si l’on détecte un téléphone sur le port (via échange CDP). De son côté, cette commande pilote le téléphone pour remarquer tous les paquets venant du poste de travail avec un champ DSCP à 0. Je mets ci-dessous quelques exemples de configuration partiellement repris du CVD Medianet mentionné plus haut.

interface range GigabitEthernet 1/0/1-48
 switchport access vlan 10
 switchport voice vlan 110
 spanning-tree portfast
 mls qos trust device cisco-phone
 ! L'interface va être configurée pour truster ce qui vient du téléphone CISCO
 mls qos trust cos
 ! Si un téléphone CISCO est branché alors on truste le COS
 service-policy input PER-PORT-MARKING
 ! Application de la policy en entrée sur le port (non détaillée)

On peut également utiliser une autre méthode sans utiliser la fonction de trust conditionnel: on applique notre service-policy non plus au niveau du port mais au niveau du VLAN, et on s’arrange pour ne prendre en compte les marquages éventuels que pour le VLAN voix. Attention quand on met en place la QoS par VLAN: bien s’assurer que le policing reste par port ET par VLAN (on veut tout de même s’assurer que les niveaux de trafic voix restent conformes à ceux attendus sur chaque port et non pas en global). Pour cela on va utiliser des « nested class-maps » ou class-maps imbriquées.

Activation de la QoS globalement sur le switch:

mls qos

Configuration de la QoS par VLAN:

interface range GigabitEthernet 1/0/1-48
 switchport access vlan 100
 switchport mode access
 switchport voice vlan 110
 mls qos vlan-based

interface Vlan100
 service-policy input QOS_DATA_VLAN

interface Vlan110
 service-policy input QOS_VOICE_VLAN

Création des class-maps (on note les 2 niveaux qui seront imbriqués la première permet de repasser dans un mode par port ET par VLAN, l’autre pour matcher les flux générés par les téléphones):

class-map match-all access-ports-1
 match input-interface  GigabitEthernet1/0/1 - GigabitEthernet1/0/48

class-map match-all VOICE
 match dscp ef

class-map match-all SIGNALING
 match dscp cs3

A ce stade dans le cas où on va stacker des équipements il faut faire autant de classes pour les ports d’accès que de chassis dans le stack. On pourra donc rajouter pour un 2nd châssis:

class-map match-all access-ports-2
 match input-interface  GigabitEthernet2/0/1 - GigabitEthernet2/0/48

Et enfin les policy-maps: pour le VLAN voix on va prendre en compte le champ DSCP, par contre sur le VLAN DATA on remarque bêtement tout à 0 (là aussi on voit les policy-maps imbriquées: la policy map au niveau du VLAN va appliquer des autres policy-maps qui feront le policing sur les différents flux). J’ai repris ci-dessous l’exemple avec 2 châssis dans le stack, il est alors nécessaire d’appeler toutes les class-maps listant les ports des différents modules du stack (access-ports-1 et access-ports-2 ici)

policy-map QOS_VOICE_VLAN
 class VOICE
  set dscp ef
  service-policy police_128k_vvlan
 class SIGNALING
  set dscp cs3
  service-policy police_32k_vvlan
 class class-default
  set dscp default

policy-map QOS_DATA_VLAN
 class class-default
  set dscp default

policy-map police_32k_vvlan
 class access-ports-1
  police 32000 8000 exceed-action drop
 class access-ports-2
  police 32000 8000 exceed-action drop

policy-map police_128k_vvlan
 class access-ports-1
  police 128000 8000 exceed-action drop
 class access-ports-2
  police 128000 8000 exceed-action drop

communications unifiées, vidéo et voix sur poste de travail

Ca se corse: on a des flux voix sur le téléphone mais également des flux multimédia depuis le poste de travail. Comment arriver à traiter de manière homogène ces flux sans faire exploser les configurations des équipements? Rappelons-nous que le client souhaite une configuration homogène sur tous les ports d’accès.

Et là il faut admettre que cela pourrait être plus clair… On a une première question pour laquelle on n’a pas de réponse immédiate: « Faut-il se baser sur le DSCP envoyé par l’application ou non? ». La section « QoS » de la seconde référence n’est pas tout à fait a jour et ne tient pas compte des nouveautés sur CUPC (Cisco unified Personal Communicator) et des les évolutions de Windows:

• CUPC a maintenant évolué et il est possible depuis la version 8.5(5) de distinguer les ports UDP utilisés pour la voix et la vidéo
• Windows 7 remarque tous les paquets émis par l’application avec un DSCP à 0. Il est cependant possible sur l’OS de définir des règles statiques pour remarquer des flux spécifiques pour une application donnée avec le DSCP souhaité

Donc en se basant sur les ports UDP utilisés on va pouvoir faire la distinction vidéo/voix sur l’OS ou sur le switch pour marquer les paquets en fonction du type de flux. Alors quelle est la différence entre les 2 approches? Et bien quand un paquet arrive sur le switch, ce dernier ne peut pas être certain que l’application utilisée est réellement CUPC! Si la classification se fait sur le switch, on risque donc de mettre dans la classe « Voix – DSCP 46 » ou « Vidéo SD – DSCP 34 » du trafic non généré par l’application CUPC. Une chose est sûre: pour les 2 approches, on ne va pas accepter tout et n’importe quoi dans chaque classe: des policers nous permettront de protéger le réseau d’un trafic EF trop important. Seul l’usager qui utilisera une application non conforme sera impacté et les 2 solutions sont donc envisageables.

Option 1: on se base sur le DSCP entrant (ici on aura précédemment configuré l’OS du poste de travail pour faire le marquage approprié)

Je repars de la configuration précédente (ingress QoS par port ET par VLAN). J’ajoute simplement des règles sur le VLAN DATA pour faire la classification appropriée pour les flux voix et vidéo (flux multimédia et signaling). Je définis donc 3 nouvelles ACL et class-maps:

ip access-list extended QoS-DSCP-EF
 permit udp any any range 16384 24575 dscp 46
 permit udp any range 16384 24575 any dscp 46

ip access-list extended QoS-DSCP-CS3
 remark SCCP
 permit tcp any any range 2000 2002 dscp 24
 permit tcp any range 2000 2002 any dscp 24
 remark SIP
 permit tcp any any range 5060 5061 dscp 24
 permit tcp any range 5060 5061 any dscp 24

ip access-list extended QoS-DSCP-AF41
 permit udp any any range 24576 32767 dscp 34
 permit udp any range 24576 32767 any dscp 34
 permit udp any any 5445 dscp 34
 permit udp any 5445 any dscp 34

class-map match-all VOICE
  match access-group name QoS-DSCP-EF

class-map match-all SIGNALING
  match access-group name QoS-DSCP-CS3

class-map match-all VIDEO
  match access-group name QoS-DSCP-AF41

Je rajoute également mes nouveaux policers (flux voix sur le VLAN Data ainsi que flux vidéos). Je continue de donner un exemple avec un stack de 2 switchs de 48 ports GE chacun. Il est nécessaire de faire appel à des policers distincts car on peut tout à fait imaginer que 2 appels soient faits sur le même port du switch: l’un depuis le téléphone et l’autre depuis le poste de travail.

policy-map police_32k_dvlan
 class access-ports-1
  police 32000 8000 exceed-action drop
 class access-ports-2
  police 32000 8000 exceed-action drop

policy-map police_128k_dvlan
 class access-ports-1
  police 128000 8000 exceed-action drop
 class access-ports-2
  police 128000 8000 exceed-action drop

policy-map police_1M_dvlan
 class access-ports-1
  police 1000000 31250 exceed-action drop
 class access-ports-2
  police 1000000 31250 exceed-action drop

policy-map police_1M_vvlan
 class access-ports-1
  police 1000000 31250 exceed-action drop
 class access-ports-2
  police 1000000 31250 exceed-action drop

Et j’appelle ces nouvelles class-maps dans mes policy-maps précédentes:

policy-map QOS_VOICE_VLAN
 class VOICE
  set dscp ef
  service-policy police_128k_vvlan
 class SIGNALING
  set dscp cs3
  service-policy police_32k_vvlan
 class VIDEO
  set dscp af41
  service-policy police_1M_vvlan
 class class-default
  set dscp default

policy-map QOS_DATA_VLAN
 class VOICE
  set dscp ef
  service-policy police_128k_dvlan
 class SIGNALING
  set dscp cs3
  service-policy police_32k_dvlan
 class VIDEO
  set dscp af41
  service-policy police_1M_dvlan
 class class-default
  set dscp default

Option 2: on se base uniquement sur les ports UDP pour les flux venant du poste de travail

Ici la seule difficulté est que si l’on ne souhaite pas utiliser le champ DSCP venant du poste de travail, on veut quand même faire la classification des flux du VLAN voix en utilisant les infos fournies par le téléphone (c’est quand même plus simple!)

On peut donc définir nos classes de manière différenciées pour le VVLAN et le DVLAN, et on n’aura plus le champ DSCP dans les ACL définissant les flux sur le VLAN Data, en revanche on ne se basera que sur ce champ pour répertorier ce qui vient du téléphone:

ip access-list extended QoS-DSCP-EF
 permit udp any any range 16384 24575
 permit udp any range 16384 24575 any

ip access-list extended QoS-DSCP-CS3
 remark SCCP
 permit tcp any any range 2000 2002
 permit tcp any range 2000 2002 any
 remark SIP
 permit tcp any any range 5060 5061
 permit tcp any range 5060 5061 any

ip access-list extended QoS-DSCP-AF41
 permit udp any any range 24576 32767
 permit udp any range 24576 32767 any
 permit udp any any 5445
 permit udp any 5445 any

class-map match-all VOICE_VVLAN
 match dscp ef

class-map match-all SIGNALING_VVLAN
 match dscp cs3

class-map match-all VIDEO_VVLAN
 match dscp af41

class-map match-all VOICE_DVLAN
 match access-group name QoS-DSCP-EF

class-map match-all SIGNALING_DVLAN
 match access-group name QoS-DSCP-CS3

class-map match-all VIDEO_DVLAN
 match access-group name QoS-DSCP-AF41

Il reste à appeler les class-maps depuis les policy-maps appliquées sur les VLANs.

policy-map QOS_VOICE_VLAN
 class VOICE_VVLAN
  set dscp ef
  service-policy police_128k_vvlan
 class SIGNALING_VVLAN
  set dscp cs3
  service-policy police_32k_vvlan
 class VIDEO_VVLAN
  set dscp af41
  service-policy police_1M_vvlan
 class class-default
  set dscp default

policy-map QOS_DATA_VLAN
 class VOICE_DVLAN
  set dscp ef
  service-policy police_128k_dvlan
 class SIGNALING_DVLAN
  set dscp cs3
  service-policy police_32k_dvlan
 class VIDEO_DVLAN
  set dscp af41
  service-policy police_1M_dvlan
 class class-default
  set dscp default

Envie de simplification ?

Ca tombe bien, « auto qos », qui existe depuis déjà quelque temps pour les flux téléphoniques a été adapté sur la gamme 3k pour la gestion de la vidéo en suivant les recommandations décrites dans leMedianet Campus QoS Design 4.0. En quelques lignes de commande on peut appliquer des règles basiques pour les différents cas de figure. Par exemple on pourrait dans le cas précédent gérer le problème en quelques lignes de commande. Tout d’abord on indique qu’on utilise auto qos pour la vidéo (par défaut auto qos fait la configuration sur un modèle de téléphonie sur IP simple)

auto qos srnd4

Puis sur les interfaces d’accès on indique qu’on souhaite une configuration pour un Soft-phone CISCO:

interface range GigabitEthernet 1/0/1-48
 switchport access vlan 10 0
 switchport voice vlan 110
 auto qos voip cisco-softphone