"Cuanto más sudes ahora, menos sangrarás en el campo de batalla". Troubleshooting Paloalto

¿Se te ha puesto esta cara con algunos problermas de PAN? Tranquilo, seguro que nadie te hará una foto ;)

Problemas inesperados entre la capa de gestión(Candidate config) y la de ejecución del Paloalto(running config).

• No se puede sincronizar la configuración entre el activo y el pasivo.
• No se puede hacer un commit al principal. Dice que ha perdido la conexión con el servidor de gestión(Cannot connect with the management server)
• El commit tarda mucho o el commit cada vez es mas lento.

Solución: Resetar los procesos de management server y device server. 

Background: Los demonios no se depuran y crecen muriendo por lentos. Hay diversas causas como el navegador.

NOTA: Este reset de procesos no afecta al tráfico que pasa por el equipo. Se puede hacer sin esperar a una ventana de intervención, sería como cerrar el navegador y volverlo abrir.

Ejecutar desde CLI:(Ni caso que se llame debug)

1. debug software restart management-server
2. debug software restart device-server

Hacer un show system resources para verificar que los procesos se han reiniciado.

BUG, de identificación de usuarios mediante pan-agent y directorio Activo.

• Los usuarios validados en el Directorio Activo se saltan las reglas de seguretat. Son identificados dentro del dominio pero aparecen como desconocidos(unknown). Todos los usuarios pueden hacer todo lo que permitan las reglas con usuarios.

Solución: Hacer un upgrade del agente cuando sala la nova versión. 

Mitigación, desactivar la comprobación por netbios y en el servicio de PANAGENT, configurar las tres acciones para cuando se quede colgado, como reiniciar.

Aplicaciones o comunicaciones lentas:

• PAN, no deja pasar los paquetes ICMP code 4 type 3(Fragmentation needed) que notifican que la mtu es demasiado grande. Eso implica que ciertas conexiones(VPN, WIFI y WANs) funcionen muy lentas. 

Solución: Definir una custom application con icmp code 4 pero en la regla de seguridad definir el servicio como default-application.

Permitir toda la navegación, no solo http y https.

Crear una "application filter" por tecnología: Browser-based. Son 489 aplicaciones como web-browsing(http), ssl, flash, youtube, facebook...etc

Ver la configuración formato comando y no estructura xml (Muy útil para cisqueros)
 set cli config-output-format set

Robclav

Cisco SECUREX, Next Generation....Architecture

Bien, en este blog he analizado algunos de los últimos productos que siguen la estela de Paloalto Networks.  Pero el gigante ha despertado, Cisco enseña sus cartas.(Actualización 18-06-2011)

Checkpoint por ejemplo, uno de los firewalls convencionales que más me gustan para entornos distribuídos, ha sufrido el problema de una maquinaria lenta y anquilosada.  Esto lo ha confirmado el mismo fabricante en la revista SIC. Checkpoint está dando un giro admitiendo que la visibilidad en la red tenia que ser mejorada, pero tiene varios problemas:

1. El primero es que ha maltratado al canal con unas condiciones de mantenimiento Draconianas. Al final eso seleccionaba el canal, garantizaba unos ingresos importantes,  pero al final el cliente tenia una percepción de CP muy inferior a la calidad real, debido a la imposibilidad(a la práctica) de abrir casos directamente. Así que la mayoría de las instalaciones se aguantaban con pinzas. Y sinó, ¿cuántas veces hemos visto, firewalls CP en activo-pasivo por que el técnico no sabia solucionar el problema de mac multicast de uno de los modos de activo-activo?
2. El segundo, que son dispositivos muy orientados a multinacionales y que en el resto de segmentos, se habían quedado muy atrás.

 Fortinet, en un artículo de su CEO, reconoce que ahora están evolucionando y que ahora quieren adquirir una empresa que les aporte futuro. Parece que solo ganan las batallas con firewalls convencionales... y cuentas pequeñas.
Pero, ahora viene el notición. Al menos para mí.(gracias VICTOR)
Parece que CISCO ya tiene su respuesta. Y no estamos hablando de una start-up de cuatro estudiantes en un garaje. La propuesta de Cisco se llama SECUREX(Sí, tiene nombre de condón). Promete hacer varias cosas que hace muy bien los PAN....y algunas más.
Seguramente, se acerca más a la seguridad normativa clásica, en la cual tiene en cuenta TODOS los activos de la red. Un ejemplo, seria si una persona está en el edificio o está de vacaciones. Y este tipo de cosas. 
Pero a parte de que solo conozco lo que dice en la web Cisco securex, la clave sería ver cuantos elementos hacen falta para que esta arquitectura funcione.  Si se trata de un ex-Cisco MARS+ASA+HIPS+IDP+Cisco Works+NAC, seguramente es más sencillo, reconfigurar una IOS para que comporte como un Paloalto.
Si es un appliance que hace todo eso, habrá que seguirlo. Evidentemente si está basado en IOS y no han hecho un refrito de FINESE(ahora ASA) versión UTM.  En la web, a veces parece una arquitectura y otras una tecnología que incorporan los ASAs(Ojo con la madurez de la solución). Los betatesters pueden sufrir bastante o cisquearse para siempre. 
Aún así tendremos que ver precios, cumplimiento de expectativas y evolución de PAN que en cada versión saca un conejo de la chistera.
Por cierto a PAN, le pediría que hubiese una parte de soporte abierta para no partners. Así como carta a los reyes. A Cisco, que alguien me aclarase las dudas.


