En mi empresa tenemos montada una VPN con otra empresa del grupo. Un extremo tiene un ADSL 2Mb (Telefónica) sobre RDSI con un router Alcatel SpeedTouch. En el otro punto tenemos un ADSL sobre RTB (Efficient SpeedStream 5560). En ambos routers he abierto el puerto TCP 1723 y el protocolo 47 (GRE) y lo he mapeado usando NAT al servidor VPN que hay en el interior (Windows 2000 Server, usando Enrutamiento y Acceso Remoto). Para esta configuración VPN todo está correcto y funcionando sin problemas desde hace más de 1 año. Llamemos a esta red AB.
Nuevo escenario: Abrimos otro centro de producción, llamémoslo C. Pues nada, otra VPN al canto... que esto ya está probado. Contratamos otra ADSL de 2Mb sobre RDSI con el mismo router Alcatel SpeedTouch (para que poner otro si de este ya me conozco la configuración y tal...). Colocamos otro servidor, en este caso Windows 2003 Server con el Enrutamiento y Acceso Remoto, etc. El router configurado igual que el otro Alcatel. La idea es tener: CAB
Pues bien; la conexión VPN de marcado bajo demanda se establece a esta nueva sede C sin problemas incialmente. Pero a los 53 segundos de conexión (cuando a través del enlace hay un mínimo tráfico) se corta. En el Registro de Eventos de Windows encuentro entradas del tipo:
El usuario MYDOMAIN.COM\Dial-On-Demand User conectado al puerto VPN4-126 en 11/24/2003 a las 04:30p.m04:31p.m53 y desconectado de 11/24/2003 a las 04:31p.m53. El usuario estuvo activo durante 0 minutos y 53 segundos. Se enviaron 555737 bytes y se recibieron 84319 bytes. La velocidad del puerto fue de 10000000. El motivo de desconexión fue solicitud del usuario.
Lo cual es muy extraño, pues las VPNs están configuradas como permanentes: Ninguna de las 2 partes que participan de la red privada la desconectan jamás (a no ser que se reinicie uno de los servidores o se detenga el servicio de Enrutamiento o Acceso Remoto).
Como ya digo esto ocurre sólo con una de las VPNs, la parte nueva CA. Mientras tanto, la parte AB sigue funcionando sin prolemas.
Y yo me pregunto... de igual modo que ciertos ISPs bloquean el acceso a servidores remotos a través del puerto tcp 4662 para evitar el tráfico p2p... ¿no habrá empezado Telefónica a hacer de las suyas con otros puertos? ¿Podría telefónica estar inyectandome (spoofing) paquetes para cerrar mis conexiones VPN? Si no estoy mal informado, ahora Telefónica ofrece cobrando lo mismo que yo estoy montándome por mi cuenta (Solución ADSL NetLan).
Para mas señas: Las 2 VPNs (CAB) han funcionado durante este fin de semana perfectamente. Sin embargo, este lunes por la mañana, a las 8:00am, en cuanto ha empezado ha haber tráfico entre las sedes la VPN nueva ha empezado a presentar los síntomas que detallo, los mismos que estuvo dando hasta el viernes pasado por la tarde.
Aún hay más: El resto de tráfico con protocolos orientados a la conexión (p.ej RDP, Remote Desktop Protocol, usando el perto 3389 TCP) funcionan perfectamente. De hecho esta mañana, mientras se sucedían las desconexiones de la VPN sin razón aparente, he mantenido una sesión de terninal sever de más 5 horas con el servidor VPN C (pero usando la red pública, ya que la privada se desconectaba cada 2 por 3.
No se trata de pérdida de paquetes, ni de pérdida de paquetes selectiva cuando el puerto de destino es el TCP 1723. Según me da la impresión, se trata de spoofing de paquetes especialmente preparados para dar por finalizada la sesión de los usuarios remotos (ya que ninguna de las 2 partes implicadas solicita la desconexión).
¿Me estaré volviendo paranoico? ¿A alguien más le ocurre algo similar? Mis jefes no paran de meterme presión para que termine de poner en marcha algo que les dije sería coser y cantar y se me están acabando las ideas, porque explicaciones para este problema que tengo no se me ocurren.
Me ha salido un post un poco largo, pero no veía como resumirlo. Gracias por leerme hasta el final, y muchas más gracias si aportas alguna idea constructiva :) Las necesito.