cancelar
Mostrando los resultados de 
Buscar en lugar de 
Quiere decir: 
Avisos
¡Bienvenido a la nueva Comunidad de Soporte de Cisco! Nos encantaría conocer su opinión
New Member

Loggin UDP y TCP en interface WAN

Hola a todos, estoy intentado loguear el trafico UDP y TCP que llegan a mis interfaces WAN, ya tengo un servidor montado donde envio el debug ISAKMP e IPSEC de vpn´s, pero me desconcierta hacerlo en la interfaz, debería hacer una ACL y un IP ACCESS-GROUP  y loguear el resultado o se puede encarar de otra forma? Mi necesidad radica en que hace unos dias tuve algunos eventos donde alrededor de 60 vpn´s (de 300) no se conectaban o tardaban demasiado, lo que me surgen dudas de un posible ataque a la interfaz, mi intención es loguear algun indicio de tal sospecha, deberia ademas de UDP y TCP loguear algo mas especifico?

Saludos y muchas gracias por la ayuda !

1 SOLUCIÓN ACEPTADA

Soluciones aceptadas
Cisco Employee

Hola.

Hola.

Para hacer este monitoreo podrías usar Netflow en lugar de un access-list con log que podría aumentar mucho el uso del CPU junto con los debugs que ya estás corriendo. El problema es que necesitarías un software aparte que pueda trabajar con la información de Netflow que provee el equipo. Puede ser software de Cisco o bien externo que maneje los paquetes de Netflow:

http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ios-netflow/prod_white_paper0900aecd80406232.html

http://www.cisco.com/c/en/us/td/docs/ios/netflow/configuration/guide/12_2sr/nf_12_2sr_book.html

Saludos.

11 RESPUESTAS
Cisco Employee

Hola.

Hola.

Para hacer este monitoreo podrías usar Netflow en lugar de un access-list con log que podría aumentar mucho el uso del CPU junto con los debugs que ya estás corriendo. El problema es que necesitarías un software aparte que pueda trabajar con la información de Netflow que provee el equipo. Puede ser software de Cisco o bien externo que maneje los paquetes de Netflow:

http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ios-netflow/prod_white_paper0900aecd80406232.html

http://www.cisco.com/c/en/us/td/docs/ios/netflow/configuration/guide/12_2sr/nf_12_2sr_book.html

Saludos.

New Member

Ricardo, buenas tardes y

Ricardo, buenas tardes y gracias por responder, a través de las guías de configuración pude implementar con exito el netflow que exporta hacia un servidor externo, lo que no me queda claro cuales son los valores de standart  IP CACHE-FLOW TIMEOUT ACTIVE / INACTIVE y de que dependen dichos valores?

Otra consulta, cambiando de tema, en mi equipo tengo configurados alrededor de 400 túneles IPSec con crypto map dinamicos, lo me desconcierta y preocupa es que se generan muchísimas AS que difieren de la cantidad de clientes conectados (350 al mismo tiempo) tanto en fase 1 como en fase 2, esto se debe a mis tiempos de vida altos, o es resultado de algún omisión i/o error en la configuracion? pego detalles:

VPN-SERVER-MASTER#sh crypto isakmp sa count
Active ISAKMP SA's: 1404
Standby ISAKMP SA's: 0
Currently being negotiated ISAKMP SA's: 3
Dead ISAKMP SA's: 6


VPN-SERVER-MASTER#sh crypto ipsec sa count
IPsec SA total: 2340, active: 1014, rekeying: 0, unused: 1326, invalid: 0

Aquí la configuración:

VPN-SERVER-MASTER#sh crypto isakmp policy

Global IKE policy
Protection suite of priority 1
encryption algorithm: DES - Data Encryption Standard (56 bit keys).
hash algorithm: Message Digest 5
authentication method: Pre-Shared Key
Diffie-Hellman group: #2 (1024 bit)
lifetime: 86400 seconds, no volume limit


VPN-SERVER-MASTER#sh crypto ipsec profile
IPSEC profile default
Security association lifetime: 4608000 kilobytes/86400 seconds
Responder-Only (Y/N): N
PFS (Y/N): N
Mixed-mode : Disabled
Transform sets={
default: { esp-aes esp-sha-hmac } ,
}