Actualización: Me temo que los peores presagios se han confirmado. Cisco, tiene todo esto en punto muerto, http://etherealmind.com/cisco-securex-empty-words/
Robclav

CISCO PFR, Balanceo de líneas por aplicación

AVISO PARA NAVEGANTES: Este post es durillo de leer y asumo ciertos conocimientos sobre funcionamiento de los protocolos dinámicos de routing y la nomenclatura de algunas herramientas de la IOS.




Hace tiempo que quería profundizar sobre OER. Una funcionalidad que creía que no había evolucionado demasiado y que al principio no aportaba demasiado diferencial al margen de control sobre la utilización de las líneas basado en criterios arbitrarios. 
El escenario donde se puede plantear OER(o su evolución PFR)  es el siguiente:
Tienes dos sedes interconectadas por varios enlaces con características diferentes. Por ejemplo una línea dedicada de dos Mbps y dos ADSL de 16 Mbps. Quieres aprovechar las tres líneas, y en el caso de que una línea falle, que el tráfico desviado hacia esta línea sea automáticamente enviado por alguna de las otras dos líneas.
¿Cómo se resuelve habitualmente este escenario?

• Creas un túnel GRE por cada conexión que tengas. Esto permitirá encapsular protocolos de routing que utilicen multicast y otro tipos de aplicaciones que de otra forma serian descartadas.
• Activas EIGRP, que es el único protocolo interno de routing dinámico que permite balancear tráfico por dos líneas con propiedades diferentes. Esto se realiza mediante el comando "variance". Evidentente redistribuyes las redes directamente conectadas al otro extremo mediante EIGRP.
• Sí, las líneas no son dedicadas, cifras el túnel GRE y todo su contenido mediante un túnel IPSEC.

Esta arquitectura, nos ofrece total seguridad, alta disponibilidad y balanceo de líneas desiguales. ¿Pero cuáles son las limitaciones entonces?

• No podemos decidir que tipo de tráfico viajará por línea.
• No podemos decidir la carga de cada línea en función de nuestros intereses. Por ejemplo, de tarificación, de criticidad de aplicaciones, de QoS...etc
• No podemos decidir en como el tráfico entra por estas líneas, solo como lo enviamos nosotros.
• No podemos decidir cambiar una aplicación por criterios como el tiempo de respuesta de una aplicación o el jitter. Con EIGRP, se hace por carga global de la línea.
• Es necesario invertir muchas semanas de trabajo para emular algo parecido utilizando: IP SLA, EEM y policy-maps para lograr tener la flexibilidad y granularidad que nos ofrece CISCO PERFORMANCE ROUTING 

¿Pero cuál es la definición de CISCO PFR?

"Performance Routing (PfR) complements traditional routing technologies by using the intelligence of a Cisco IOS infrastructure to improve application performance and availability. This technology can select the best path for each application based upon advanced criteria such as, reachability, delay, loss, jitter, and Mean Opinion Score (MOS)." Bien, entonces el resumen de PFR es que cumple con todo aquello que la solución expuesta anteriormente no hace. Asi que, si tenemos que balancear líneas iguales o no, podemos utilizar Performance routing, que se encarga de medir el rendimiento de las líneas con variables asociadas a aplicaciones. Dejando en nuestras manos la posibilidad de aplicar críterios propios en función de aplicación o tarificación por ejemplo. También destacar que interacciona con los protocolos de routing dinámicos existentes, modificando su comportamiento. Pero, ¿Cómo lo hace para conocer las rutas y modificar el enrutado del tráfico? Se basa en un esquema de cliente-servidor que le permite intercambiar información entre dos routers que lo tengan habilitado, y finalmente modifica el enrutado inyectando rutas o mediante PBR(Policy Based Routing). Es capaz incluso de modificar el comportamiento del BGP añadiendo AS para penalizar la entrada de tráfico por un camino por ejemplo.  Por otra parte, es preciso personalizar alertas y limites de IP SLA en las que se basa para la toma de decisiones, y tener activado IP CEF junto con NBAR para reconocer las aplicaciones de forma básica. Puedes encontrar más información en la web CISCO OER Robclav

Evolución del routing I

Hace unos cuantos meses me preguntaba cuál era la evolución o el siguiente paso de los protocolos de routing. El routing predictivo. Actualmente todos los protocolos de enrutamiento dinámicos se basan en algo que conocen. Estos incorporan mejoras respecto a y que se puede intercambiar de forma más o menos eficiente, teniendo en cuenta más o menos variables. Pero que pasará cuando los sistemas aprendan y tomen decisiones en función de la experiencia? El routing predictivo is out there.
RobClav