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

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

Hace unas semanas había publicado un artículo sobre un posible diseño/arquitectura de un firewall en vuestra red de Azure: Infraestructura en Microsoft Azure y Servicios de Office 365 [Parte II]: tips para tu firewall. Hoy voy a mostraros como podéis desplegar y configurar un firewall Fortinet en Azure, lo haré en varios artículos para que sea sencillo de seguir y de escribir. A continuación, os muestro como voy a dividir los artículos:

  • Parte I:
    • Instalación Firewall
    • Activación licencias
    • Configuración general del firewall
    • Creación de rutas estáticas en Azure
  • Parte II:
    • Configuración reglas entre vNets
    • Configuración reglas entre subredes [microsegmentación]
  • Parte III
    • Configuración VPN SSL con Split-Tunneling
    • Importación certificado
    • Autenticación Radius con MFA
    • Políticas de firewall para los clientes VPN
  • Parte IV
    • Configuración VPN SSL sin Split-Tunneling
    • Autenticación SSO con AzureAD para los clientes VPN
    • Políticas de firewall para los clientes VPN [filtrado web  y asignación de perfiles de av, ips, ssl-inspection, apps]
  • Parte V
    • Políticas de salida a internet de las diferentes vNets

Ahora que ya tenemos las partes de las que constará este artículo, os muestro la infografía desde la que vamos ir documentando todo el proceso:

Además, la instalación del firewall será sobre una estructura de vNets existente, lo que lo harás más interesante porque nos tendremos que ir adaptando en función de las configuraciones que tenemos que seguir manteniendo activas antes de cambiar el flujo del tráfico de red. En mi topología tengo varias vNets emparejadas entre si [con la red de Hub], además tienen una conexión VPN entre la red de Hub y la red On-Premises la cual tenemos que seguir manteniendo.

Aquí os dejo algunos artículos sobre el emparejamiento de vNet que había publicado en su momento, por lo menos para que este artículo sea más entendible:

El objetivo es introducir el firewall en la instalación actual, permitiendo filtrar las conexiones entre vNets, SubNets y toda la salida a internet desde cualquier equipo de nuestras redes. Además, si tenemos clientes VPN en nuestro firewall On-Premises pasar las conexiones al nuevo firewall, esto nos permitirá que los clientes VPN tengan menos latencia para acceder a los recursos locales de Azure.

Antes de nada, comentar que el Firewall lo conectaremos a la vNet de Hub, vamos a la vNet central donde tenemos los servicios compartidos (Adds, Dns, Waf, etc..) para el resto de vNets. Crearemos dos subredes en la vNet de Hub para situar la red interna y la red externa, más delante os comentaré la particularidad que esto tiene.

Pues dicho todo esto, vamos a crear una VM con nuestro Fortinet desde la siguiente plantilla desde el Marketplace de Azure:

Ahora vamos cubriendo todos los datos necesarios para ir creando la VM:

Si ya tenéis la licencia de Fortinet  ya se la podéis entregar desde aquí, sino lo haremos más adelante:

Esta es la parte más “importante” en la creación de nuestro firewall:

  • vNet: elegimos nuestra red de Hub
  • External subnet: elegimos la subnet que habremos creado previamente en nuestra vNet de Hub [solo tendremos conectado a esta subnet a la interface del Firewall], esta red será donde ubiquemos nuestra WAN en el Firewall.
  • Internal subnet: elegimos la subnet que habremos creado previamente en nuestra vNet de Hub [solo tendremos conectado a esta subnet a la interface del Firewall], esta red será donde ubiquemos nuestra LAN en el Firewall.
  • Protected subnet: la plantilla nos obliga a configurar una red protegida, la configuraremos pero luego la podemos eliminar. Básicamente es la red a proteger como cualquier otra subnet de las vNet que tenemos configuradas.

Elegimos una dirección IP Pública que tengamos disponible, sino es así, la tenemos que crear desde el propio asistente:

Si tenemos FortiManager lo podemos configurar, no es mi caso, así que no configuro nada.

