Zyxel Firewall [VPN Routing] - Enrutamiento del tráfico desde el túnel VPN a otro sitio VPN [VPN Routing].

Este artículo explica cómo enrutar el tráfico de un túnel de sitio a sitio en otro túnel para llegar a los dispositivos detrás de una conexión de sitio a sitio. Se explica cómo enrutar el tráfico desde el sitio A al sitio B a través de cortafuegos HQ / puerta de enlace (ruta de sitio a sitio a través de túnel de sitio a sitio), solucionar problemas / problemas, reglas de enrutamiento si desea que su cliente VPN para llegar a un servidor que se encuentra en otro sitio (cliente a sitio a través de sitio a sitio), SecuExtender IPSec configuración.

Alternativa 1: Enrutamiento del tráfico desde el túnel VPN remoto a otra VPN de sitio a sitio

1) Configuración de túneles VPN

Requisito previo: Ya debe estar establecida una conexión de sitio a sitio entre las ubicaciones.

Una vez establecido el túnel, lo conectaremos utilizando L2TP sobre IPSec.

Para obtener instrucciones sobre cómo configurar una VPN, consulte:

VPN - Configurar IPSec Site-To-Site VPN

Puede encontrar información sobre L2TP sobre IPSec:

VPN - Configurar VPN L2TP sobre IPSec usando PSK [Modo autónomo]

Para simplificar el proceso, puede utilizar el asistente para crear un túnel VPN y L2TP sobre IPSec.

2) Configuración de políticas de enrutamiento

Para permitir el tráfico entre la sede principal (HQ) y el Sitio B, es necesario configurar políticas y rutas para el túnel VPN.

En el cortafuegos de la sede central

1. Cree una ruta de política que dirija las solicitudes entrantes desde el túnel L2TP al túnel del Sitio B. Esto enruta las peticiones entrantes desde el túnel L2TP a través del cortafuegos de la sede central hacia el túnel del Sitio B.

   • Origen: Subred de cliente L2TP
   • Destino Subred del sitio B
   • Próximo salto: túnel VPN "túnel del Sitio B".

Nótese que la dirección de destino es la de nuestro cliente.

2. Cree una política que permita las respuestas del Sitio B y las enrute en el túnel hacia el Sitio B. Esto es crucial para el tráfico que regresa del Sitio B a la Sede Central.

• • Fuente: Cualquier
  • Destino: Túnel L2TP
  • Siguiente salto: Túnel VPN "Túnel L2TP"

En el sitio B:

1. Asimismo, cree una ruta de política que permita las solicitudes entrantes desde la sede central y las reenvíe al túnel hacia el sitio B:

Asegúrese de que el enrutamiento asimétrico está activado para una conectividad perfecta. Puede encontrar esta opción aquí:

Configuración > Política de seguridad > Control de políticas

Al habilitar esta función se activa la ruta "triangular", lo que permite al cortafuegos utilizar una topología de ruta asimétrica en la red y evita que se restablezca la conexión cuando vuelven las respuestas.

Si sigue estos pasos, podrá enrutar eficazmente el tráfico entre sus túneles VPN y mantener una conexión fluida y segura entre la sede central y el sitio B.

Alternativa 2: Enrutamiento desde un túnel VPN a otro sitio VPN

1) Enrutar el tráfico del Sitio A al Sitio B a través del Sitio HQ

Si desea que el sitio A llegue al sitio B y viceversa, debe crear rutas de política en cada cortafuegos para que el cortafuegos de la sede central sepa dónde enviar las solicitudes que llegan y dónde enviar también las respuestas.

1.1 Rutas de política - Cortafuegos HQ

En el cortafuegos de la sede central, primero debe configurar una regla que permita las solicitudes procedentes del Sitio A que se dirigen al Sitio B. Estas deben enrutarse en el túnel al Sitio B, y esto es importante tanto para las solicitudes ICMP (procedentes del Sitio A), como para las respuestas ICMP (procedentes del Sitio B y que ahora vuelven al Sitio B).

Entrante: cualquiera - Origen: "Subred del sitio A" -> Destino: "Site B subnet" - Next-hop Tunnel - "Site B VPN tunnel"

