J’avoue que quand je lis mon titre, je me dit que le profane doit se demander si je parle Français 
.
Bref, ici on va voir plusieurs choses:
-Redondance GDOI (GETVPN), aussi appelé mode COOP (Co-Operation)
-DMVPN over GETVPN : Quel est l’intérêt, toussa toussa…
-Comment forcer un KS à forward du traffic sur du GETVPN (la on va voir un petit trick car normalement ça n’est pas son but).
Read more…
En bon geek je me suis dit : heh, sachant que j’ai un asa à la maison, ça serait cool de mettre un AP avec 2 SSID, un pour l’inside et un pour l’outside, et ce serait encore mieux de mettre de l’EAP-TLS sur l’inside !! Donc je me suis lancé, et je vais résumer ici les étapes pour ceux qui seraient tenté de faire de même !
juin 15th, 2011 by Bastien Migette | 2 Comments »Etant en train de monter un LAB, et celui-ci se décomposant en plusieurs PODs, j’ai voulu faire en sorte que ces PODs soient identiques (topologie, adressage IP, …), tout en ayant un accès vers un réseau externe. Voici donc comment j’ai fait pour réaliser ça:
On va utiliser cette topologie pour l’exemple:
Topologies PODs
On va donc ici utiliser des VRFs pour chacuns des PODs, et on va ajouter du NAT statique pour tout le réseau du POD. Cela veut dire que 2 PODs peuvent avoir le même réseau, mais seront vu depuis l’extérieur comme des réseau différent. Cela permets de copier/déplacer des machines depuis un POD vers l’autre.
On commence par la configuration IP et VRF sur R2:
! hostname R2 ! ip vrf pod1 rd 65000:1 ! ip vrf pod2 rd 65000:2 ! interface FastEthernet1/0 ip address 192.168.10.2 255.255.255.0 ip nat outside ip virtual-reassembly duplex auto speed auto ! interface FastEthernet1/1 ip vrf forwarding pod1 ip address 192.168.0.1 255.255.255.0 ip nat inside ip virtual-reassembly duplex auto speed auto ! interface FastEthernet2/0 ip vrf forwarding pod2 ip address 192.168.0.1 255.255.255.0 ip nat inside ip virtual-reassembly duplex auto speed auto !
On ajoute ensuite la config du NAT et du routage:
! ip nat inside source static network 192.168.0.0 192.168.1.0 /24 vrf pod1 ip nat inside source static network 192.168.0.0 192.168.2.0 /24 vrf pod2 ip route vrf pod1 0.0.0.0 0.0.0.0 192.168.10.1 global ip route vrf pod2 0.0.0.0 0.0.0.0 192.168.10.1 global !
Voilà, le plus gros du travail est fait. Si on regarde la syntaxe des commandes nat, on voit que l’ont traduit le réseau 192.168.0.0 de la VRF pod1 vers le réseau 192.168.1.0, avec un masque de 24bits (on auraient pu mettre netmask 255.255.255.0). On fait la même chose avec le réseau 192.168.0.0 de la VRF pod2 que l’ont traduit en 192.168.2.0. L’astuce ici est d’utiliser le « source static network » qui indique que l’on va translater un réseau et non pas une IP.
Ensuite, on ajoute des routes dans les VRF vers la table globale afin que le traffic puisse joindre le réseau extérieur.
La configuration des autres routeurs est assez simple ici :
R1:
! interface FastEthernet1/0 ip address 192.168.10.1 255.255.255.0 duplex auto speed auto ! ip route 192.168.0.0 255.255.0.0 192.168.10.2 !
R3/R4:
! interface FastEthernet1/0 ip address 192.168.0.2 255.255.255.0 duplex auto speed auto ! ip route 0.0.0.0 0.0.0.0 192.168.0.1 !
Ici, si je ping 192.168.1.2 depuis R1, je ping R3, et si je ping 192.168.2.2 je ping R4:
R1#ping 192.168.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 132/159/176 ms R1#ping 192.168.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 152/167/188 m R3# *Jun 14 14:08:51.187: ICMP: echo reply sent, src 192.168.0.2, dst 192.168.10.1, topology BASE, dscp 0 topoid 0 *Jun 14 14:08:51.335: ICMP: echo reply sent, src 192.168.0.2, dst 192.168.10.1, topology BASE, dscp 0 topoid 0 *Jun 14 14:08:51.491: ICMP: echo reply sent, src 192.168.0.2, dst 192.168.10.1, topology BASE, dscp 0 topoid 0 *Jun 14 14:08:51.667: ICMP: echo reply sent, src 192.168.0.2, dst 192.168.10.1, topology BASE, dscp 0 topoid 0 *Jun 14 14:08:51.819: ICMP: echo reply sent, src 192.168.0.2, dst 192.168.10.1, topology BASE, dscp 0 topoid 0 R4# *Jun 14 14:08:54.023: ICMP: echo reply sent, src 192.168.0.2, dst 192.168.10.1, topology BASE, dscp 0 topoid 0 *Jun 14 14:08:54.183: ICMP: echo reply sent, src 192.168.0.2, dst 192.168.10.1, topology BASE, dscp 0 topoid 0 *Jun 14 14:08:54.323: ICMP: echo reply sent, src 192.168.0.2, dst 192.168.10.1, topology BASE, dscp 0 topoid 0 *Jun 14 14:08:54.531: ICMP: echo reply sent, src 192.168.0.2, dst 192.168.10.1, topology BASE, dscp 0 topoid 0 *Jun 14 14:08:54.667: ICMP: echo reply sent, src 192.168.0.2, dst 192.168.10.1, topology BASE, dscp 0 topoid 0
On peut voir sur R2 que le traffic est bien natté:
R2#sh ip nat translations Pro Inside global Inside local Outside local Outside global icmp 192.168.1.2:7 192.168.0.2:7 192.168.10.1:7 192.168.10.1:7 --- 192.168.1.2 192.168.0.2 --- --- --- 192.168.1.0 192.168.0.0 --- --- icmp 192.168.2.2:6 192.168.0.2:6 192.168.10.1:6 192.168.10.1:6 --- 192.168.2.2 192.168.0.2 --- --- --- 192.168.2.0 192.168.0.0 --- ---
!
hostname R2
!
ip vrf pod1
rd 65000:1
!
ip vrf pod2
rd 65000:2
!
interface FastEthernet1/0
ip address 192.168.10.2 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
!
interface FastEthernet1/1
ip vrf forwarding pod1
ip address 192.168.0.1 255.255.255.0
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
!
interface FastEthernet2/0
ip vrf forwarding pod2
ip address 192.168.0.1 255.255.255.0
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
!
Je suis tombé par hasard sur cet article:
https://supportforums.cisco.com/docs/DOC-16398
qui parle de l’outil Network Monitor de Microsoft:
http://www.microsoft.com/downloads/details.aspx?familyid=983b941d-06cb-4658-b7f6-3088333d062f&displaylang=en
Vous allez me dire, quel intérêt, puisqu’il y a déjà wireshark ? Et bien quatre gros points positifs (je n’ai pas testé de fond en comble l’outil, alors il y a peut être d’autres features sympa)
-Possibilité de capturer en mode monitor avec sa carte WiFi
-Possibilité de filtrer le trafic par processus
-Possibilité de capturer sur plusieurs interfaces en même temps
-Export des fichiers de capture en .cap, pour les lire avec wireshark par exemple 
Pour ceux d’entre vous qui ne le savent pas, le ‘?’ sur un routeur cisco affiche l’aide.
Comment faire donc si je veux créer un utilisateur salut avec le mot de passe « cava? » ?
Voici ce qu’il se passe:
R1(config)#username salut password cava? LINE <cr> R1(config)#username salut password cava
Autrement dit, ça ne parche pas.
Pareil sur l’asa:
ASA1(config)# username salut password cava? configure mode commands/options: WORD ASA1(config)# username salut password cava
Donc petite astuce, il faut taper Ctrl+V avant. Pourquoi ? je ne sais pas, mais il en est ainsi.
R1(config)#username salut password cava? !ici j'ai tapé ctrl+v avant le '?' R1(config)#do sh run | i salut username salut password 0 cava?mars 16th, 2011 by Bastien Migette | No Comments »
Un petit article sur le failover stateful IPSEC en utilisant des interface VTI. Pourquoi ? parce que c’est cool les VTIs !!! Plus que les crypto maps 
Ah oui pour le fun j’ai mis du nat aussi (CCIE approchant, j’éssaie toujours de rajouter une petite touche de techno qui peut faire tout foirer histoire de troubleshooter).
R4 est le routeur qui fait du NAT. Il faut Imaginer que la liaison entre R4 et R5 est une connexion internet (d’où l’adressage en IP publique, les malins l’auront remarqué). Soit R1-R4 = Site1 et R5 = Site2
Ici, R2 et R3 vont avoir une IP Virtuelle HSRP qui va être nattée et servir de point de terminaison pour la connexion VPN.
Topologie
Bon après une longue période d’inactivité, du moins du coté de mon blog, car à coté de cela beaucoup de choses à faire (sinon j’aurai évidemment faire plus d’articles ), eh bien j’ai décidé de faire un petit article sur le GETVPN car je vais sauter les 2 dernières certifs CCSP et attaquer directement le CCIE comme un grand.
Salut à tous, je vends du matériel Cisco, la liste ici:
http://shop.ebay.fr/remus-95/m.html?_nkw=&_armrs=1&_from=&_ipg=&_trksid=p4340
juin 20th, 2010 by Bastien Migette | No Comments »Salut à tous, dans un élan de motivation pour attaquer ma certification IPS, et bien que la nouvelle version de la certification porte sur les AIP-SSM (pour les >5510) ou les AIP-SSC (pour les 5505), ces derniers étant hors de mes moyens (d’ailleurs je vais faire un bouton donate pour me payer un nouveau lab ), je décides donc d’acheter un 4215 sur ebay, puis, le blueprint CCIE 3.0 est toujours sur les 4215, cela n’est donc pas perdu me dis-je… Que n’avais-je donc pas fait … J’ai réeussi ce jour a faire marcher mon IDS, sachant que je l’ai acheté il y a quelques mois.
Voilà, cela faisait longtemps que je n’avais pas fait de vidéo, bref voici comment mettre en place l’authentification PEAP avec ACS pour l’authentification sur un point d’accès. La vidéo n’est pas montée, donc il y a peut être des partie inutile, mais je laisse comme ça pour deux raisons, d’une part parce que j’ai la flemme de faire le montage et d’autre part pour voir les procédures de debugging.
J’ai utilisé un certificat auto signé pour ne pas déployer d’autorité de certification.
Voir la vidéo