Duda ENORME con VPN (SonicWall - Azure)

[Hache_Tilted]

Buenos días,

Os voy a comentar un poco la situación general a la que me estoy enfrentando, a ver si podéis arrojar un poco de luz.

Trabajo en una empresa en la que usamos los firewalls de SonicWall para aportar seguridad y sobretodo para montar VPN's con azure (site to site de toda la vida). Hasta aquí todo bien y no es algo complicado.
El problema viene que desde hace unos días tenemos un cliente que de la manera que tiene la topología de red complica todo esto.
Voy a subir una captura para que veáis como la tiene el cliente y otra captura de como la montamos nosotros de normal.
Topología del cliente: ellos hosted at ImgBB
Nuestra topología que montamos de normal: nosotros hosted at ImgBB

- El caso está en que montar no hemos montado nada físicamente, estamos haciendo pruebas antes. Porque básicamente toca usar la interfaz de WAN del Firewall a enrutar de vuelta en la misma interfaz WAN, y está dando problemas. Porque siempre que hemos configurado la VPN era de entrada la LAN y de salida la WAN/VPN y de ahí el firewall sabe a donde mandar todo. Pero estando solo en la interfaz de WAN en la que van conectados los equipos, el router y el firewall parece que le da problemas.
Da problemas porque hemos logrado conectividad, pero es una conectividad que pierde. Por ejemplo, hemos configurado un Terminal Server, y a este desde Azure nos conectamos sin problemas y no falla ni una vez, pero desde aquí a Azure responde 1 de 4 veces que le das a conectar, eso si, una vez se ha conectado no se desconecta. Lo cual me da a entender que hay un problema de enrutamiento cuando tiene que salir desde aquí hacia Azure.

No podemos cambiar la topología del cliente, ya que es un cliente grande y no puede parar (y no me van a pagar 2000 euros para ir a montarlo un fin de semana jajajaja), así que la implementación debe hacerse en horas de producción. Por ende nos vemos obligados a que coexistan de manera temporal hasta que todo se migre bien, los 2 firewalls, uno el que ya está ahí (mikrotik) y el que llevaremos nosotros (sonicwall) dejando una topología como esta: FUSION hosted at ImgBB

Y aquí viene la pregunta: ¿Alguien tiene idea de por qué puede ser que no termina de saber como enrutar hacia Azure? ¿Que reglas de enrutamiento me recomendaríais?, ¿o que pruebas hacer?.

El objetivo a conseguir: Necesito lograr que los equipos que necesiten conectarse a Azure (porque tienen ahí un programita de gestión, nada más) el SonicWall sepa enrutarles hacia fuera sin problema. Y cuando quieran salida a internet NO pasen por el SonicWall, debido a que su topología es estúpida de narices no tiene ningún sentido.

Sé que es bastante denso todo esto pero llevamos exprimiendo nuestro cerebro y no logramos dar con la tecla, pero debe poder hacer si o si y estoy convencido que se me pasa algo por alto, más que nada, porque en el lugar del cliente el firewall lo tienen montado de la misma manera que pretendemos hacerlo nosotros, pero con éxito.


Gracias de antemano.

 

[Armadval]

Como me molan estas movidas

Lo primero de todo. Cual es el gateway de los equipos de la red a la que quereis dar soporte? porque necesitais que de alguna forma pasen por vuestro FW, o que pasen por algun lado en el cual vosotros podais añadir una ruta estática para que X tráfico sea redirigido hacia la dirección que vosotros querais.

Aún me cuesta entender todo el post, pero te voy a citar una cosa rara y que igual deberiais hacer un especial énfasis en ella:

Da problemas porque hemos logrado conectividad, pero es una conectividad que pierde. Por ejemplo, hemos configurado un Terminal Server, y a este desde Azure nos conectamos sin problemas y no falla ni una vez, pero desde aquí a Azure responde 1 de 4 veces que le das a conectar, eso si, una vez se ha conectado no se desconecta

Que se conecte, a veces si, a veces no, y esa conexion no se pierda, indica que algo está mal ahi, una ruta duplicada que a veces va por un lado y otras por otro dependiendo del peso, yo me huelo que van a ir por ahi los tiros, pero siempre lo digo, en temas de redes, es una ciencia exacta, las aleatoriedades indican fallos de configuración.