En segundo lugar, es necesario configurar una regla que permita respuestas procedentes del Sitio B que va al Sitio A (cuando se ha enviado una solicitud desde el Sitio A) y las necesidades de enrutamiento en el túnel del Sitio A. Esto es importante tanto para las peticiones ICMP (procedentes del Sitio B), como para las respuestas ICMP (procedentes del Sitio B y que ahora vuelven de nuevo al Sitio A).

Entrante: cualquiera - Origen: "Subred del sitio B" -> Destino: "Site A subnet" - Next-hop Tunnel - "Site A VPN tunnel"

1.2 Rutas de política - Firewall del sitio A

Entonces, necesita configurar una regla que permita peticiones que vienen del Sitio B que va al Sitio A (cuando ha enviado una petición desde el Sitio B). Estas necesitan ser enrutadas"de vuelta" al túnel del Sitio A, y esto es importante tanto para las peticiones ICMP (que vienen del Sitio B), como para las respuestas ICMP (que vienen del Sitio B y ahora van de vuelta al Sitio B de nuevo).

Entrante: any - Origen: "Subred del sitio B" -> Destino: "Subred del sitio A" - Siguiente salto "Túnel VPN del sitio A".

1.3 Rutas de política - Firewall del sitio B

Entonces, necesita configurar una regla que permita peticiones que vienen del Sitio A que va al Sitio B (cuando ha enviado una petición desde el Sitio A). Esto es importante tanto para las peticiones ICMP (que vienen del Sitio A), como para las respuestas ICMP (que vienen del Sitio A y ahora vuelven al Sitio A).

Entrante: any - Origen: "Subred del sitio A" -> Destino: "Subred del sitio B" - Siguiente salto "Túnel VPN del sitio B".

2) Verificación / Resolución de problemas

Cuando haya configurado todas las rutas de política, es importante verificar que el enrutamiento funciona realmente. Puede que haya rutas conflictivas en las reglas de su cortafuegos (solapamientos de subredes, rutas políticas/estáticas existentes, etc.) o que haya algún otro problema.

Tenga en cuenta que esto puede ser muy confuso ya que hay muchas rutas de las que debe ocuparse. La forma más fácil de hacerlo es trazar manualmente todos los flujos de paquetes en un papel (PC -> Pasarela A - la pasarela necesita enrutarse a la Sede Central, la Sede Central necesita enrutarse al Sitio B - el Sitio B necesita enrutar la respuesta de nuevo a la Sede Central ... etc.), pregúntese - "¿quién es responsable del enrutamiento, y está el enrutamiento en su lugar?".

Más abajo encontrarás dos escenarios en los que puede que necesites cambiar configuraciones para que el enrutamiento funcione.

2.1 Prueba haciendo ping al cortafuegos

La primera es una prueba haciendo ping desde un PC en el Sitio A a un servidor o PC en el Sitio B:

Flecha roja - Solicitud ICMP [ping]

Flecha verde - Respuesta ICMP [ping]

2.2mPolicy Routes - Firewall del Sitio A

Si está haciendo ping al Gateway del Sitio B desde el Gateway del Sitio A (herramienta ICMP incorporada), la política de enrutamiento en el Sitio A no se aplicará para las respuestas de vuelta desde el Sitio B, si el Sitio B está intentando hacer ping al Gateway del Sitio A.

Por lo tanto, necesitamos una ruta de política que se parezca a esto:

Entrante: ZyWall-Fuente: "Subred del sitio B" -> Destino: "Subred del sitio A" - Siguiente salto "Túnel VPN del sitio A".

2.3 Rutas de política - Firewall del sitio B

La primera prueba que puede hacer es hacer un ping al cortafuegos, sin embargo, debido a que el enrutamiento que ahora ha creado es SOLO para Incoming any (Excluyendo Zywall), significa que el enrutamiento no se aplicará si el ping viene del Sitio A, llega al Cortafuegos del Sitio B y entonces el Cortafuegos es responsable de responder a esa petición. La respuesta ICMP tendrá entonces este aspecto:

Petición ICMP

PC (Petición ICMP) -> Pasarela del Sitio A -> Túnel VPN a la Sede Central -> Pasarela de la Sede Central envía tráfico a la Pasarela del Sitio B

Respuesta ICMP

Pasarela del Sitio B (Respuesta ICMP) -> Pasarela del Sitio B -> Túnel VPN a la Sede Central -> Pasarela de la Sede Central envía tráfico a la Pasarela del Sitio A -> Pasarela del Sitio A envía paquetes de vuelta al PC

Por lo tanto, se necesita esta ruta de política:

Entrante: ZyWall-Fuente: "Subred del sitio A" -> Destino: "Subred del sitio B" - Siguiente salto "Túnel VPN del sitio B".

2.4 Prueba haciendo ping a un servidor / PC

Debido a que el PC se encuentra en la red 192.168.20.0/24, y el Servidor se encuentra en la red 192.168.30.0/24, el servidor no reconoce la red 192.168.20.0/24 y por lo tanto es muy probable que el servidor bloquee los paquetes ICMP procedentes de subredes desconocidas. Por lo tanto, al realizar pruebas, siempre:

• Desactive cualquier cortafuegos incorporado (por ejemplo, Windows Defender / Firewall)
• Desactive otros programas antivirus y de seguridad de punto final instalados en el servidor / PC.

Enrutar el tráfico de cliente a sitio a través de un túnel de sitio a sitio

Atención: Esto no funciona con Dynamic VPN. Seleccione sólo VPN Site2Site.

1) Configurar SecuExtender IPSec VPN

Para enrutar clientes VPN IPSec a otro túnel, es necesario que utilicen direcciones IP fijas.

Si es necesario enrutar muchos clientes diferentes, se recomienda utilizar IPs cercanas entre sí para poder crear un rango. Esto reduce el número de rutas necesarias.

La subred en la que se encuentran las direcciones IP no tiene que estar presente en el cortafuegos.

Introduzca la dirección IP fija en el Cliente VPN IPSec.

2) Configurar el enrutamiento del cortafuegos

En el cortafuegos, vaya a

Configuration > Object > Address

y haga clic en

Add

para crear el intervalo para las direcciones IP del cliente VPN IPSec.

Ahora podemos añadir las rutas necesarias en

Configuration > Network > Routing

haciendo clic en

2.1 En el sitio A Firewall

Necesitamos crear dos rutas:

• Una para el tráfico saliente, es decir, desde el túnel VPN-cliente dinámico a la subred remota a través del túnel de sitio a sitio.

• Uno para el tráfico entrante, es decir, desde la subred remota a través del túnel sitio a sitio hacia el túnel cliente VPN.

Las nuevas rutas deberían parecerse a esto:

Otra forma de que pase el tráfico entrante de la subred remota por el túnel VPN remoto, puedes habilitar "ruta asimétrica":

Esto habilitará la ruta "triangular" que hace que el cortafuegos permita el uso de topología de ruta asimétrica en la red y no reinicie la conexión cuando vuelva la respuesta.

2.2 Cortafuegos del Sitio B

En el sitio remoto, puede ser necesario tener rutas similares creadas para que el dispositivo en el sitio principal sepa cómo manejar el tráfico de los clientes VPN que vienen del sitio sucursal.

En la sede central, creamos el rango IP para los clientes VPN remotos de modo que podamos utilizarlo para enrutar el tráfico.

A continuación, creamos las rutas correspondientes también en la sede central.

Una ruta saliente, desde la subred de la sede central a través del túnel de sitio a sitio hacia los clientes VPN remotos.

Y una ruta entrante, desde el rango de clientes VPN remotos a través del túnel sitio a sitio hacia la LAN local de la sede central. Si el tráfico se enruta a una subred local, seleccionamos "Auto" como siguiente salto, el USG lo gestiona automáticamente.

Las rutas deberían tener este aspecto:

+++ Puedes comprar licencias para tus clientes Zyxel VPN (SSL VPN, IPsec) con entrega inmediata mediante 1-click: Zyxel Webstore +++