Saludos ! y gracias nuevamente.

Cisco Employee

Esos dos contadores los

Esos dos contadores los podemos explicar de la siguiente manera:

IP CACHE-FLOW TIMEOUT ACTIVE - Es el tiempo en minutos que el router va a mantener información de este flujo dentro de la memoria antes de exportar la información al colector. Se llama activo, porque el router o equipo sigue viendo paquetes fluyendo. Por default son 30 minutos. Una conversación por lo general no tarda tanto tiempo activa.

IP CACHE-FLOW TIMEOUT INACTIVE - Es el tiempo en segundos que voy a mantener un flujo que ya no está intercambiando paquetes (por lo general una conversación ya terminada o interrumpida) antes de exportar la información al colector. Por default son 15 segundos.

Con respecto a los SA's va a depender de la fase de la que estamos hablando. Para fase 1, deberías tener una por cliente, pero ISAKMP tiene un tiempo de vida default de unas 24 horas, entonces es posible que en ocasiones veas más del número de clientes conectados porque les toma cierto tiempo borrarse de la tabla.

Para fase 2, IPSEC requiere crear un SA por cada flujo de tráfico. Es decir, si tienes un access-list de split-tunnel o un access-list que define el tráfico interesante a encriptar, cada línea del access-list que refleje un flujo de tráfico genera un SA. Por ejemplo, si tienes un access-list con 10 líneas, cada cliente por el simple hecho de conectarse tendrá 10 SAs de IPSEC ya sea que mande tráfico a estas redes o no.

New Member

Gracias Ricardo, me ha

Gracias Ricardo, me ha quedado muy claro Netflow.

Con respecto a las SA de IPSec, como puedo eliminar las que figuran como unused, hay algún dpd o timeout que podría configurar para que el equipo las detecte e elimine?

VPN-SERVER-MASTER#sh crypto ipsec sa count
IPsec SA total: 2340, active: 1014, rekeying: 0, unused: 1326, invalid: 0

Saludos !

Cisco Employee

Aquí debo hacer una pequeña

Aquí debo hacer una pequeña correción. El comando que estás usando registra cada SA unidireccional. Es decir que por cada línea del access-list de tráfico interesante, va a contar dos SA's unidireccionales: la SA con el SPI definido para encriptar tráfico de salida y la SA con el SPI definido para desencriptar el tráfico de entrada. El contador de unused es para SAs unidireccionales que no han encriptado ni desencriptado ningún paquete desde que se creó. Esas eventualmente expiran con el contador de timeout de IPSEC y se van borrando de la base de datos. Este timeout se configura con el siguiente comando:

crypto ipsec security-association lifetime

Nada más hay que tener cuidado en el valor que se utiliza aquí, ya que, en tu caso, tienes varios miles de SAs funcionando. Cada vez que el tiempo de vida está por expirar, IPSEC renegocia las llaves de las SAs que están activas y eso ocupa tiempo de operación en el CPU. Si pones un valor muy bajo de lifetime, vas a tener al CPU renegociando llaves constantemente, lo que podría traer otros problemas como aumento de utilización de CPU o si es mucho trabajo para el equipo algunos túneles se podrían perder porque no hubo tiempo/recursos disponibles para renegociar las llaves y tienen que re-negociarse por completo otra vez, teniendo pérdidas de tráfico y aumentando más el trabajo del CPU.

Otra opción es usar el temporizador sin actividad (idle-time) para borrar las SAs que no se están usando durante cierto tiempo:

crypto ipsec security-association idle-time <time>

También hay que tomar en cuenta que al usar este otro parámetro ya no vamos a esperar el lifetime completo del SA, pero podríamos afectar a túneles que no mandan tráfico constantemente y dichos túneles tendrían que renegociar todo otra vez después de ser borrados. Todo es cuestión de ir viendo qué opción sirve más para tu implementación.

New Member

Ya me queda claro porque veo