Al final una VPN es una regla de enrutamiento muy sencilla, que se limita a que cuando un equipo quiere acceder a una IP de una subred, el tráfico en vez de enviarse por la "WAN" se envía por la interfaz de la VPN. Tened en cuenta que, si se da la casualidad de que vuestra red local coincide con alguna otra red local del cliente, pueda generarse tráfico incorrecto (de hecho deberia ser imposible generarlo). Me refiero:

Si vuestro servidor Azure lo estais conectando con una VPN, y su red local es la 10.10.10.0/24 , pero el cliente tiene en alguna otra delegación o internamente otra red 10.10.10.0/24, es posible que el FW de vuestro cliente no sepa devolver ese tráfico correctamente.

 

[pky]

En mikrotik del cliente: masquerade a la subred de la VPN. Y en el router de fuera, del cliente, el que da internet, una ruta estática que diga que, a vuestra subred, se llega usando el mikrotik como gateway (la IP LAN que tiene ese dispositivo).

Y, como os dice el compañero, ojo con no solapar subredes que existan en ambos extremos. En la parte del mikrotik, lo podéis paliar con una regla de de NAT de tipo netmap.

Saludos!

 

[Hache_Tilted]

Como me molan estas movidas

Lo primero de todo. Cual es el gateway de los equipos de la red a la que quereis dar soporte? porque necesitais que de alguna forma pasen por vuestro FW, o que pasen por algun lado en el cual vosotros podais añadir una ruta estática para que X tráfico sea redirigido hacia la dirección que vosotros querais.

Aún me cuesta entender todo el post, pero te voy a citar una cosa rara y que igual deberiais hacer un especial énfasis en ella:



Que se conecte, a veces si, a veces no, y esa conexion no se pierda, indica que algo está mal ahi, una ruta duplicada que a veces va por un lado y otras por otro dependiendo del peso, yo me huelo que van a ir por ahi los tiros, pero siempre lo digo, en temas de redes, es una ciencia exacta, las aleatoriedades indican fallos de configuración.

Al final una VPN es una regla de enrutamiento muy sencilla, que se limita a que cuando un equipo quiere acceder a una IP de una subred, el tráfico en vez de enviarse por la "WAN" se envía por la interfaz de la VPN. Tened en cuenta que, si se da la casualidad de que vuestra red local coincide con alguna otra red local del cliente, pueda generarse tráfico incorrecto (de hecho deberia ser imposible generarlo). Me refiero:

Si vuestro servidor Azure lo estais conectando con una VPN, y su red local es la 10.10.10.0/24 , pero el cliente tiene en alguna otra delegación o internamente otra red 10.10.10.0/24, es posible que el FW de vuestro cliente no sepa devolver ese tráfico correctamente.

Hola! Muchas gracias por tu tiempo en responderme. Te comento.

El gateway en los equipos es el router de Movistar que concreto es la 192.168.0.2/24. ()

Y si, en cuanto a la conectividad que llega bien desde fuera pero cuando tiene que salir desde aquí que se pierda tiene que ser si o si algo del enrutamiento y que se hace la picha un lio el pobre. Porque si montamos nuestro firewall, como tiene que convivir en paralelo con el otro (el que ya estaba ahí), nos da miedo que pierda conectividad y es una empresa que NO puede parar. Entonces solo podemos optar por lo que podemos recrear y probar por nuestros propios medios.


Tampoco se pisan nuestra subredes, ya que es algo que tenemos muy en cuenta por anteriores eventos.

Lo que yo quiero es lograr redirigir ese tráfico al firewall cuando se hagan peticiones para la VPN, y el resto del tráfico que salga a internet sin más complicaciones a través del router. Esto se hacerlo (split tunneling), si el firewall estuviese montado donde toca.

Por cierto! Al MikroTik que está montado, no tenemos acceso y no creo que nos lo den, ya que lo montó otra empresa.

Me han surgido un par de ideas gracias a tu publicación, muchas gracias!

Sé que igual no está redactado de la forma más comprensible. Saludos!

 

[Armadval]

Y si, en cuanto a la conectividad que llega bien desde fuera pero cuando tiene que salir desde aquí que se pierda tiene que ser si o si algo del enrutamiento

Haced varios tracert desde dentro de la red hacia azure y mirad donde se pierde el ultimo salto, donde se pierda, es lo que os está jodiendo.

 

[pky]

Vale, entonces la cosa cambia. Pensaba que el mikrotik era quien tenía que levantar el túnel a vuestra infra, ¿es así, o es otra VPN esa?. ¿Qué montáis vosotros para levantar el site to site, el sonic wall? Si es otra pieza intermedia que tenéis que poner en la infra del cliente, en ese caso píntala porfa. Lo que tiene montado vuestro cliente es una infra de lo más común cuando, por ejemplo, te piden que les montes un servidor VPN, pero que no toques absolutamente nada de la infra existente.

