Voilà, chose promise, chose due.
Ci joint un fichier dynagen, j’ai laissé l’idlepc et l’image IOS, libre à vous de remplacer ces valeurs par n’importe quelle autre routeur de la famille, le plus important étant la ligne configuration=, qui contient, vous l’aurez deviné, la configuration problématique.
Pour faire simple, vous avez deux routeurs reliés entre eux par le réseau 1.1.1.0/30, chacun de ces routeurs ayant des loopback simulant un LAN.

Le but ici est de pouvoir pinger :

R1#ping ip 192.168.2.1 source 192.168.1.1

doit fonctionner (inverser les IP sur l’autre routeur).

R1 loop 0: 192.168.1.1/24

R2 loop 0: 192.168.2.1/24

Petit indice: debug crypto ipsec

Le fichier.net:

IPSEC_CNT_1

Edit: Bien joué à IGOR pour la avoir trouvé la solution, l’erreur était bien au niveau de la crypto ACL, il faut matcher le trafic au niveau de la source ET de la destination!

dans le debug crypto IPSEC, l’on peut voir:

*Mar  1 00:01:32.175: IPSEC(validate_proposal_request): proposal part #1, (key eng. msg.) INBOUND
local= 1.1.1.2,
remote= 1.1.1.1,
local_proxy= 192.168.2.0/255.255.255.0/0/0 (type=4), remote_proxy= 0.0.0.0/0.0.0.0/0/0 (type=4), protocol= ESP,
transform= esp-des esp-md5-hmac  (Tunnel), lifedur= 0s and 0kb, spi= 0×0(0), conn_id= 0, keysize= 0, flags= 0×0
*Mar  1 00:01:32.183: Crypto mapdb : proxy_match
src addr     : 192.168.2.0
dst addr     : 0.0.0.0
protocol     : 0
src port     : 0
dst port     : 0
*Mar  1 00:01:32.195: IPSEC(crypto_ipsec_process_proposal): proxy identities not supported

Notez le dst addr : 0.0.0.0
Si je redéfinis l’access list comme ceci:

R1(config)#ip access-list extended TUNNEL
R1(config-ext-nacl)#no 10
R1(config-ext-nacl)#permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

et vice versa, j’obtiens:

*Mar  1 00:01:28.056: Crypto mapdb : proxy_match
src addr     : 192.168.2.0
dst addr     : 192.168.1.0
protocol     : 0
src port     : 0
dst port     : 0
*Mar  1 00:01:28.064: IPSEC(crypto_ipsec_sa_find_ident_head): reconnecting with the same proxies and peer 1.1.1.1
*Mar  1 00:01:28.068: IPSEC(policy_db_add_ident): src 192.168.2.0, dest 192.168.1.0, dest_port 0
*Mar  1 00:01:28.072: IPSEC(create_sa): sa created,  (sa) sa_dest= 1.1.1.2, sa_proto= 50,

et le ping passe!

Salut à tous, depuis quelque temps je n’ai plus trop le temps de m’occuper de mon blog, mais ça va revenir vous inquiétez pas, et pour cela, je voulais savoir si l’idée à laquelle j’ai pensé intéresse du monde (sinon ça sert à rien)

En gros, je fournirai des topologies dynagen pré configurées, et bien entendue buguées, et il faudra faire du troubleshooting, la première personne ayant résolue la situation recevra… Mes félicitations
Le principe étant bien entendu que cela mette en évidence un point utile sur une technologie.

J’ai mis un petit sondage pour voir les personnes intéressées:

 Loading ...

C’est par ici!

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080120f48.shtml

Voici un petit projet illustrant l’utilisation de raw socket ethernet et IP en c++ sous linux. Le code n’est pas forcément toujours très propre, mais à la base je suis ingénieur réseau hein . La doc doxygen est incluse dans l’archive. Il y a une classe pour la résolution ARP, une classe pour l’entête IP, et une classe qui gère l’envoi de flux IP. iptraffic.tar

Deux petits liens (en anglais) à mettre dans les favoris:

Asa : http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/conf_gd.html

