Cisco Security: IKEv1 L2L IOS & ASA

      1 Comment on Cisco Security: IKEv1 L2L IOS & ASA

Cisco Security: IKEv1 L2L IOS & ASA

Hola a todos una vez más, de tiempo que no paso por acá… y es que me he encontrado más que ocupado… Sin más y porque no recuerdo lo que iba a publicar la última vez, decidí realizar un post sobre VPN Site to Site teniendo en consideración ambos mundos tanto IOS como ASA, y aun así tener conexión a internet (muchos dicen que se confunden con los NAT… bue).

Con esto y sin más mostramos la topología con la que trabajaremos, en la cual se aprecia un Cisco ASA con versión 8.4 a la izquierda que tiene 2 redes, una publica y una privada, un Cisco Router con IOS 15.1 de igual forma con 2 redes y un Web Server que tiene la  IP publica ya conocida 8.8.8.8/32, entonces la idea es que ambas redes internas 192.168.1.0/24 y 172.16.15.0/24 se puedan comunicar a través de Internet, teniendo una conexión segura.

vpn-s2s-ios-asa

Ok, vamos a partir con el Cisco Router, el cual posee la configuración básica (IP, quad zero)

vpn1

Ya con eso vamos con la con la configuración del NAT, que la mayoría de ustedes ya deben de manejar al revés y al derecho (se peinan), un simple PAT

vpn2

 

Seguido pasamos a la parte de VPN en cuestión donde vamos a generar la política de fase 1 o ISAKMP y habilitarla, adicional a eso generaremos la PSK ciscorocks a usar como vector de inicial.

vpn3

ya que tenemos la política de fase 1 creada pasamos a crear la política de fase 2 o IPSec, solo para tener en cuenta como dato adicional, si existe mas de una política de fase 1 que tenga coincidencia entre dispositivos Cisco, se toma en consideración únicamente la política mas robusta, ejem AES sobre DES o 3DES bla bla..

vpn4

Ahora lo que debemos hacer es generar un regla que pueda hacer match contra el trafico interesante, o también conocido como domain encryption, hay que tener en consideración que lo que se permita en esta nueva ACL, se debe denegar en la ACL del NAT, esto simplemente para evitar que el trafico VPN salga nateado por la IP publica de nuestro Cisco Router

vpn5

Como ya visto en otros de mis post de VPN, ahora debemos asociar los parámetros creados anteriormente en un crypto map, si se fijan una de las restricciones de un crypto map es de que este permanecerá deshabilitado hasta que no posea un peer y una ACL para el trafico interesante, esto debido a que las otras opciones pueden ser heredadas.

vpn6

y para terminar con nuestro Cisco Router solo faltaría aplicar el crypto map creado bajo la interface donde se encuentra la IP publica, solo para mencionar, técnicamente se pueden asociar hasta 65535 cryptos en una interface, o hasta donde nuestra licencia nos permita. Vemos apenas aplicamos el crypto que ISAKMP es habilitado en la interface

vpn7

Con lo anterior terminamos de configurar nuestro Cisco Router, una vez mas no me pagan por decir o escribir Cisco, solo que es por costumbre jeje. Bien entonces pasamos a la parte interesante donde encontramos a nuestro Cisco ASA, el cual de igual forma se encuentra configurado con lo básico de lo básico (IP y quad zero)

asa1

Seguido de eso al igual que con el Cisco Router, debemos generar nuestro NAT para poder acceder a la red publica, para esto generamos un objecto llamado LAN y lo asociamos a un NAT after-auto que son utilizados para realizar el ya conocido por ustedes PAT o NAT overload

asa2

Técnicamente con esto podemos salir hacia la red publica pero sin embargo si generamos un ping, no veremos respuesta de los recursos externos, esto es debido a que el ping debe ser inspeccionado o en su defecto permitir los reply y unreachable en la interface outside como trafico de entrada. en nuestro caso vamos a usar la inspección por defecto que normalmente se encuentra como parte de la configuración de un Cisco ASA, mas no en la imagen de GNS3, por lo cual la aplicamos como una inspección global para todo el trafico.