Insisto, todo lo que necesitas es decirle al router que maneje la tabla de rutas (sea el mikrotik o el otro), que a vuestra subred se llega por la IP del chisme que sea que levante la conexión. Si fuera el mikrotik, a su IP WAN.

Incluso cuando no tenéis acceso al mikrotik, podéis intentar replicarlo en un entorno virtual con una imagen CHR (router virtual) y, si os pasan la config que tiene montada (que se la pidan a la empresa proveedora, es tan sencillo como que accedan y hagan un export), podéis simular la implantación de lo vuestro de manera segura, y luego llegar y aplicar los cambios necesarios.

Pero lo más importante de ese setup es que identifiquéis quién es el gateway (sea un router, un server o cualquier otro elemento de red) que va a levantar el túnel, y enrutéis en el router de la operadora para decirle: tú no tienes ni papa de quien es esta subred, pero yo te digo que se llega por aquí.

Saludos!

 

[Hache_Tilted]

Haced varios tracert desde dentro de la red hacia azure y mirad donde se pierde el ultimo salto, donde se pierda, es lo que os está jodiendo.

Al final lo hemos logrado haciendo lo siguiente:

Usar la interfaz LAN del firewall, aunque fuese directamente al router. Después en el enrutamiento le hemos dicho que de un rango de IP's privadas las enrutara hacia fuera, porque al principio habiamos puesto el rango entero pero como el router esa interfaz también tiene una IP de ese rango se quedaba en bucle y no salía a fuera.
Al final la solución ha sido relativamente sencilla, y realmente el escenario tampoco era tan complejo más que lioso.

Muchas gracias por vuestra ayuda, me habéis aportado nuevas ideas y gracias a ellas he podido hacer más pruebas para dar con la tecla.

Un saludo!

 

[Hache_Tilted]

Vale, entonces la cosa cambia. Pensaba que el mikrotik era quien tenía que levantar el túnel a vuestra infra, ¿es así, o es otra VPN esa?. ¿Qué montáis vosotros para levantar el site to site, el sonic wall? Si es otra pieza intermedia que tenéis que poner en la infra del cliente, en ese caso píntala porfa. Lo que tiene montado vuestro cliente es una infra de lo más común cuando, por ejemplo, te piden que les montes un servidor VPN, pero que no toques absolutamente nada de la infra existente.

Insisto, todo lo que necesitas es decirle al router que maneje la tabla de rutas (sea el mikrotik o el otro), que a vuestra subred se llega por la IP del chisme que sea que levante la conexión. Si fuera el mikrotik, a su IP WAN.

Incluso cuando no tenéis acceso al mikrotik, podéis intentar replicarlo en un entorno virtual con una imagen CHR (router virtual) y, si os pasan la config que tiene montada (que se la pidan a la empresa proveedora, es tan sencillo como que accedan y hagan un export), podéis simular la implantación de lo vuestro de manera segura, y luego llegar y aplicar los cambios necesarios.

Pero lo más importante de ese setup es que identifiquéis quién es el gateway (sea un router, un server o cualquier otro elemento de red) que va a levantar el túnel, y enrutéis en el router de la operadora para decirle: tú no tienes ni papa de quien es esta subred, pero yo te digo que se llega por aquí.

Saludos!

Muchas gracias por tu tiempo! y por tu explicación, que por cierto, bastante buena.

Por otro lado y solo por aclarar, el mikrotik que tienen ellos lo tienen montado desde hace tiempo, lo usan para acceder a unos servidores externos de un proveedor de gestión de nóminas, y dentro de esos servidores tienen una impresora que la tienen en local pero que imprimen a través de los servidores externos. Básicamente la VPN hace falta para poder imprimir nóminas y ya jajajajaja.

Pedimos acceso al mikrotik o que nos pasaran como lo tenían y nos han ignorado mucho, era de esperar, porque básicamente los están sustituyendo por nosotros.
El problema no era no entender lo de las subredes y demás, ha sido más bien un pedo mental mezclado con varias situaciones puntuales que han hecho que interpretemos cosas de forma errónea.

Muchas gracias por tu tiempo!

Un saludo.

 

[pky]

Venga, perfecto. Me alegro de que hayáis dado con la tecla

Saludos!