Ya me queda claro porque veo tantas SA en IPSec, my crypto acl tiene tres lineas, o sea que por cada tunel se generan 6 SA, en el caso de mi implementacion algunos peers utilizan una linea de esta acl y otros solo dos, por lo consiguiente siempre quedan SA sin utilización, por lo que deberían ser eliminados por crypto ipsec security-association idle-time.

Los paquetes de keepalive que envía tanto el peer como equipo a través del túnel son considerado trafico y por lo tanto afectan el idle-time?

La expiracion de las AS a través de crypto ipsec security-association idle-time se suceden de manera independiente en cada túnel, atado a cuando estas se crearon, entiendo que el problema se daría tras un reload del equipo y que todos lo túneles re negocien a la vez, esto es así?

Estoy utilizando un 2911 con modulo VPN, cual es el numero de AS que puede manejar?, tengo dudas que al tener configurado muy alto los lifetime (24hs) en fase uno y default en dos y sin idle-time para las no utilizadas, haya superado un máximo de SA, en algunas oportunidades tuve problemas con alrededor de 50 túneles que no se me formaban.

Esta es la configuración que estoy preparando:

!
crypto isakmp policy 1
hash md5
authentication pre-share
group 2
lifetime 14400
crypto isakmp key xxxxxxxx address 0.0.0.0
crypto isakmp keepalive 10 periodic
!
!
crypto ipsec transform-set Set_Agencias esp-des esp-md5-hmac
mode transport
!
crypto ipsec profile IPSec_Profile1
set security-association lifetime seconds 3600
set security-association idle-time 120
set transform-set Set_Agencias
responder-only
!

Los tiempos de vida de la primera fase deben ser mayores que de la segunda o es indistinto?

Gracias por toda la ayuda !

Cisco Employee

Aquí las respuestas:

Aquí las respuestas:

> Los paquetes de keepalive que envía tanto el peer como equipo a través del túnel son considerado trafico y por lo tanto afectan el idle-time?

Depende del tipo de keepalive al que te refieres. Si son DPD's para IKE, estos se manejan sobre isakmp y no IPSEC, por lo que no afectan al contador de idle-time. Si por otro lado, son keepalives que se mandan como parte del tráfico interesante del túnel, estos sí reiniciarían el contador de tiempo inactivo, ya que cada vez que se use la SA, se genera actividad en el túnel y se reinicia el contador.

> La expiracion de las AS a través de crypto ipsec security-association idle-time se suceden de manera independiente en cada túnel, atado a cuando estas se crearon, entiendo que el problema se daría tras un reload del equipo y que todos lo túneles re negocien a la vez, esto es así?

Los túneles expiran de manera independiente. En un tiempo aleatorio antes de que el lifetime termine, se inicia el proceso de re-key para los túneles activos, por lo que por regla general los túneles no renegocian al mismo tiempo aún cuando todos los túneles se hayan construído a la misma hora en primera instancia. Ahora bien, no todo en programación es perfectamente aleatorio, por lo que existe la posibilidad de que varios túneles renegocien al mismo tiempo, pero no debería ser problema para el equipo. Por otro lado, el contador inactivo (idle-time) empieza cuando el SA deja de encriptar/desencriptar tráfico, una vez llegado el tiempo límite la SA se borra de la base de datos y es independiente de cuándo se generó el túnel.

> Estoy utilizando un 2911 con modulo VPN, cual es el numero de AS que puede manejar?

Desconozco los límites del equipo, pero por lo general lo puedes revisar con el comando "show crypto eli".

> tengo dudas que al tener configurado muy alto los lifetime (24hs) en fase uno y default en dos y sin idle-time para las no utilizadas, haya superado un máximo de SA, en algunas oportunidades tuve problemas con alrededor de 50 túneles que no se me formaban.

Si has tenido problemas con la generación de túneles porque podrías estar cerca del límite máximo de túneles, te recomendaría abrir un caso en el TAC para analizar por qué razón no se establecen los túneles.

> Los tiempos de vida de la primera fase deben ser mayores que de la segunda o es indistinto?

