Uno de los escenarios que nos estamos encontrado en algunos clientes es la necesidad de integrar Palo Alto VM-Series con Azure Application Gateway, de tal forma que este último sea el balanceador externo, que se comunica con Palo Alto y este con un balanceador interno que termina dirigiendo la petición al backend.
Palo Alto ha puesto a nuestra disposición una plantilla que te permite montar este entorno de manera sencilla, aunque hay parte de configuración que hacer por nuestra parte. Si bien es cierto que existe un archivo XML con la configuración que te voy a contar, yo no he tenido mucha suerte al intentar importarla en el portal de administración de los nodos de VM-Series como se indica aquí en el paso 3.2, por lo que en este post quiero explicarte cómo dejar este entorno funcionando con todas las piezas mencionadas anteriormente, según la configuración ofrecida en dicho XML (que he mapeado tranquilamente a mano en cada uno de los apartados de la administración :))
Desplegar plantilla de Palo Alto
El primer paso para montar este entorno es desplegar la plantilla que proporciona Palo Alto. Esta puedes encontrarla en su GitHub: https://github.com/PaloAltoNetworks/azure-applicationgateway. En la parte inferior del repositorio tienes un botón que te permitirá hacer el despliegue a Azure de manera sencilla. Para este post dejaremos todos los parámetros que aparecen por defecto con el fin de simplificar el escenario lo más posible y que puedas entender su funcionamiento, para poder personalizarlo luego a tu gusto. Lo único que debes elegir es el nombre del grupo de recursos, el DNS name de Application Gateway (parece ser que este valor luego no se aplica bien, pero es obligatorio), el DNS utilizado para acceder a la configuración de Palo Alto, el nombre para una cuenta de almacenamiento, un nombre de usuario y su contraseña para poder acceder luego al portal de administración.
Una vez desplegado, el resultado a nivel de red será el siguiente:
Como ves, la plantilla ha desplegado 4 máquinas virtuales: 2 que se corresponden con las VM-Series (VM-Series0 y VM-Series1) que tienen 3 NICs asociadas y están alocadas en diferentes subnets (Mgmt, Untrust y Trust) y 2 frontales web Linux (web-e43b-0 y web-e43b-1) que están en la subnet backendSubnet. Por otro lado, tenemos el Application Gateway (myAppGw) en la subnet AppGWSubnet, que ya te conté en un artículo anterior que debe estar en su propia subnet, y un Azure Load Balancer en la subnet Trust.
Ahora bien, si intentas acceder al backend, simplemente con la plantilla desplegada, podrás comprobar que no es posible, devolviendo un 502.
De hecho, existe un apartado en Azure Application Gateway que te permite conocer el estado de tus backend pools llamado Backend Health:
Esto significa que Application Gateway no es capaz de acceder, en este caso, a través del puerto 80 a los nodos de Palo Alto, ya que necesitamos configurar los mismos para que esto sea posible.
Acceder al portal de administración de Palo Alto VM-Series
Para poder configurar el firewall, lo primero que debemos hacer es acceder al portal de administración. Una de las NICs que tienen configuradas las máquinas de Palo Alto, en concreto la eth0 que están en la subnet Mgmt, tanto en eth0-VM-Series0 como eth0-VM-Series1, tienen asociadas un DNS para que sea más sencillo el acceso. Haz clic en el apartado Public IP address:
Esto te llevará a otro blade donde podrás copiar el DNS asociado:
Y accede al portal de administración utilizando https + el DNS anterior.
Acepta el acceso inseguro a través del enlace inferior y aparecerá la pantalla de Login de Palo Alto Networks:
Utiliza las credenciales que configuraste durante el despliegue de la plantilla y ya estarás dentro del portal de administración.
Para esta prueba de concepto debemos configurar tres apartados:
- Network
- Asociar las interfaces a las IPs correspondientes
- Dar de alta dos zonas (trust y untrust)
- Configurar el virtual router con una ruta estática
- Objects
- Dar de alta dos addresses:
- firewall-untrust-IP
- internal-load-balancer-IP
- Dar de alta dos addresses:
- Policies
- Security
- política para permitir el acceso por HTTP
- política para denegar todo lo demás
- NAT
- Politica que redirija al balanceador interno
- Security
¡Empecemos!
Network
Lo primero que necesitamos configurar son una serie de valores que utilizaremos posteriormente en el resto de apartados. En la pestaña Network lo primero que debemos configurar son las interfaces.
Selecciona la primera de ellas, ethernet1/1, y modifica el combo de Virtual Router a default.
En la pestaña IPv4 selecciona la opción DHCP Client y deshabilita «Automatically create default route pointing to default gateway provided by server».
Hacemos exactamente lo mismo con la segunda interface (ethernet1/2).
Una vez finalizada la configuración de ambas interfaces el resultado será el siguiente:
El siguiente apartado a configurar son las zonas. Accede al apartado Zones y haz clic en el botón Add de la parte inferior.
La primera zona que vamos a crear tiene como nombre trust de tipo Layer 3 y tiene como interfaz la ethernet1/2.
La segunda zona será la llamada untrust, también con tipo Layer 3, y tendrá la interfaz ethernet1/1.
El resultado de la configuración debería de ser el siguiente:
Para finalizar con el apartado Network, lo último que tienes que modificar es la sección Virtual Routers. Selecciona el llamado default para entrar en su configuración.
Y en el apartado Static Routes debes añadir la siguiente ruta para la comunicación con Application Gateway:
Haz clic en Ok y Ok para guardar los cambios.
Objects
En esta pestaña sólo es necesario dar de alta un par de direcciones IP en la sección Addresses. Haz clic en el botón Add de la parte inferior para añadirlas. La primera de ellas, firewall-untrust-IP con IP 192.168.1.4, se corresponde con la NIC de la eth1-VM-Series0 en la subnet Untrust. La segunda que debes configurar es internal-load-balancer-IP con IP 192.168.2.6 que se corresponde con el balanceador interno de Azure.
La configuración debería de quedar de esta manera:
Policies
En policies es donde realmente está la magia que necesitamos para obtener la conectividad desde Application Gateway, pero hemos necesitamos el resto de pasos previos para estar preparados para este momento 😉
En el apartado Security debemos dar de alta dos políticas. La primera de ellas la llamaremos allow_http.
Todos los apartamos que aparecen con una linea subrayando en rojo es porque requieren de configuración obligatoria. En Source simplemente marcaremos Any y Any y en el apartado Destination selecciona en el combo any. Por último en Service/URL Category añade service-http.
En el apartado Actions no es necesario configurar nada ya que por defecto cuando creas una nueva regla el valor por defecto es Allow.
Es necesario crear una segunda regla llamada deny_all con todos los valores anteriores (any) excepto por la sección Service/URL Category que la dejamos tal cuál se crea y en el apartado Actions modificamos la acción a Deny.
La configuración de este apartado quedaría de la siguiente forma:
El último paso es configurar la sección NAT donde debes crear una regla que permita el paso al balanceador interno. En este entorno la he llamado ilb al igual que figura en el archivo de configuración de ejemplo.
En la pestaña Original Packet, en el lado izquierdo debe estar marcado Any, en Destination Zone selecciona untrust y en Destination Address añade firewall-untrust-IP.
Por último, en la pestaña Translated Packet configura los valores de la siguiente forma:
La configuración de la sección NAT debería de ser igual que la siguiente:
Ya tienes toda la configuración necesaria para el entorno. El paso final es hacer commit de todos los cambios que hemos realizado. Para ello haz clic en el botón Commit que se encuentra en la parte superior derecha y, si todo se ha configurado correctamente, deberías obtener este mensaje:
Si intentas acceder ahora a través del DNS de Application Gateway verás la página por defecto de Apache2 de Ubuntu. ¡Hemos llegado al backend a través de Application Gateway, pasando por Palo Alto y un balanceador interno de Azure!
Sin embargo, con esto no hemos acabado ya que si vuelves a la sección Backend health de nuevo vemos que uno de los nodos de VM-Series no está respondiendo correctamente.
Funciona porque al menos uno de los nodos del backend pool está funcionando pero es necesario replicar toda la configuración comentada aquí en el otro nodo. El único cambio en la configuración que debes realizar para el nodo VMSeries1 sería en el apartado Objects > Addresses donde la IP de firewall-untrust-IP debería ser 192.168.1.5 que es la que se corresponde con este nodo.
Con este único cambio y siguiendo todos los pasos de la configuración que has seguido para la VM-Series0 quedarían los dos nodos perfectamente configurados:
Además puedes ver que ambos nodos están recibiendo llamadas en el apartado Hit Count de la regla ilb del NAT:
Más información: Start Using the VM-Series & Azure Application Gateway Template
¡Saludos!