ICMP Pegado despues de fail-over.
Publicado: 20 Oct 2015, 19:17
Con respecto al caso se puede decir que son dos puntos los que se deben solucionar, aunque en sí tienen relación y solucionando el primero automáticamente se solucionaría el segundo.
Escenario.
Sitio Central
- Se tienen Dos Enlaces a internet, uno dedicado y un ADSL asimétrico. (WAN1 y WAN2)
- Se tienen Tres redes en diferentes interfaces del firewall. (LAN-1, LAN-2, LAN-3)
- Las redes LAN-1 y LAN-2 deben salir a internet por el enlace Dedicado siempre, pero si este fallara deben salir por el secundario.
- La Red LAN-3 debe salir por el enlace ADSL y cuando este falle debe salir por el dedicado. (policy Route)
En ambos casos, cuando su enlace original se reestablezca, el tráfico se debe regresar automáticamente según corresponda.
Sitio Remoto:
- Firewall con Servicio ADSL y VPN hacia el sitio central
Problemática 1 – Fail-Over:
Cuando ocurre un corte en el enlace correspondiente y después se reestablece el servicio, el Firewall mantiene la sesión ICMP por el enlace que entró como respaldo, y esta no se “regresa” automáticamente al enlace por donde se supone la red debe salir originalmente y no es hasta que la sesión se termina por inactividad (cosa que nunca ocurrirá por ser un sistema de monitoreo por ping continuo) o cuando se termina manualmente dicha sesión.
Ejemplo. Si tengo un ping continuo de la LAN-3 (192.168.6.1) hacia 8.8.8.8 esta sesión originalmente sale por WAN2, si ocurre un corte en el servicio el ping ahora sale por WAN1, y si el servicio se reestablece, el ping continúa saliendo por WAN1, no se regresa a WAN2, sólo las nuevas sesiones generadas salen por WAN2.
Problemática 2 - VPN:
Al parecer es el mismo comportamiento, pero ahora en las VPN’s, si hay un ping continuo desde la LAN-1(192.168.1.1) hacia la IP 192.168.7.254(firewall remoto) y la VPN está establecida, éste contesta, si la VPN se cae, el Ping ahora es enviado hacia la WAN-1 y éste no responde, cuando la VPN se establece nuevamente, el Ping continúa hacia la WAN-1 y no se re direcciona, aunque el túnel esté activo, de igual forma solo las sesiones nuevas serán enviadas correctamente, pero estas sesiones “persistentes” no.
Entonces, el problema radica en las sesiones que se quedan “pegadas”, y no regresan a donde deberían de estar, esto implica un falso-positivo para el monitoreo interno del cliente y su sistema ERP que también censa el estatus de la disponibilidad de sus dispositivos.
Alguna Idea?
Escenario.
Sitio Central
- Se tienen Dos Enlaces a internet, uno dedicado y un ADSL asimétrico. (WAN1 y WAN2)
- Se tienen Tres redes en diferentes interfaces del firewall. (LAN-1, LAN-2, LAN-3)
- Las redes LAN-1 y LAN-2 deben salir a internet por el enlace Dedicado siempre, pero si este fallara deben salir por el secundario.
- La Red LAN-3 debe salir por el enlace ADSL y cuando este falle debe salir por el dedicado. (policy Route)
En ambos casos, cuando su enlace original se reestablezca, el tráfico se debe regresar automáticamente según corresponda.
Sitio Remoto:
- Firewall con Servicio ADSL y VPN hacia el sitio central
Problemática 1 – Fail-Over:
Cuando ocurre un corte en el enlace correspondiente y después se reestablece el servicio, el Firewall mantiene la sesión ICMP por el enlace que entró como respaldo, y esta no se “regresa” automáticamente al enlace por donde se supone la red debe salir originalmente y no es hasta que la sesión se termina por inactividad (cosa que nunca ocurrirá por ser un sistema de monitoreo por ping continuo) o cuando se termina manualmente dicha sesión.
Ejemplo. Si tengo un ping continuo de la LAN-3 (192.168.6.1) hacia 8.8.8.8 esta sesión originalmente sale por WAN2, si ocurre un corte en el servicio el ping ahora sale por WAN1, y si el servicio se reestablece, el ping continúa saliendo por WAN1, no se regresa a WAN2, sólo las nuevas sesiones generadas salen por WAN2.
Problemática 2 - VPN:
Al parecer es el mismo comportamiento, pero ahora en las VPN’s, si hay un ping continuo desde la LAN-1(192.168.1.1) hacia la IP 192.168.7.254(firewall remoto) y la VPN está establecida, éste contesta, si la VPN se cae, el Ping ahora es enviado hacia la WAN-1 y éste no responde, cuando la VPN se establece nuevamente, el Ping continúa hacia la WAN-1 y no se re direcciona, aunque el túnel esté activo, de igual forma solo las sesiones nuevas serán enviadas correctamente, pero estas sesiones “persistentes” no.
Entonces, el problema radica en las sesiones que se quedan “pegadas”, y no regresan a donde deberían de estar, esto implica un falso-positivo para el monitoreo interno del cliente y su sistema ERP que también censa el estatus de la disponibilidad de sus dispositivos.
Alguna Idea?