asa3

Al igual que el equipo anterior, se debe generar la política de fase 1 o IKEv1, la cual debe hacer match para poder generar negociaciones en las otras capas

asa4

y también debe de hace match la política de fase 2 o IPSec, esta esta definida para únicamente IKEv1, debido a que el parser no alcanza para visualizar el comando en cuestión, en algunos casos pondré el show run de la configuración en particular o lo escribiré sin mas

asa5

Ahora, ya tenemos ambas políticas por lo cual vamos a generar los domain encryption para el trafico interesante, en esta ocasión utilizaremos object-groups, para ver como se utilizan y lo mas importante, que simplifican la administración de las VPN o cualquier otra cosa, ya que si es necesario agregar mas redes en ambos extremos, únicamente se editan los object-group, y no es necesario crear mayor numero de ACL, NAT, etc. Como se ve tenemos 2 object-group uno para identificar mi red interna, y otro para la red remota, la ACL solo hace mención de los objectos una sola vez, y como mencione anteriormente, si es necesario en un futuro agregar mayor cantidad de redes, estas solo se agregan  en los object-group y puff se hizo chocapic

asa6

Al igual que con el otro dispositivo, debemos generar una excepción de NAT para el trafico interesante, en ASA versión 8.0 hasta 8.2 se conocía como NAT 0, por su identificador; al igual que el punto anterior usaremos los object-group previamente creados, entonces si revisamos la sentencia, esta indica que se debe de hacer una NAT de la siguiente forma, si se origina en la red local y se dirige hacia la red remota, mantén la red local como origen y la red de destino como destino, es algo algo gracioso el como suena XD, otro punto que tiene esta excepción es que normalmente vamos a querer aplicarla como primera linea, ya que los NAT en as 8.3 en adelante, son secuenciales, para posicionarlo de primer lugar solo se debe agregar 1 entre ) y source quedando como

nat (inside,outside) 1 source static …

asa9

Entonces con esto creamos nuestro crypto map en el cual vamos a asociar todo lo anteriormente creado y activarlo en la interface outside

asa7

ahora, si recordamos, aun no hemos definido la PSK en el Cisco ASA, esto se realiza bajo la configuración del túnel en si, de forma especifica bajo los atributos ipsec, si se dan cuenta adicional aplique un group policy, lo que hace esto es setear de forma explicita el protocolo a utilizar, en nuestro caso IKEv1, esto para no usar configuración heredada por defecto.

asa8

ya con esto terminamos la configuración en ambos equipos por lo cual solo faltaría generar el ping entre ambos host finales, normalmente cuando se genera el ping con el tunel down, se pierden 2 request, uno para ARP y otro para la negociación de las fases. Para revisar si el tunel se encuentra UP se pueden utilizar los siguientes comandos para Cisco ASA
show crypto ipsec sa peer x.x.x.x | include ident|pkt
show crypto ikev1 sa detail
show vpn-sessiondb l2l

y para Cisco IOS
show crypto ipsec sa peer x.x.x.x | include ident|pkt
show crypto ipsec sa address x.x.x.x
show crypto isakmp sa detail

Si se fijan a continuación se puede ver que existen paquetes encapsulados y decapsulados,lo cual es lo ideal y ambos deben de estar en incremento, una vez tenemos exito con este lab, 😀 si por algun motivo se llega a ver que  existen paquetes encapsulados pero no hay decapsulados, lo mas probable es que exista un problema de routing interno en el otro extremo

Cisco ASA

asaver1

asaver2

Cisco IOS

isover1

iosver2

Una vez más, si hay faltas de ortografía… bue… con esto concluimos la parte de ‘Cisco Security: IKEv1 L2L IOS & ASA‘, espero que  sido de su agrado #ThugLife 😎 , favor si les gusto o tienen preguntas al respecto no duden en consultar y denle hartos likes XD #YOLO :mrgreen:, no dejen de visitar la pagina de Facebook !!

  • Expl0it

    increible tu trabajo paulo, que te tomes el tiempo de explicar nuestros dolores más grandes de cabeza, un abrazo