Routers : http://www.cisco.com/en/US/docs/ios/security/configuration/guide/12_4/sec_12_4_book.html

Un petit tuto pour patcher asaos afin de faire fonctionner ASDM en émulation. Les manipulation seront à faire sous linux.

Testé avec la version 8.0.2

Pour ceux qui ne sont pas bidouilleurs, j’ai mis une version patchée de la VM citée dans un précédent post, c’est par ici:

http://dl.free.fr/qQK1wuZDn

Read more…

Ceux qui ont l’habitude d’utiliser la commande

ip route subnet mask interface

sur un routeur ont peut être remarqué que la commande route sur un pix ou un asa nécessitait forcément un prochain saut:

route interface_name subnet mask next_hop

Si vous voulez utiliser le même comportement que la commande ip route interface, vous pouvez mettre l’ip de l’interface de votre pix/asa en tant que nexthop. A ce moment, votre équipement effectura une requête arp sur l’adresse de destination, et il faudra biensur que le nexthop réel ait le proxy arp activé (voir mon précédent post), sans quoi ça ne marchera pas.

Biensur, il faut faire attention, cette approche étant subjecte à de l’arp spoofing (un petit malin peut aisément se faire passer pour le nexthop)

Bon j’ai passé ma SNRS
J’ai eu aucun lab type commande, que du SDM, pas mal de questions DMVPN et IPSv5, ainsi que zone based FW. Je vous poste mes notes que j’ai prises, dont pas mal sont tirées de bouquins cisco.

SNRS.doc

Aller go SNAF

Voici une petite présentation des fonctionnalités de l’IOS Get VPN.
Nous ne verrons pas de configuration, puisque vous avez un bon exemple ici:

http://www.ipflow.utc.fr/index.php/GET-VPN_Introduction

Donc le GET VPN C’est quoi ? GET = Group Encrypted Transport, donc pour faire simple on vas chiffrer au niveau de la couche 4 par groupes, c’est à dire qu’on vas utiliser un protocole (GDOI, qui se base sur ISAKMP) et un Key Server qui aura pour rôle d’envoyer les configuration aux équipements distants (group members). Les group members vont établir une SA vers le KS qui vas leur envoyer les paramètres de chiffrement de manière sécurisée. Ensuite, chaque group members, lorsqu’il voudra communiquer avec un autre, vas chiffrer uniquement à partir de la couche 4, c’est à dire que l’en tête IP n’est jamais modifiée. En gros, immaginons que l’on a un réseau non sécurisé avec du routage entre nos différents sites. J’ajoute les fonctionnalités GETVPN à mon réseau, et les échanges seront maintenant sécurisés sans l’utilisations de tunnels. Cela prend donc tout son intérêt dans le cadre du MPLS, le transport paquets du client étant gérés par le FAI.

Le principe est que le FAI doit acheminer des paquets de l’adressage privé du client entre les différents site, sans quoi le client devrait utiliser des tunnels. Le client est ensuite libre d’implémenter une solution GET VPN pour sécuriser son traffic transitant par son fournisseur d’accès.

Il faut bien comprendre que l’adressage privé/publique n’a rien à voir avec GETVPN, on pourrait très bien utilisé des connexions WAN dédiée, et implémenter GETVPN sur les routeurs des différents sites, mais il faudrait utiliser un protocole de tunneling pour que les paquets d’un réseau local soient transportable sur internet.

Le gros avantage de cette solution est de permettre du chiffrement any to any (tous les sites vers tous les sites), sans avoir d’interface tunnel, ce qui est couteux en terme de performance (encapsulation/décapsulation), et qui obligerait à avoir autant de tunnel vers les différents site (imaginons que l’on ait 10 sites, chaque site devrait avoir 10 tunnels…) , ou dans le cas d’une topologie hub and spoke, avoir un routeur qui fait tout le routage…

Un article sur la configuration du SSL VPN:

Topologie

L’avantage du WebVPN est d’être très simple au niveau de la configuration pour l’utilisateur car il permet de se connecter via un applet java sur son navigateur web, et est compatible mac, linux et windows.

Read more…