OSPF Multi-Area- Théorie

1)     La topologie

 Afin d’illustrer les exemples, nous utiliserons la topologie suivante.

Par ailleurs, nous l’utiliserons aussi dans la partie pratique.

Nous ne nous soucierons pas de la configuration appliquée aux routeurs pour le moment.

2)     Rappels sur les zones

 Avant d’étudier les différents  types de zones, revenons sur le fonctionnement d’une zone basique.

Ces notions ont été traitées dans l’article sur les notions de base d’OSPF.

Premièrement, à quoi servent-les zones ?

Simplement à alléger le travail des routeurs.

Au sein d’une même zone, tous les routeurs se connaissent.

Par exemple, R2 connait R1 et R3, ainsi que R4 et R5. Par contre, il ne connait pas R6 et R7.

Ainsi, les LSA ne peuvent pas sortir d’une zone.  Par exemple, les LSA qui circulent dans la zone 0 n’iront jamais dans la zone 40.

Néanmoins, les routes d’une zone sont tout de même annoncées dans les autres zones.

R4 aura donc connaissance des routes pour 172.17.0.0 /22

En bref, les Area Border Router ne redistribuent pas les LSA (du moins certains types de LSA) dans d’autres zones, mais par contre, ils redistribuent les routes.

Pour rappel, il est possible de résumer les routes avant de les redistribuer. Pour cela, il faut que l’adressage soit hiérarchique (pour permettre la création d’une route résumée qui englobe les routes internes).

Au passage, les Autonomous System Border Router injectent dans la zone les routes venant d’un autre protocole de routage (ici ce sera R1).

Nous avions aussi vu qu’il faut que toutes les zones soient connectées à la zone 0.

Sinon, les routes n’arrivent pas dans la dernière zone.

Prenons l’exemple des zones 60 et 70.

R3 va envoyer à R6 les routes qu’il connait.

Par contre, R6 ne va pas renvoyer ces routes à R7.

A retenir :

• Utilité des zones : localiser les MAJ à la zone, réduire la taille de la topologie à connaitre
• Toutes les zones doivent être connectées à la zone 0
• L’adressage doit être hiérarchique (pour le résumé entre les zones)
• ABR : fait le lien entre plusieurs zones
• ASBR : injecte des routes venant d’autres protocoles de routage

3)     Les différents messages LSA

La partie suivante a déjà été partiellement traitée dans l’article sur les bases d’OSPF.

Nous allons voir qu’il existe différents types de LSA en OSPF. Il est important de les connaitre afin de bien comprendre le fonctionnement des différents types de zones.

Voici les LSA qui existent :

• Type 1 : Décrit les interfaces d’un routeur
• Type 2 : décrit les routeurs connectés au segment
• Type 3 : Route de résumé envoyée dans une autre Area par l’ABR – Area Border Router
• Type 4 : Décrit l’ASBR – Autonomous System Border Router. Généré par l’ASBR et envoyé dans les autres zones. Permet de faire connaitre le routeur ID dans d’autres zones.
• Type 5 : Route redistribuée par l’ASBR (route externes, type RIP, EIGRP, etc…)
• Type 7 (abordée plus en détails avec la Not So Stubby Area) : Comme le type 5, mais qui peut circuler dans une NSSA. Il est transformé en Type 5 à la sortie de la NSSA

Revenons plus en détail sur ces 6 types.

Type 1 et 2 : ils permettent aux routeurs d’une zone de se connaitre, et de construire une carte topologique de la zone.

Type 3 : il permet d’envoyer des routes d’une zone A  à une zone B. Ainsi, les routes de la zone A, seront présentes dans la zone B, et ce sans connaitre la topologie de la zone A. Il est possible de résumer les routes avant de les envoyées.

Type 5 : il permet à l’ASBR de redistribuer des routes externes dans une zone.

Type 4 : il permet de faire connaitre l’ASBR. Reprenons la topologie. R1 est l’ASBR, car il peut injecter des routes externes.

Grace au LSA de type 5, R1 va redistribuer ses routes externes. Quand R3 recevra des LSA de type 5 de la part de R1, il n’y aura pas de problème.

Il va ensuite faire suivre ces LSA dans la zone 60.

Considérons R6. Il va recevoir un LSA de type 5 venant de R1 (grâce à R3 qui l’a fait suivre).

