Azure Firewall: Centralizar la salida a Internet de las vNet

Una de las principales funciones de un Firewall, bien sea físico o virtual, es la conexión y/o filtrado de la salida a Internet (entre otras “miles” de funciones), además, de ofrecer enrutamiento entre diferentes redes. Todos tenemos en nuestras redes corporativas  por lo menos un router y/o firewall para centralizar nuestra salida a Internet, permitiendo definir de forma centralizada diferentes reglas de seguridad.

Dicho esto, todos sabemos que cuando tenemos un servidor virtual en Azure, se le asigna automáticamente una dirección IP pública para SNAT, pero claro este escenario no permite de forma centralizada definir una serie de reglas de firewall (salientes y entrantes). Además, cada vez que apagamos  y encendemos el servidor, tendremos una dirección IP Pública diferente.

Si queremos tener una o varias vNets que tengan centralizada su salida a Internet, podemos lograrlo utilizando nuestro NVA y que en mi caso como os muestro en la siguiente infografía, seguimos utilizando el Azure Firewall:

Siguiendo con la topología anterior, lo que haremos será que todos los equipos de cada una de las vNet  de Spoke que tenemos emparejadas con la vNet de Hub, se conecten a Internet mediante el Firewall ubicado en la vNet de Hub.

Para completar este proceso, debemos realizar las siguientes tareas:

• Crear una regla de red en el Firewall para permitir la conexiones salientes de las diferentes subredes y protocolos que queramos permitir
• Actualizar la tabla de rutas

En el artículo anterior (Azure Firewall: Instalación y Configuración), únicamente permitíamos las conexiones entre vNets, aquí os dejo la regla de red que se había configurado:

Pero claro, ahora necesitamos que los equipos de cada vNet (172.17.0.0/16 y 172.18.0.0/16) se puedan conectar a cualquier destino, no sólo a la subred “vecina”. Pero, tampoco dejaremos que los equipos puedan conectarse a cualquier servicio, únicamente dejaremos los siguientes:

• DNS: sino permitimos la resolución DNS, tendremos Internet pero no tendremos resolución de nombre (entendemos que el tener Internet y resolución DNS son cosas diferentes aunque necesarias que se den a la vez)
• HTTP: conexiones a páginas web sin tráfico cifrado
• HTTPS: conexiones a páginas web con tráfico cifrado

Antes de iniciar las tareas de configuración, os voy a mostrar la dirección IP que tiene uno de los servidores de una vNet a la cual me he conectado vía RDP desde Internet utilizando la publicación mediante el Azure Firewall (está documentado en el artículo anteriormente citado). Como vemos, la dirección IP Pública a la que me conecto empieza por 52.x.x.x y luego la IP con la que estoy navegando desde dentro del servidor es una 40.85.x.x

Dicho esto, ahora si vamos a configurar nuestra regla de red que cumpla con el objetivo de que los equipos puedan Internet para únicamente los servicios comentados (DNS, HTTP y HTTPS) y de momento sólo para los equipos ubicados en la vNet con la subred 172.17.0.0/16:

Aquí es cuando ya empieza ser importante las prioridades de cada regla, puesto que las reglas se procesan por orden de menor a mayor prioridad, si tenemos una regla con mayor prioridad que otra siendo más o menos permisiva se ejecutará primero.

Una vez que ya hemos configurado las diferentes reglas de Firewall, ahora tenemos que añadir  en la tabla de rutas una regla para todo el tráfico de último salto se enrute hacia el Firewall. El proceso es muy sencillo, desde la sección de rutas en nuestra tabla de rutas pulsamos en Agregar:

La configuración es tal cual os muestro:

• Nombre: nombre para nuestra ruta
• Prefijo de dirección: esta es la parte importante, pero es sencillo, debemos poner 0.0.0.0/0 lo cual indica “cualquier destino”
• Tipo del próximo salto: elegimos el Dispositivo Virtual
• Dirección del próximo salto: aquí ponemos la dirección IP interna del Firewall

Una vez tengamos todos los datos cubiertos, pulsamos en Aceptar

Y ya tenemos que todo destino para el cual no se tenga una ruta se enviará al Firewall y él se encargará de enviarlo a Internet (SNAT)

Si ahora vemos las rutas eficaces del servidor desde el cual vamos a realizar nuevamente la prueba de conexión, vemos que tenemos dos rutas por defecto, pero en este caso al tener rutas personalizadas invalidan a las por defecto.

Por último, si ahora volvemos a conectarnos a Internet y vemos que dirección IP Pública estamos utilizando, podemos apreciar como ha cambiado y ahora es la misma que tiene el Firewall como IP Pública!!

Veis que el proceso es muy sencillo, en dos pasos lo tenemos configurado. Ahora que ya tenemos la conexión a Internet centralizada mediante nuestro Firewall, podemos empezar a definir reglas de seguridad saliente para permitir o denegar puertos, servicios y dominios que veremos en el siguiente artículo.

Espero que os sea de utilidad, ahora os toca probarlo a vosotros!!