Cada vez son más los clientes que nos piden ayuda en la transición al cloud y quieren tener conectividad entre los recursos alojados en la nube y en su CPD.
Algo que les facilita mucho dicha transición es reutilizar el conocimiento que ya tienen con cierto software o servicios que usan on-premise, por eso es habitual que nos pidan mantener el mismo firewall que ya tenían en activo.
En esta ocasión detallaremos la implementación de FortiGate como firewall de red para analizar todas las peticiones de entrada/salida a nuestros recursos hospedados en la nube.
A la hora de desplegar la máquina virtual con el firewall, vamos a hacer uso de la imagen predefinida de Fortinet, que está disponible en el Marketplace de AWS. Para poder usarla, primero debemos aceptar la suscripción.
Fuente: AWS
En el siguiente diagrama vemos la implementación que vamos a utilizar para conectar y forzar el paso de todas las peticiones a través de FortiGate:
Fuente: AWS
Mediante una implementación de red Hub and Spoke con la ayuda de AWS Transit Gateway nos abstraemos del número de VPCs y/o entornos que pueda tener el cliente, pues todos estarán conectados de la misma forma. Entonces es FortiGate, mediante el uso de reglas, quien posibilita o deniega la conectividad norte-sur y este-oeste.
Usamos GateWay Load Balancer, para distribuir las peticiones entre las diferentes instancias de FortiGate, o incluso, para centralizar todas las peticiones a una única instancia. Exponemos el GWLB con un VPC Endpoint.
Conectividad norte-sur
A continuación mostramos un esquema detallado con los distintos pasos que dará una petición para poder salir a internet:
- Paso 1: Una aplicación en la VPC de spoke-1 quiere comunicarse con un recurso en internet. La aplicación utiliza la ruta predeterminada (0.0.0.0/0) en la tabla de rutas de spoke-1 para enviar tráfico al Transit Gateway.
- Paso 2: Dado que la VPC de spoke-1 está asociada con la tabla de rutas de salida, el Transit Gateway utiliza la ruta predeterminada en esta última para enviar tráfico a la VPC de inspección.
- Paso 3: En la VPC de inspección, la subred A del Transit Gateway utiliza la ruta predeterminada en la tabla de rutas del Transit Gateway para enviar tráfico a GWLBE A (vpce-az-a-id) en la misma Zona de Disponibilidad (AZ).
- Paso 4: GWLBE A, utilizando AWS PrivateLink, enruta el tráfico a GWLB. El tráfico se enruta de manera segura a través de la red de Amazon sin ninguna configuración adicional.
- Paso 5: GWLB utiliza las 5 tuplas o las 3 tuplas de un paquete IP para seleccionar una aplicación durante toda la vida de ese flujo. Esto crea adherencia de sesión a una aplicación durante toda la vida de un flujo, lo cual es necesario para aplicaciones con estado como firewalls.
- Paso 6: GWLB encapsula el tráfico IP original con un encabezado GENEVE y lo reenvía a la aplicación a través del puerto UDP 6081. Esta encapsulación permite entregar todo el tráfico IP a las instancias de FortiGate para su inspección, sin especificar oyentes para cada puerto y protocolo.
- Paso 7: FortiGate, detrás del GWLB, desencapsula el encabezado GENEVE y toma una decisión para permitir el tráfico basándose en la política de seguridad configurada.
- Paso 8: FortiGate vuelve a encapsular el tráfico y lo reenvía al GWLB.
- Paso 9: GWLB, basado en la sesión de GENEVE, selecciona GWLBE A, elimina el encabezado GENEVE y reenvía el tráfico a GWLBE A.
- Paso 10: GWLBE A utiliza la ruta predeterminada en la tabla de rutas de Aplicación A y enruta el tráfico a NAT Gateway A (nat-az-a-id).
- Paso 11: NAT Gateway A utiliza la ruta predeterminada en la tabla de rutas de NAT Gateway A, realiza la traducción de la dirección IP de origen y enruta el tráfico a Internet Gateway (igw-id). Desde allí, el tráfico sale hacia Internet.
De igual forma mostramos cómo sería el proceso inverso en el que nos llega una petición retorno desde internet y ha de consumir alguno de nuestros servicios:
- Paso 1: Cuando el tráfico de retorno llega al Internet Gateway, ya que NAT Gateway A había traducido la dirección IP de origen, el Internet Gateway enruta el tráfico de vuelta a NAT Gateway A.
- Paso 2: NAT Gateway A utiliza la ruta de dirección de red de la VPC de spoke-1 en la Tabla de Rutas de NAT Gateway A y envía tráfico a GWLBE A.
- Paso 3: GWLBE A, utilizando AWS PrivateLink, enruta el tráfico a GWLB de manera segura a través de la red de Amazon.
- Paso 4: Dado que este paquete de retorno está asociado con un flujo existente, GWLB encapsula el tráfico IP original con un encabezado GENEVE y lo reenvía a la instancia de FortiGate que había elegido para este flujo.
- Paso 5: FortiGate detrás del GWLB desencapsula el encabezado GENEVE, inspecciona el tráfico y, dependiendo de la política de seguridad configurada, decide cómo manejar el tráfico. La adición de encabezados GENEVE no cuenta hacia el límite total de MTU de GWLB.
- Paso 6: Suponiendo que el tráfico está permitido, FortiGate vuelve a encapsular con encabezados GENEVE y reenvía el tráfico al GWLB.
- Paso 7: GWLB, basado en la sesión de GENEVE, selecciona GWLBE A, elimina el encabezado GENEVE y reenvía el tráfico a GWLBE A.
- Paso 8: GWLBE A utiliza la ruta de dirección de red de la VPC de spoke-1 en la Tabla de Rutas de Aplicación A y enruta el tráfico al Transit Gateway.
- Paso 9: Dado que la VPC de inspección está asociada con la tabla de rutas de tráficot, el Transit Gateway utiliza la ruta de dirección de red de la VPC de spoke-1 en la tabla de rutas para enviar tráfico a la VPC de spoke-1.
- Paso 10: Finalmente, una vez que el tráfico está en la VPC de spoke-1, el destino del paquete está dentro del rango CIDR de la VPC, donde se utiliza la ruta local para entregar el tráfico a la instancia de aplicación que generó el tráfico.
Conectividad este-oeste
- Paso 1: Una aplicación en la VPC de spoke-1 quiere comunicarse con una aplicación en la VPC de Spok2. La aplicación utiliza la ruta predeterminada (10.0.1.0/24) en la tabla de rutas de spoke-1 para enviar tráfico al Transit Gateway.
- Paso 2: Dado que la VPC de spoke-1 está asociada con la tabla de rutas de salida, el Transit Gateway utiliza la ruta predeterminada en esta última para enviar tráfico a la VPC de inspección.
- Paso 3: En la VPC de inspección, la subred A del Transit Gateway utiliza la ruta predeterminada en la tabla de rutas del Transit Gateway para enviar tráfico a GWLBE A (vpce-az-a-id) en la misma zona de disponibilidad (AZ).
- Paso 4: GWLBE A, utilizando AWS PrivateLink, enruta el tráfico a GWLB. El tráfico se enruta de manera segura a través de la red de Amazon sin ninguna configuración adicional.
- Paso 5: GWLB utiliza las 5 tuplas o las 3 tuplas de un paquete IP para seleccionar una aplicación durante toda la vida de ese flujo. Esto crea adherencia de sesión a una aplicación durante toda la vida de un flujo, lo cual es necesario para aplicaciones con estado como firewalls.
- Paso 6: GWLB encapsula el tráfico IP original con un encabezado GENEVE y lo reenvía a la aplicación a través del puerto UDP 6081. Esta encapsulación permite entregar todo el tráfico IP a las instancias de FortiGate para su inspección, sin especificar oyentes para cada puerto y protocolo.
- Paso 7: FortiGate detrás del GWLB desencapsula el encabezado GENEVE y toma una decisión para permitir el tráfico basándose en la política de seguridad configurada.
- Paso 8: FortiGate vuelve a encapsular el tráfico y lo reenvía al GWLB.
- Paso 9: GWLB, basado en la sesión de GENEVE, selecciona GWLBE A, elimina el encabezado GENEVE y reenvía el tráfico a GWLBE A.
- Paso 10: GWLBE A utiliza la ruta predeterminada en la tabla de rutas de Aplicación A y enruta el tráfico al Transit Gateway.
- Paso 11: El Transit Gateway utiliza la ruta predeterminada en la tabla de rutas de tráfico para enviar tráfico a la VPC de spoke-2.
- Paso 12: Finalmente, una vez que el tráfico está en la VPC de spoke-2, el destino del paquete está dentro del rango CIDR de la VPC, donde se utiliza la ruta local para entregar el tráfico a la instancia de aplicación de destino.
Esperamos que esta guía te haya sido útil para entender la implementación de FortiGate como firewall de red para analizar todas las peticiones de entrada/salida a nuestros recursos hospedados en la nube.
Si tienes alguna pregunta o necesitas más detalles, no dudes en contactar con nosotros o dejar un comentario.