Mais il ne va pas reconnaitre l’expéditeur du LSA (le routeur R1). En effet, le routeur ID à l’origine du LSA est celui de R1. Or R6 ne connait pas R1, car il ne fait partie de sa zone.

R6 aura donc une information dans sa base de données, lui disant que pour joindre le réseau 172.16.0.0 /22, il faut d’abord joindre le routeur R1. Mais R6 ne connait pas R1. Même si il a une route pour R1, il ne sait pas qu’elle mène au routeur ayant pour ID celui de R1.

Le LSA de type 4 permet donc de faire connaitre l’ASBR dans toutes les zones.

Pour illustrer cette explication, voyons cela en pratique.

R1, R3 et R6 ont été configurés de manière basique (IP, OSPF)

R1 redistribue les routes statiques qu’il possède.

Chaque routeur a un router-id correspondant à son Hostname.

Donc, R1 va envoyer des LSA de type 5 pour annoncer les routes externes.

Voyons cela  sur R3 (avec la commande « show ip ospf database »)   :

R3 sait comment joindre le réseau 172.16.0.0 /22. Il doit pour cela joindre le routeur ayant pour ID 1.1.1.1. Attention, il ne s’agit pas de joindre l’IP 1.1.1.1, mais bien le routeur ayant cet ID.

Il faut donc que R3 ai connaissance de R1.

Cela tombe bien, ils sont dans la même zone. Les LSA de types 1 et 2 qui circulent au sein de la zone, permettent aux routeurs de se connaitre.

R3 connait le routeur ayant pour ID 1.1.1.1. Il sait donc comment le joindre.

Comme nous l’avions dit, jusqu’ici, il n’y a pas de problème. Nul besoin de LSA de type 4.

Voyons où ceux-ci sont utiles.

Que se passe-t-il quand R3 fait suivre des LSA de type 5 venants de R1, vers R6 ?

R6 réceptionne les LSA, et remplit sa base de données.

Ici le problème est flagrant : R6 ne connait pas R1 (l’ID 1.1.1.1)

Il ne peut donc pas se créer une route pour 172.16.0.0 /22. Celle-ci devrait pointer vers R1. Or R6 ne connais pas R1, car ils ne sont pas dans la même zone (c’est le principe des zones).

Encore une fois, nous parlons bien de l’ID 1.1.1.1 (ce qui n’a rien à voir avec une éventuelle IP 1.1.1.1).

Bref, il faut que R6 sache qui est R1.

C’est ici qu’interviennent les LSA de type 4.

Avant de faire suivre les LSA de type 5, R3 va envoyer un LSA de type 4 (aussi appelé Summary ASB LS) à R6 :

R6 sait donc que pour joindre R1, il faut passer par R3.

A partir des LSA de type 4 et 5, R6 peut maintenant se construire une route pour 172.16.0.0 /22.

En bref, un LSA de type 4 est généré par un ABR, afin de faire connaitre l’ASBR dans d’autres zones.

Ensuite, les routeurs pourrons assimiler les LSA de type 5, même si l’ASBR n’est pas dans leur zone.

 Type 7 : il est un peu particulier. Nous l’étudierons plus tard avec les Not So Stubby Area.

 4)     Les différents types de zones

 La Backbone Area : toutes les zones doivent y être connectées

La Standard Area : type de zone par défaut. Les LSA de type 1 et 2 ne sortent pas de la zone (comme toujours).

Les LSA de types 3, 4 et 5 peuvent s’échanger entre les zones standards

Stubby Area : les LSA de types 4 et 5 ne sont pas envoyés dans la zone. A la place, une route par défaut est utilisée.

Par exemple, R4 (à gauche sur la topologie) ne recevra jamais les LSA de type 5 venant de R1.

Il n’aura pas conscience des routes externes.

Il connaitra bien les réseaux 10.0.12.0, 10.0.13.0, etc… En effet, les LSA de type 3 entrent bien dans les zones Stubby.

 Mais alors, comment joindre les réseaux externes ?

Avec une route par défaut !

Celle-ci est automatiquement créée sur R4, si il est en mode Stubby.

 Voici la table de routage de R4 quand il est en mode Stubby :

