Cerrar
InicioAzureMicrosoft Azure: Instalación y Configuración de un Firewall Fortinet (Parte II)

Microsoft Azure: Instalación y Configuración de un Firewall Fortinet (Parte II)

Continuando con la implementación de un firewall Fortinet en Azure, hoy vamos a ver que cositas tenemos que tener en cuenta al manejo del tráfico de red entre vNets y Subnets. En el primero artículo [Microsoft Azure: Instalación y Configuración de un Firewall Fortinet (Parte I)] habíamos visto como desplegar el firewall y las configuraciones esenciales para ofrecer salida a internet mediante el firewall a nuestros equipos en Azure.

El objetivo a conseguir en este artículo es el conseguir manejar todo el tráfico de red, filtrarlo e inspeccionarlo con nuestro Firewall. Además, entender el papel fundamental que juegan las UDR (User-Defined Route) en el enrutamiento del tráfico en nuestras redes de Azure.

Aquí os dejo la topología que vamos a desplegar en este artículo:

Como se aprecia, tenemos tres vNets y queremos conseguir los siguientes objetivos:

  • vNet [172.15.0.0/16]
    1. Que tenga acceso a Internet mediante al Firewall
    2. Permitir la conexión a los puertos de los servicios publicados en cada VM de cada subred
    3. Bloquear la conexión entre las diferentes subnets con excepciones
  • vNet [172.16.0.0/16]
    1. Que tenga acceso a Internet mediante al Firewall
    2. Permitir la conexión a los puertos de los servicios publicados en cada VM de cada subred
  • vNet [172.17.0.0/24]
    1. Que tenga acceso a Internet mediante al Firewall
    2. Permitir los inicios de sesión de los equipos en el ADDS cuyos controladores de dominio están en la subnet 172.16.1.0/24

Además, todas las vNet deben poder ser accesibles desde las seden conectadas por VPN pero pasando por el Gateway de Microsoft. Esto lo comento así para que podáis ver como excluir ciertos tráficos de red del firewall y enviarlo directamente por el Gateway, pero claramente suyo es por pasar todo el tráfico por el Firewall para analizar/filtrar dicho tráfico.

Para lograr el objetivo común de que todas las vNet accedan a Internet mediante el Firewall tenemos que crear una tabla de rutas con la siguiente ruta, luego esta tabla de rutas la asociamos a las diferentes subred de cada vNet que queramos.

Ahora debemos configurar una regla en el firewall para permitir la conexión hacia Internet de las diferentes subredes, para ello hacemos algo parecido a esto:

Si editamos la regla que tenemos seleccionada en amarillo, vemos su definición:

  • Incoming interface: nuestra interface LAN
  • Outgoing interface: nuestra interface WAN
  • Source: añadimos los objetos que definen nuestras vNets o subnets (debemos crearlo antes)
  • Nat: habilitado
  • Perfiles de seguridad: aquí habilitamos todos los servicios que queramos

Con esto, ya tenemos salida a Internet de todas las subnets que hemos configurado con la tabla de rutas anteriormente creada.

Ahora vamos a configurar otro escenario, el poder gestionar el tráfico entre diferentes vNets pasando por el Firewall, como siempre primero añadimos las siguientes subnets en la tabla de rutas. Añadimos las subnets remotas a las que queremos llega desde las subnets a las que asignemos esta tabla de rutas:

  • Destino: 172.18.x.x/2x
  • Próximo salto: Virtual Appliance (nuestro Firewall)
  • IP Próximo salto: la IP interna de nuestro firewall

Antes de continuar, tenemos que crear otra tabla de rutas para asociarla a las subnets de destinos para que tener el tráfico de retorno también por el firewall. Para ello, tenemos la siguiente tabla de rutas:

  •  0.0.0.0/0  para todo el tráfico dirigido a Internet que salga por el Firewall
  • 172.18.3.0.0/24 esta ruta es para que el tráfico entre subnets de la misma vNet pasen por el firewall y así poder filtrado, esto se conocerá como microsegmentación
  • 172.17.0.0/16 esta red es la red de Hub a la que queremos enviarle el tráfico de retorno mediante el firewall

Y ahora, debemos configurar las reglas en el firewall para permitir el tráfico que deseemos. Yo os voy a mostrar dos reglas:

  • La que permite el tráfico necesario para iniciar sesión en el dominio en los equipos de Azure Virtual Desktop
  • Permitir acceso a un servidor de ficheros que está en otra vNet

Las reglas que están en amarillo son las que se corresponden con los dos puntos comentados:

Aqui viene lo importante en este escenario del Firewall, que tanto la interface de entrada y salida siempre es la LAN. Pensad que todo el tráfico le viene por la misma interface, entonces debemos configurar la interface LAN como interface “para todo”. Luego, otra cosa importante es que no haremos NAT, porque “básicamente” haremos de enrutador entre las diferentes vNets (source en el firewall). El resto es sencillo, debemos configurar las reglas lo más explícitas posibles y definirlas por origen, destino, puerto y perfiles de seguridad.

Esta regla es la que permite acceder a los controladores de dominio desde la red donde tenemos los host de nuestro Azure Virtual Desktop para que puedan iniciar sesión en el dominio:

Y aquí tenemos otra regla donde permitimos el acceso a un servidor de ficheros de otra vNet:

Recordad que la máxima de cualquier firewall es tener una regla por defecto que bloquea todo el tráfico, por lo que, todo el tráfico que queráis permitir lo tenéis que definir en las reglas del firewall.

Como podéis apreciar, tenemos que jugar con las rutas para permitir el tráfico hacia Internet, su propia vNet y otras vNet que tengamos en Azure. De esta forma, podemos aplicar reglas por subnet, puertos y servicios los cuales tenemos que definir en nuestro firewall para que todo sea más cómodo de gestionar. Además, importante,  las reglas que definen el tráfico que vamos a permitir entre las vNets y sus subnets, no tenemos que habilitar NAT.

Ha sido un artículo cortito, pero es pero que haya sido más o menos claro para que podáis entender los puntos claves de la configuración de nuestro firewall en Azure.

Microsoft Azure: Ins
Microsoft Intune: In
NO HAY COMENTARIOS

DEJA UN COMENTARIO

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies
Share This