Revisamos que tengamos todo correctamente preconfigurado, si es así, pulsamos en Crear y se iniciará la provisión de nuestro Fortigate: Una vez creado, pulsamos en Go to resource group para ver la IP Pública que tiene nuestro firewall y que podamos acceder a su configuración. 

Si podéis crear un registro DNS para acceder al Firewall, mejor que mejor, así siempre será más fácil el recordar su acceso, pero bueno, sino hemos registrado el firewall es lo primero que tendremos que hacer para poder registrarlo y posteriormente configurarlo. Esto lo haremos accediendo a la web de soporte de Fortinet: FortiGate Cloud. Una vez dentro, pulsamos en Register more y continuar con el proceso que será guiado por un asistente:

Una vez que hayamos registrado el firewall podemos descargarnos la licencia que tenemos que subir a nuestro firewall.

Una vez ya la el fichero de licencia, al iniciar por primera vez a la configuración del firewall podemos cargar su licencia:

Una vez cargada la licencia, nos pide obligatoriamente un reinicio y se lo damos claramente:

Esperamos a que termine de reiniciarse:

Antes de continuar con cualquier otra configuración siempre se recomendable actualizar a la versión más estable de nuestro firewall y así lo hacemos:

Una vez reiniciado y con las licencias correctamente cargadas podemos empezar a realizar las primeras configuraciones para ponerlo en marcha.   

Lo primero que haremos será nombrar nuestras interfaces de red del Firewall:

WAN para nuestra interface “externa”y establecemos su role a WAN:

LAN para la interface “interna” y establecemos su rol a LAN:

Esto nos permitirá identificarlas algo mejor:

Por defecto, el firewall tiene dos rutas estáticas:

  • 0.0.0.0/0 con salida por la interface WAN, su default gateway es la IP .1 de la subred que nos ofrece Azure para dicha subred
  • 172.17.0.0/16 es la subred donde está nuestra vNet de Hub, su default gateway es la IP .1 de la subred que nos ofrece Azure para dicha subred

Como sabemos, Microsoft envía por defecto todas las rutas a cada subnet de cada vNet, por lo que por cualquier subred vamos a ser capaces de llegar a las redes internas indistintamente por la red WAN o LAN, de ahí que le indiquemos al Firewall que tiene que llegar al resto de subredes de las diferentes vNets mediante la interface LAN:

Debemos añadir tantas subredes como queramos hacer pasar por el firewall, además, debemos incluir la 168.63.129.16/32 que es la red de Azure donde residen diferentes servicios a los cuales debemos tener acceso. Todas las subredes deben salir por la interface LAN, aunque os parezca algo absurdo es importante dejarlo bien configurado.

Por defecto, como en cualquier firewall tenemos una única regla por defecto bloqueando todo el tráfico que pase por el:

Lo que haremos será crear una primera regla muy sencilla para que todo el tráfico que pase por el firewall tenga acceso a Internet y comprobar que todo funciona correctamente:

Antes de nada os comento que, no hemos hecho nada de hardening del firewall [lo comentaré en otros artículos], únicamente me estoy centrando en hacerlo funcional en Azure. Con esta configuración, si algún equipo de nuestras vNets estuviese correctamente configurado ya podría tener internet mediante nuestro firewall. Para que esto ocurra tenemos que configurar diferentes rutas estáticas para invalidar las que por defecto tienen los equipos, las cuales podemos consultar desde el portal de Azure en la configuración de la tarjeta de red de cualquier VM. Una vez creada la tabla de rutas, añadiremos las que necesitamos:

Para este artículo voy a mostraros como crear una regla para todo el tráfico hacia Internet:

  • Nombre: to-Fortinet o to-Internet o to-Default
  • Destino: como queremos que todo el tráfico enviado a internet pase por el firewall escribimos 0.0.0.0/0
  • Próximo salto: dispositivo virtual
  • IP de próximo salto: la IP de la tarjeta del firewall de su red LAN

Ahora tenemos que asociarlo a la cualquier vNet de las que queramos realizar una primera prueba para dirigir el tráfico de Internet por mediante el firewall:

Ahora vamos a comprobar que rutas efectivas tiene alguna de las máquinas virtuales de las diferentes subnets, como vemos el único tráfico dirigido hacia el firewall es el  que va a Internet, el resto sigue por las mismas rutas por defecto que tiene Microsoft:

Si ahora queremos que otras subredes con las que nos queremos comunicar pasen por el firewall, tendremos que añadir las diferentes subredes a la tabla de enrutamiento:

Si ahora volvemos a ver la tabla de enrutamiento del mismo servidor, vemos que se ha actualizado la tabla de enrutamiento y añadiendo las nuestras e invalidando las de Microsft:

Nota: para que esta última configuración funcione, tenemos que configurar las rutas en todas las subnets implicadas, sino no tendremos tráfico de retorno

Si ahora queremos hacer microsegmentación, vamos que todo el tráfico entre las subnets de una misma vNet pase por el firewall y no de forma directa, tenemos que añadir las diferentes subnets a la tabla de enrutamiento. De esta forma, todo el tráfico entre equipos de la misma vNet pero diferente subnet pasará todo por el firewall.

Si tenéis como yo una conexión VPN Site-to-Site con On-Premises y seguí queriendo mantenerla por el Gateway de Azure, debéis dejar habilitado la propagación de rutas de gateway:

De esta forma, los equipos obtendrán las rutas que tendrán como destino nuestros sedes remotas mediante el gateway:

De esta forma, vamos “desviando” el tráfico de red a nuestro gusto  de forma progresiva. Ahora bien, esto solo son las rutas de red, ahora debemos configurar nuestro firewall para permitir el tráfico entre las diferentes subnets, para ello tenemos que configurar diferentes políticas de firewall con NAT deshabilitado y como origen y destino de interface siempre la red LAN:

Seguramente para muchos de vosotros (para mi al principio también) os resultará extraña la política en cuanto a que la interface de entrada y salida siempre es la LAN, pero es que realmente todo el tráfico pasar por la misma interface de red con diferentes orígenes y destinos en cuanto a subredes IP se refiere:

Las regla que os he mostrado es muy básica, simplemente quería mostrarla para que vierais como se tienen que hacer las reglas con esta tipología y firewall con dos interfaces de red. La idea es que son los siguientes artículo vayamos entrando en más detalles sobre la configuración de hardening del Firewall, Políticas, Perfiles de Seguridad, etc.. ahora es una simple introducción que espero que haya quedado más o menos clara.

En resumen:

  • Crear nuestro firewall
  • Registrar su licencia
  • Crear rutas estáticas en el firewall para todas las subnets que tengan que ser alcanzables por el firewall
  • Crear rutas estáticas en Azure para las diferentes subnets
  • Crear una política con NAT  para darle salida a Internet a las subnet que habilitemos a pasar por el firewall

Espero que os haya gustado, en próximos artículos iremos realizando diferentes configuraciones e iremos recordando conceptos de este artículo para que todos lo tengamos claro. He tratado de ser lo más breve posible, de ahí que no incida en los emparejamientos de vNets, creación de GatewayVPN, etc. todo esto lo tengo en otros artículos que podéis buscar en mi blog.

Nota: si algo me he dejado atrás, es posible que así sea, por favor, escribirlo en comentarios e os iré respondiendo.

Infraestructura 100%
Microsoft Azure: Ins
2 COMENTARIOS
  • Sergio Laguna / 5 abril, 2023

    Buenas tardes Santiago, a ver si me puedes echar una mano. Tengo montado un Forti sobre Azure conectado por IPSEC a varias sedes y con varios clientes SSL. Desde una maquina en la subred de Azure llego a todas las sedes sin problema (conecto por RDS, hago ping…) pero desde las otra sedes no conectan a la subred donde se encuentra esta maquina… salvo que active el NAT en las reglas de entrada. En el Forti tengo la ruta estática que me manda todo lo que entra por la LAN hacia esa subred.
    ¿Qué puedo tener mal configurado o que me puede faltar?
    Saludos, Sergio

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