Nous pouvons voir qu’il possède toujours les routes importées depuis d’autres zones. Par contre, il ne possède plus de routes externes. A la place, il a une route par défaut, pointant vers R2.

 Sans le mode Stubby, nous aurions 4 routes pour le réseau 172.16.0.0 /22

 Totally Stubby Area : Empêche les LSA de type 3, 4 et 5 de rentrer.

 Les routeurs de l’Area ne connaîtront que les réseaux internes à l’Area.

Pour joindre les réseaux des autres zones, ou les réseaux externes, une route par défaut est utilisée.

 Voici la table de routage de R5, quand l’Area 50 est en Totally Stubby

Si nous rajoutons d’autres routeurs dans la zone 50, R5 connaitra leurs réseaux (grâce aux LSA de type 1 et 2).

 Not So Stubby Area : oui, le nom de ce type de zone est … spécial !

 Le but est de permettre la présence d’un ASBR dans une Stubby ou Totally Stubby Area. A noter que pour une Totally Stubby Area, nous appellerons la zone « Totally Stubby Not So Stubby Area ». Oui, vous avez bien lu …

 Pourquoi faut-il une configuration particulière ?

En Stubby ou Totally Stubby, les LSA de types 4 et 5 ne circulent pas.

L’ASBR ne pourra donc pas redistribuer de routes externes.

 En mode NSSA, l’ASBR utilisera le fameux LSA de type 7 pour remplacer les LSA de type 4 et 5

A la sortie de la NSSA, le LSA de type 7 est transformé en type 4 ou 5 selon le cas.

 Voyons un exemple :

Nous ajoutons des routes statiques sur R4

Voici le message du routeur quand nous volons configurer la redistribution (et donc en faire un ASBR) :

Il refuse de redistribuer les routes externes, car les LSA de types 4 et 5 ne pourront pas circuler dans l’Area.

La redistribution n’aura donc aucun effet.

Pour corriger le problème, la zone doit être en NSSA

Une fois cela fait (détail de la configuration dans un prochain article), les routes peuvent être redistribuées

 R2 possède maintenant des LSA de type 7 :

Comme dit précédemment, à la sortie de la zone NSSA, les LSA de types 7 sont convertis en types 4 et 5 (nous retrouvons le fonctionnement normal de la redistribution)

 Voyons si R3 reçoit bien les LSA de type 5 correspondants au réseau 172.18.0.0 /22 :

En effet, R3 n’y voit que du feu !

Notons au passage, qu’il considère R2 comme l’ASBR, et non pas R4.

 5)     Conclusion

 Nous avons vu la théorie sur les différents types de zones OSPF

Pour rappel, les voici :

• Standard Area : zone par défaut, tous les LSA peuvent y circuler
• Stub Area : zone qui ne laisse pas circuler les LSA de type 4 et 5 (les routes externes sont alors remplacées par une route par défaut)
• Totally Stubby Area : zone qui ne laisse pas circuler les LSA de type 3, 4 et 5 (les routes externes et celles des autres zones sont alors remplacées par une route par défaut)
• Not So Stubby Area : Zone Stub qui continent un ASBR. Les LSA de types 4 et 5 sont remplacées par du type 7, au sein de la zone. Ils sont convertis en types 4 et 5 à la sortie
• Totally Stubby Not So Stubby Area : même chose qu’une NSSA mais pour Totally Stubby Area

Bien sûr, pour bien comprendre tout cela, nous avons étudié les messages LSA.

Voici un récapitulatif :

• Type 1 : Décrit les interfaces d’un routeur
• Type 2 : décrit les routeurs connectés au segment
• Type 3 : Route de résumé envoyée dans une autre Area par l’ABR – Area Border Router
• Type 4 : Décrit l’ASBR – Autonomous System Border Router. Généré par l’ASBR et envoyé dans les autres zones. Permet de faire connaitre le routeur ID dans d’autres zones.
• Type 5 : Route redistribuée par l’ASBR (route externes, type RIP, EIGRP ; statique, etc…)
• Type 7 : Comme le type 5, mais qui peut circuler dans une NSSA. Il est transformé en Type 5 à la sortie de la NSSA

Si la théorie est claire, vous pouvez passer à la pratique (dans l’article suivant).

Les configurations ne sont pas compliquées du tout. Le plus gros du travail était de comprendre le fonctionnement des zones.

 