La implementación de IKE de Cisco maneja los tiempos de Fase 1 y Fase 2 independientes entre sí. Por eso en ocasiones podrías no ver un SA de Fase 1 mientras los SAs de Fase 2 siguen funcionando sin problemas.

New Member

Gracias por responder con

Gracias por responder con tanta dedicación, he dado con el problema de conexión de mis túneles, aparentemente se exceden los máximos de SA que puede manejar el equipó:

VPN-SERVER-MASTER#sh crypto ipsec sa count
IPsec SA total: 3200, active: 694, rekeying: 0, unused: 2506, invalid: 0

He aquí la verificación de máximos con sh crypto eli :

VPN-SERVER-MASTER#sh crypto eli
Hardware Encryption : ACTIVE
Number of hardware crypto engines = 1

CryptoEngine Onboard VPN details: state = Active
Capability : IPPCP, DES, 3DES, AES, GCM, GMAC, IPv6, GDOI, FAILCLOSE, HA

IPSec-Session : 618 active, 3200 max, 42635 failed

Todo se soluciona cuando hago clear crypto sa y limpio todas las SA, he configurado los ipsec idle-time a 120 segundo, pero no entiendo porque motivo no se borran las SA sin utilizar (unused: 2506) ya que están me llenan los contadores, he intentado bajar los lifetime de isakmp e ipsec a 3600 pero el problema se agrava, ya que al cabo de la hora de vida pasan todas la SA activas a inactivas y no se eliminan y así sucesivamente hasta alcanzar el limite de 3200 deteniendo todos los intentos de conexión y generando errores (PSec-Session : 618 active, 3200 max, 42635 failed), tambien he comprobado que al flapear la conexion a mi ISP hace que los tuneles pasen a inactivos en pocos minutos volviendo a llenar el contador de maximas. Quizas este fallando en la configuracion la cual pego mas abajo, tambien estoy pensado en realizar un EEM que pueda leer la cantidad de SA periodicamente y si pasa un limite realizar un clear crypto sa, pero nunca he realizado alguno. estoy desconcertado, aguardo sus útiles opiniones al respecto.

crypto isakmp policy 1
hash md5
authentication pre-share
group 2
crypto isakmp key 47434011 address 0.0.0.0
!
crypto ipsec security-association lifetime seconds 86400
crypto ipsec security-association idle-time 120
!
crypto ipsec transform-set Set_Agencias esp-des esp-md5-hmac
mode transport
!
crypto ipsec profile default
responder-only
!
!
crypto dynamic-map SDM_DYNMAP_1 1
set transform-set Set_Agencias
match address 2081

Cisco Employee

Estuve buscando algo m[as de

Estuve buscando algo m[as de información sobre este asunto. Y encontré que en algunas plataformas la salida del comando "show crypto ipsec sa count" no siempre muestra la información correcta sobre las SAs disponibles, por lo que no todos los contadores en "unused" serían necesariamente correctos. Al parecer necesitas hacer un "show crypto ipsec sa" antes de ejecutar el comando con "count" para refrescar la información.

Esto es parte de un bug interno. Posiblemente podrías verificar si esto es correcto y abrir un caso en el TAC para más información.

New Member

Ok, muchas gracias, he

Ok, muchas gracias, he ejecutados los comandos y por el momento no encontré discrepancia entre sh crypto ipsec sa, sh crypto ipsec sa count y sh crypto eli, hace unos días supere el limite máximo de SA generando errores que verifico en sh crypto eli y no permitiendo la conexión de nuevas vpn. 

Estoy barajando la posibildad de realizar un script con EEM, que lea el total de de SA de sh crypto ipsec sa count y si este se excede realizar un clear ipsec sa.

Esto es posible con EEM?

Cisco Employee

Me parece que sí es posible

Me parece que sí es posible hacer eso con EEM, pero creo que la parte de "leer" el total de SAs desde un comando se hace a través de un script de TCL.

http://www.cisco.com/c/en/us/td/docs/ios/netmgmt/configuration/guide/12_2sx/nm_12_2sx_book/nm_eem_policy_tcl.html

72
Visitas
0
ÚTIL
11
Respuestas
CrearPor favor para crear contenido