Remote VPN IPSEC sur ASA

Cet article va monter le detail d’une configuration remote vpn sur un asa. De nombreuses notions ont déjà été abordée sur mon article sur le remote VPN avec des routeurs, aussi je ne m’étendrai pas forcément dessus, le but ici est de comprendre la méthode de configuration. Certains préfèreront peut être ASDM, pourquoi pas, mais il est beaucoup plus simple pour le débogage d’utiliser la CLI. A ce propos, le déboguage sur un asa se fait via plusieurs niveaux de verbosité.
ciscoasa#debug crypto isakmp {1-255}
Par défaut à 1, vous n’aurez quasiment pas d’informations. A 100 c’est un peu plus bavard, et à 255 c’est trop bavard (on a les dumps des paquets etc…), cependant, il n’existe pas de niveau intermédiaire (ou je ne les ai pas trouvé), et le niveau 255 est le seul qui fasse apparaitre les SA proposal envoyé par le client distant. Bref, je préfère le débogage sur un bon vieux routeur 

! Définition des IP et paramètres des interfaces
interface Ethernet0/0
 nameif inside
 security-level 100
 ip address 192.168.7.3 255.255.255.0
!
interface Ethernet0/1
 nameif outside
 security-level 0
 ip address 192.0.0.1 255.255.255.0
!
crypto ipsec transform-set TSET esp-aes esp-sha-hmac ! Creation d'un transform set
crypto dynamic-map remote_vpn_dynmap 1 set transform-set TSET !creation d'une crypto map dynamique 
!(rappelez vous, pour le remote VPN on ne dispose pas de l'IP distante, il faut donc une CM Dynamique)
crypto dynamic-map remote_vpn_dynmap 1 set reverse-route ! Activation du reverse route (une route statique par client)
crypto map remote_vpn_map 1 ipsec-isakmp dynamic remote_vpn_dynmap
!(creation d'une crypto map qui utilisera le modèle de la CM Dynamique)
crypto map remote_vpn_map interface outside !application de cette crypto map sur l'interface outside
crypto isakmp enable outside ! activation ISAKMP sur l'interface outside
crypto isakmp policy 1 !creation d'une policy: auth presahre, AES/SHA/DH Group2
 authentication pre-share
 encryption aes
 hash sha
 group 2
 lifetime 86400
no crypto isakmp nat-traversal ! à activer sur l'on traverse du nat (coté client ou server)
!Creer le groupe en premier, sinon vous aurez une erreur lors de l'affectation au tunnel group ou au client
group-policy remote_vpn_group internal !creation d'un groupe d'utilisateurs, le split tunneling, IP dns/wins/... est à définir ici
group-policy remote_vpn_group attributes !définition des attributs de ce groupe
 vpn-tunnel-protocol IPSec  ! actif que pour IPSEC (autre possibilités: L2TP, WEBVPN, ...)
 default-domain value dom.lan
username vpnuser password CsQTPU4apf7BtSoe encrypted ! ajout d'un utilisateur à ce groupe.
username vpnuser attributes
 vpn-group-policy remote_vpn_group
!
tunnel-group remote_vpn type remote-access ! Creation d'un tunnel groupe type remote-access: contient l'ensemble des paramètres (group policy, psk, adresses)
! pour une connexion VPN. Des groupes par défauts sont créés, les options non explicitée utilisent celles de ces groupes
!il faudra utiliser le nom du tunnel group dans la configuration du client VPN, pas celui du group-policy (objet interne)
tunnel-group remote_vpn general-attributes
 address-pool remote_vpn_pool
 default-group-policy remote_vpn_group
tunnel-group remote_vpn ipsec-attributes
 pre-shared-key * !dans la config la clé n'apparaît pas, c'est normal
!
ip local pool remote_vpn_pool 192.168.10.1-192.168.10.100

Les points qui n’ont pas été abordés mais qui peuvent être importants

• Exemption du nat pour le traffic tunnelé : Creation d’une ACL et utilisation du NAT0
• Utilisation d’un serveur externe pour l’authentification : Dans le tunnel group, spécifier le authentication-server-group
• Redistribution des routes statiques dans un protocole de routage
• Activer le nat traversal, pour encapsuler les packets IPSEC dans un segment UDP afin de ne pas être sensible au nat (uniquement si on utilise HMAC).
• Renseigner les paramètres de DNS/WINS dans le group-policy

Ceux qui ont du mal avec ces configurations, ASDM peut être un bon outil, assurez vous de cocher la case qui permets de voir les commandes qu’ASDM envoi à l’ASA avant de les envoyer, de cette manière vous pouvez voir les paramètres et leurs commandes associées.

Note: Pour le passage de la SNAF, ces commandes ne sont pas à savoir, il faut simplement savoir les réaliser avec ASDM.

!
interface Ethernet0/0
nameif inside
security-level 100
ip address 192.168.7.3 255.255.255.0
!
interface Ethernet0/1
nameif outside
security-level 0
ip address 192.0.0.1 255.255.255.0
!
crypto ipsec transform-set TSET esp-aes esp-sha-hmac
crypto dynamic-map remote_vpn_dynmap 1 set transform-set TSET
crypto dynamic-map remote_vpn_dynmap 1 set reverse-route
crypto map remote_vpn_map 1 ipsec-isakmp dynamic remote_vpn_dynmap
crypto map remote_vpn_map interface outside
crypto isakmp enable outside
crypto isakmp policy 1
authentication pre-share
encryption aes
hash sha
group 2
lifetime 86400
no crypto isakmp nat-traversal
!
group-policy remote_vpn_group internal
group-policy remote_vpn_group attributes
vpn-tunnel-protocol IPSec
default-domain value dom.lan
username vpnuser password CsQTPU4apf7BtSoe encrypted
username vpnuser attributes
vpn-group-policy remote_vpn_group
username cisco password 3USUcOPFUiMCO4Jk encrypted
tunnel-group remote_vpn type remote-access
tunnel-group remote_vpn general-attributes
address-pool remote_vpn_pool
default-group-policy remote_vpn_group
tunnel-group remote_vpn ipsec-attributes
pre-shared-key *
!

Remote Access VPN + Radius

Un petit exemple de remote VPN avec authentification/Authorization via Radius.

Configuration des IP et du nom d’hôte

Router(config)#hostname VPNGATE
VPNGATE(config)#int f0/1
VPNGATE(config-if)#ip address 192.168.254.1 255.255.255.0
VPNGATE(config-if)#no shut
VPNGATE(config-if)#int f0/0
VPNGATE(config-if)#ip add 80.80.80.80 255.255.255.0
VPNGATE(config-if)#no shut
VPNGATE(config-if)#int loop1
VPNGATE(config-if)#ip address 192.168.1.1 255.255.255.0

Ping vers le serveur radius:

VPNGATE#ping 192.168.254.10

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.254.10, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/6/16 ms

Configuration du remote VPN:

Voici les différentes étapes à suivre:

• Configuration des politiques de groupes utilisée par le VPN (aaa)
• Configuration ISAKMP et IPSEC
• Configuration du client VPN Cisco
• Optionnel: Ajout de l’authentification XAuth

Configuration des politiques de groupes utilisée par le VPN (aaa)

Dans cette première partie, nous allons indiquer comment la configuration des utilisateurs va être appliquée par le VPN. Je vais créer un groupe local, et un groupe sur mon serveur radius.

Configuration AAA

VPNGATE(config)#aaa new-model
VPNGATE(config)#aaa authorization network Remote_VPN_Author group radius local
VPNGATE(config)#aaa authentication login Remote_VPN_Authen group radius local

Configuration du group local

Je vais créer un groupe d’administrateur de secour de manière à ce que si le serveur radius tombe en panne, le VPN soit encore accessible.
Il faut définir un pool d’adresse qui sera utilisé, puis configurer le groupe avec une clé pré partagée ainsi que les diverses options du groupe (serveur wins, DNS…).
On vas aussi créer un utilisateur LocalAdmin

VPNGATE(config)#ip local pool Remote_VPN_Pool 192.168.100.1 192.168.100.254
VPNGATE(config)#crypto isakmp client configuration group VPN_Admins
VPNGATE(config-isakmp-group)#key 4dm!nVPNP4$$
VPNGATE(config-isakmp-group)#pool Remote_VPN_Pool
VPNGATE(config-isakmp-group)#domain mynetwork.lan
VPNGATE(config-isakmp-group)#exit

Configuration du serveur radius

Sur le routeur:

VPNGATE(config)#radius-server host 192.168.254.10 key R4d!usK3y

Sur le serveur ACS:

Note: Ne pas oublier de changer l’adresse IP dans Network Configurations / AAA Servers et redémarrez le serveur radius (CSRadius)

NOTE: Pour les groupes ISAKMP Avec radius, il faut créer un utilisateur portant le nom du groupe, et l’associer à son groupe, avec le mot de pase cisco qui est un mot de passe spécial !
Je penses qu’il faut faire cela car le protocol radius n’accepte pas que l’on lui passe un groupe en paramètre, on utilisera donc un utilisateur pour authentifier le groupe. A vérifier
Source: http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/ftunity.html#wp1191206 ethttp://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/ftunity.html#wp1045273

Dans le menu Network configuration, dans AAA Clients, cliquez sur add entry et mettez ces paramètres:
Hostname: VPNGATE
AAA Client IP: 192.168.254.1
Shared Secret: R4d!usK3y
Authenticate using: RADIUS (CISCO IOS/PIX)

Puis cliquez sur submit+apply

Allez ensuite dans Interface configuration, puis RADIUS (Cisco IOS/PIX 6.0), et vérifiez que « 026/009/001] cisco-av-pair » est coché (première ligne), puis submit.

Dans group Setup, choisissez le groupe 1, renommez le en VPN_USERS (optionnel), puis cliquez sur edit settings.

Dans la partie « Cisco IOS/PIX 6.x RADIUS Attributes » cochez « [009\001] cisco-av-pair » et mettez ceci:

ipsec:key-exchange=ike
ipsec:key-exchange=preshared-key 
addr-pool=VPN_Users_Pool
ipsec:default-domain=myNetwork.lan

Note: le pool VPN_Users_Pool Doit exister sur le router:

VPNGATE(config)#ip local pool VPN_Users_Pool 192.168.101.1 192.168.101.254

Cocher aussi ces attributs dans Radius IETF (s’ils n’apparaissent pas, aller dans Interface configuration, RADIUS IETF, puis cochez les)

• Attribute 6: Service-Type=Outbound
• Attribute 64: Tunnel-Type=IP ESP
• Attribute 69: Tunnel-Password=U$3rVPNP4$$

Cliquez sur Submit+Restart

Je n’ai pas trouvé la liste exhaustive des attributs supportés, je me suis inspiré de ceux ci:
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/ftunity.html#wp1058287

AJOUT DE L’UTILISATEUR DU GROUPE !!

ajouter un utilsateur VPN_USERS avec le mot de passe cisco (cisco et pas un autre mot de passe, voir note au début de ce point). Dans la partie Client IP Address Assignment, mettez « No IP address assignment »

Ajoutez un utilisateur dans le serveur radius (cliquez sur User setup, entrez un nom d’utilisateur puis cliquez sur add/edit et mettez les paramètres sur screenshot).

j’ai créé l’utilisateur vpnuser avec le mot de passe cisco (ici le mot de passe cisco n’est pas obligatoire, vous pouvez mettre ce que vous voulez). Testons les paramètres sur le routeur:

VPNGATE#test aaa group radius vpnuser cisco legacy
Attempting authentication test to server-group radius using radius
User was successfully authenticated.

Configuration ISAKMP et IPSEC

Configuration ISAKMP: Hash md5, Authentification PSK, Diffie-Hellman Group 2, et encryption DES

VPNGATE(config)#crypto isakmp policy 1
VPNGATE(config-isakmp)#hash md5
VPNGATE(config-isakmp)#authentication pre-share
VPNGATE(config-isakmp)#group 2
VPNGATE(config-isakmp)#encryption des
VPNGATE(config-isakmp)#exit

Note: La clé pré partagée IKE sera celle du groupe.

Il faut maintenant créer un transform set, et une crypto map dynamic. Les crypto map dynamiques sont des crypto map dont l’ensemble des paramètres n’est pas connu, par exemple en l’occurence le peer distant n’est pas static, on ne connait pas les adresses IP qui vont se connecter en remote VPN.
Creation d’un transform set et d’une crypto map dynamiques. La fonction reverse-route permet d’intégrer une route /32 avec l’adresse du client dans la table de routage et donc de la propager aux autres routeurs via des mises à jour (RIP, EIGRP, OSPF…) afin qu’il soit connu des autres routeur du réseau.
Note: Les numéros 1 et 10 des crypto map correspondent au numéros de séquence, ce qui permet d’avoir plusieurs profiles. Le numero le plus petit est prioritaire, car il sera traité en premier.

VPNGATE(config)#crypto ipsec transform-set Remote_VPN_TSet esp-3des esp-Md5-hmac
VPNGATE(cfg-crypto-trans)#exit
VPNGATE(config)#crypto dynamic-map Remote_VPN_Dynmap 1
VPNGATE(config-crypto-map)#set transform-set Remote_VPN_TSet
VPNGATE(config-crypto-map)#reverse-route

Nous allons maintenant creer la crypto map qui indiquera comment est déclenchée la connexion client, ainsi que les paramètres d’authorization

VPNGATE(config)#crypto map Remote_VPN_Map isakmp authorization list Remote_VPN_Author
!connexion déclenchée par le client
VPNGATE(config)#crypto map Remote_VPN_Map client configuration address respond
VPNGATE(config)#crypto map Remote_VPN_Map 10 ipsec-isakmp dynamic Remote_VPN_Dynmap  

Note: Les numéros 1 et 10 des crypto map correspondent au numéros de séquence, ce qui permet d’avoir plusieurs profiles. Le numero le plus petit est prioritaire, car il sera traité en premier.

Il ne reste plus qu’a appliquer notre crypto map au l’interface par laquelle vont se connecter les clients et ça doit marcher (suspens)

VPNGATE(config)#interface FastEthernet 0/0
VPNGATE(config-if)#crypto map Remote_VPN_Map

Configuration du client VPN Cisco

Dans le client VPN Cisco, cliquez sur new:

Dans la fenêtre utilisez ces paramètres (ou ceux que vous avez spécifier pour votre groupe local à l’étape 1).:
Group : VPN_Admins
Password: 4dm!nVPNP4$$

Refaire la même étape avec les paramètres du serveur Radius

Group: VPN_USERS
Password:U$3rVPNP4$$

ester la connexion VPN_USERS:

Sélectionnez la connexion dans le Client VPN, puis cliquez sur connect. Cela doit marcher.

Vérification de la reverse-route (80.80.80.1 est mon l’adresse publique du client).

VPNGATE#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     80.0.0.0/24 is subnetted, 1 subnets
C       80.80.80.0 is directly connected, FastEthernet0/0
C    192.168.254.0/24 is directly connected, FastEthernet0/1
C    192.168.1.0/24 is directly connected, Loopback1
     192.168.101.0/32 is subnetted, 1 subnets
S       192.168.101.1 [1/0] via 80.80.80.1

Affichage des clients:

VPNGATE#sh crypto isakmp peers
Peer: 80.80.80.1 Port: 3800 Local: 80.80.80.80
 Phase1 id: VPN_USERS

VPNGATE#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
80.80.80.80     80.80.80.1      QM_IDLE           1001    0 ACTIVE

IPv6 Crypto ISAKMP SA

VPNGATE#sh crypto session
Crypto session current status

Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 80.80.80.1 port 3800
  IKE SA: local 80.80.80.80/500 remote 80.80.80.1/3800 Active
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 192.168.101.1
        Active SAs: 2, origin: dynamic crypto map

Et sur mon pc:

Carte Ethernet Connexion au réseau local 8:

        Suffixe DNS propre à la connexion : myNetwork.lan
        Adresse IP. . . . . . . . . . . . : 192.168.101.2
        Masque de sous-réseau . . . . . . : 255.255.255.0
        Passerelle par défaut . . . . . . : 192.168.101.1

Maintenant, désactivons le serveur radius (déconnecter, shutdown,…) pour tester le groupe admins. Si on ne faisait pas ça, le serveur radius répondrait par invalid user et on ne pourrais s’authentifier avec le groupeVPN_Admins.Si l’on voulais que ce groupe soit quand même accessible, il aurait fallu le créer ET sur le routeur ET sur le serveur radius. Pour ma part je vais shutdown l’interface du radius.

Note: Cela ne marche pas car le temps qu’il y ait un timeout pour contacter le serveur radius, le client VPN annule la connexion. Par contre si je modifie la ligne

VPNGATE(config)#aaa authorization network Remote_VPN_Author group radius local
par
VPNGATE(config)#aaa authorization network Remote_VPN_Author local

Le groupe VPN_Admins fonctionne. On remarque bien un pool d’adresse différent:

Carte Ethernet Connexion au réseau local 8:

        Suffixe DNS propre à la connexion : mynetwork.lan
        Adresse IP. . . . . . . . . . . . : 192.168.100.1
        Masque de sous-réseau . . . . . . : 255.255.255.0
        Passerelle par défaut . . . . . . : 192.168.100.2

Il faudrait trouver un moyen d’augmenter le timeout pour le client VPN, ou de baisser celui du serveur radius sur le routeur. Bref on va plutot s’attaquer à l’XAUTH.

Ajout de l’authentification XAuth

XAuth c’est quoi? XAuth = eXtended Authentication. Oui mais encore ? Xauth est un processus entre les phase 1 et 2 IKE (parfois appelé phase IKE 1.5), permettant d’authentifier un utilisateur lorsqu’il se connecte en VPN. Les plus doué d’entre vous auront peut être remarqué que j’ai créé un utilisateur vpnuser avec le mot de passe cisco, et que j’ai ajouter une ligne dans la configuration du routeur qui ne nous a pas encore servie:

VPNGATE(config)#aaa authentication login Remote_VPN_Authen group radius local

Bref, pour activer XAuth, ajouter une authentication list à la crypto map précédemment créée:

VPNGATE(config)#crypto map Remote_VPN_Map client authentication list Remote_VPN_Authen

Maintenant, il suffit de couper la connexion, et de la relance (VPN_USERS), et l’on va être amenés à se logguer. Nous utiliseront vpnuser/cisco (ou tout autre utilisateur que vous aurez créé). Libre à vous d’ajouter d’autres utilisateurs dans ACS. Pour les groupes locaux, il suffit d’utiliser les utilisateurs créé avec la commande username. (Ne pas oublier de remettre aaa authorization network Remote_VPN_Author group radius local si vous aviez enlevé radius pour testé le group local)

Configuration finale:

VPNGATE#sh run
Building configuration...

Current configuration : 1785 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname VPNGATE
!
boot-start-marker
boot-end-marker
!
!
aaa new-model
!
!
aaa authentication login Remote_VPN_Authen group radius local
aaa authorization network Remote_VPN_Author group radius local 
!
aaa session-id common
!
resource policy
!
memory-size iomem 15
no network-clock-participate slot 1
no network-clock-participate wic 0
ip cef
!
!
!
!
!
!
!
!
username LocalAdmin privilege 15 secret 5 $1$tDWV$6NngMkxdNRufvvGGmZ68h1
!
!
!
crypto isakmp policy 1
 hash md5
 authentication pre-share
 group 2
!
crypto isakmp client configuration group VPN_Admins
 key 4dm!nVPNP4$$
 domain mynetwork.lan
 pool Remote_VPN_Pool
!
!
crypto ipsec transform-set Remote_VPN_TSet esp-3des esp-md5-hmac
!
crypto dynamic-map Remote_VPN_Dynmap 1
 set transform-set Remote_VPN_TSet
 reverse-route
!
!
crypto map Remote_VPN_Map client authentication list Remote_VPN_Authen
crypto map Remote_VPN_Map isakmp authorization list Remote_VPN_Author
crypto map Remote_VPN_Map client configuration address respond
crypto map Remote_VPN_Map 10 ipsec-isakmp dynamic Remote_VPN_Dynmap 
!
!
!
!
interface Loopback1
 ip address 192.168.1.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 80.80.80.80 255.255.255.0
 duplex auto
 speed auto
 crypto map Remote_VPN_Map
!
interface FastEthernet0/1
 ip address 192.168.254.1 255.255.255.0
 duplex auto
 speed auto
!
ip local pool Remote_VPN_Pool 192.168.100.1 192.168.100.254
ip local pool VPN_Users_Pool 192.168.101.1 192.168.101.254
!
!
ip http server
no ip http secure-server
!
!
!
!
radius-server host 192.168.254.10 auth-port 1645 acct-port 1646 key R4d!usK3y
!
control-plane
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end