Skip to content

Referencia de Configuración del NGFW — TLSStress.Art Modo DUT

Para quién es este documento: el ingeniero de redes responsable de configurar el firewall que se está probando (el Device Under Test — DUT). Este documento contiene cada VLAN, dirección IP, ruta y política TLS que el NGFW debe tener configurados antes de que el test-bed pueda generar tráfico.

Autor: André Luiz Gallon — agallon@Cisco.com | Versión: v3.6.0

Estado del alcance (post-congelación de alcance 2026-05-10) — Ver ARCHITECTURE.md para los 37 MÓDULOs canónicos + 7 Test Kinds + arquitectura de safety DOM/CPOS/PIE-PA. ADRs 0014, 0019-0025 cubren adiciones post-Freeze.

Índice

  1. Cómo Funciona el Test-Bed
  2. Conectividad Física
  3. Referencia Completa de VLANs e IPs
  4. Configuración de Interfaces del NGFW
  5. Tabla de Ruteo
  6. PKI — Las Dos CAs
  7. Política de Inspección TLS
  8. Ejemplos de Configuración por Fabricante
  9. Cisco FTD (FMC)
  10. Cisco FTD (FDM)
  11. Cisco ASA
  12. FortiGate
  13. Palo Alto PAN-OS
  14. Check Point
  15. Verificación
  16. Solución de Problemas

1. Cómo Funciona el Test-Bed

El TLSStress.Art posiciona el NGFW en el centro de todo el tráfico HTTPS entre usuarios simulados (agentes) y sitios web simulados (personas). El NGFW debe realizar inspección TLS en cada conexión — esto es exactamente lo que se está midiendo.

┌─────────────────────────────────────────────────────────────────┐
│              TLSStress.Art (Ubuntu + k3s)                   │
│                                                                 │
│  Agentes browser-engine (VLAN 20 — 172.16.x.x)                     │
│  Agentes synthetic-load         (VLAN 30 — 172.17.x.x)                     │
└───────────────────────────┬─────────────────────────────────────┘
                            │  TLS Leg 1
                            │  Agentes → NGFW
                            │  NGFW presenta su propio cert firmado por su CA
                            │  Agentes confían en ngfw-ca (instalada en el cluster)
                            ▼
              ┌─────────────────────────┐
              │   NGFW (Device Under    │  ◄── Esto es lo que se está probando
              │        Test)            │
              │                         │
              │  Motor de Inspección    │
              │  TLS                    │
              │  Descifrar → Inspeccionar│
              │  → Re-cifrar            │
              └─────────────┬───────────┘
                            │  TLS Leg 2
                            │  NGFW → Webservers de las personas
                            │  Certs de personas firmados por persona-ca
                            │  NGFW confía en persona-ca (instalada en NGFW)
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│           20 Webservers de Personas (Caddy + Kubernetes)        │
│                                                                 │
│  shop        VLAN 101 — 10.1.1.0/27                            │
│  news        VLAN 102 — 10.1.2.0/27                            │
│  ...         ...                                               │
│  har-media   VLAN 120 — 10.1.20.0/27                           │
└─────────────────────────────────────────────────────────────────┘

Dos legs TLS — dos relaciones de confianza de certificados distintas:

Leg Dirección Quién presenta el cert Quién debe confiar Cómo
Leg 1 Agente → NGFW NGFW (cert de forward-proxy) Agentes (browser-engine + synthetic-load) ngfw-ca.crt instalado en el cluster Kubernetes
Leg 2 NGFW → Webservers de personas Webserver de la persona (Caddy) NGFW persona-ca.pem instalado en el trust store del NGFW

2. Conectividad Física

Cableado

Servidor Ubuntu (test-bed)
  eth1 (trunk 802.1q) ──────────► Puerto trunk del Nexus 9000
                                        │
                                   Trunk VLAN
                                   (todas las VLANs)
                                        │
                               ┌────────┴────────┐
                               │   Nexus 9000    │
                               └────────┬────────┘
                                        │
                             ┌──────────┴──────────┐
                             │   Puerto(s) access  │
                             │   hacia interfaces  │
                             │   de datos del NGFW │
                             └──────────┬──────────┘
                                        │
                                   ┌────┴────┐
                                   │  NGFW   │
                                   │  (DUT)  │
                                   └─────────┘

Requisitos del Nexus 9000

El Nexus 9000 debe configurarse con las siguientes VLANs y trunk:

vlan 20,30,99,101-120,200-209

interface <trunk-hacia-ubuntu>
  switchport mode trunk
  switchport trunk allowed vlan 20,30,99,101-120,200-209

interface <hacia-inside-ngfw>           ! puerto NGFW lado agentes
  switchport mode trunk
  switchport trunk allowed vlan 20,30

interface <hacia-outside-ngfw>          ! puerto NGFW lado webservers (Personas Sintéticas + Clonadas)
  switchport mode trunk
  switchport trunk allowed vlan 101-120,200-209

interface <hacia-mgmt-ngfw>             ! puerto de gestión del NGFW (opcional)
  switchport mode access
  switchport access vlan 99

Nota sobre VLAN 10 (eliminada en v3.7.0): la antigua capa de webserver Caddy único del modo Docker, que vivía en la VLAN 10 / 10.20.30.0/24, fue eliminada. Kubernetes es la única fuente de verdad para webservers DUT — 20 Personas Sintéticas en VLANs 101–120 + 10 slots de Personas Clonadas en VLANs 200–209.

3. Referencia Completa de VLANs e IPs

3.0 Mapeo de Zonas de Seguridad del NGFW (v4.3, fijado 2026-05-09)

El NGFW tiene 8 interfaces (o sub-interfaces en un trunk) distribuidas en 3 zonas:

Zona VLANs Qué transporta
TRUST / INSIDE 20, 30, 2900 LANs corporativas de agentes (browser-engine + synthetic-load) + agente de stress de plano de control (MAC + ARP/NDP)
UNTRUST / OUTSIDE 1982, 2001, 2809, 4338 Endpoints de enrutamiento/peer VyOS (OSPF, ISP/edge, BGP, MÓDULO SDWAN/CoR-N.Art modo local — término legado "VPN-REMOTE")
MGMT 99 Administración — SNMP only

VLANs que NO terminan en el NGFW:

VLAN Razón
40 (cloner-isp) Cloner egresa directamente a Internet pública — bypassa el NGFW
101–120 (Personas Sintéticas) Las personas viven DETRÁS del pod VyOS-ISP (un /24 por país por VLAN); el NGFW solo ve el enlace edge (VLAN 2001) — VyOS-ISP enruta desde ahí hacia cada país
200–209 (Personas Clonadas) En deprecación — las clonadas migran a los /24s de país junto con las Sintéticas

⚠️ Las secciones 3.3 y 4.2 a continuación describen la topología LEGACY v3.x donde las personas terminaban en sub-interfaces del NGFW (una por VLAN 101–120, con gateway NGFW 10.1.x.1). En v4.3, las personas viven detrás del VyOS-ISP y el NGFW solo tiene la única interfaz outside VLAN 2001 para todo el tráfico de personas. Ver docs/ARCHITECTURE.md "DUT network segments" para la topología corregida. Migración rastreada por separado (Personas v4.3 IP migration option B).

3.1 VLANs de los Agentes (Inside — hacia el NGFW)

Estas son las subredes donde viven los agentes de prueba. El NGFW es el gateway predeterminado de los agentes.

VLAN Propósito Subred IP de Interfaz NGFW Rango de IPs de agentes Protocolo
20 Agentes browser engine (navegador real) 172.16.0.0/16 172.16.0.1 172.16.1.0 – 172.16.255.254 HTTPS (TCP 443)
30 Agentes synthetic-load engine (carga HTTP) 172.17.0.0/16 172.17.0.1 172.17.1.0 – 172.17.255.254 HTTPS (TCP 443)

Los agentes browser engine generan HTTPS con comportamiento real de navegador, con handshake TLS completo y ejecución de JavaScript. Los agentes synthetic-load engine generan carga HTTP/2 y HTTP/3 a gran escala.

3.2 VLAN de Gestión

VLAN Propósito Subred IP del Nexus 9000 IP de gestión del NGFW Rango del pod SNMP
99 Monitoreo SNMP 192.168.90.0/24 192.168.90.2 192.168.90.3 192.168.90.10 – .49

El pod SNMP Exporter recolecta contadores de CPU, memoria e interfaces tanto del Nexus 9000 como del NGFW para correlacionar la carga de tráfico con el rendimiento del hardware.

3.3 VLANs de las Personas (Outside — hacia los webservers Caddy)

Cada persona corre en su propio namespace de Kubernetes con una VLAN dedicada, subred /27, certificado TLS y nombre DNS. El NGFW es el gateway para conexiones entrantes del lado de los agentes.

VLAN Persona Subred IP de Interfaz NGFW IP(s) del Webserver Nombre DNS Tipo de sitio
101 shop 10.1.1.0/27 10.1.1.1 10.1.1.2 shop.persona.internal E-Commerce (Saleor)
102 news 10.1.2.0/27 10.1.2.1 10.1.2.2 news.persona.internal Portal de Noticias
103 blog 10.1.3.0/27 10.1.3.1 10.1.3.2 blog.persona.internal Blog
104 docs 10.1.4.0/27 10.1.4.1 10.1.4.2 docs.persona.internal Documentación Técnica
105 gallery 10.1.5.0/27 10.1.5.1 10.1.5.2 gallery.persona.internal Galería de Imágenes
106 stream 10.1.6.0/27 10.1.6.1 10.1.6.2 stream.persona.internal Streaming de Vídeo HLS
107 download 10.1.7.0/27 10.1.7.1 10.1.7.2 download.persona.internal Alojamiento de Archivos
108 edu 10.1.8.0/27 10.1.8.1 10.1.8.2 edu.persona.internal Plataforma de Aprendizaje
109 gov 10.1.9.0/27 10.1.9.1 10.1.9.2 gov.persona.internal Portal Gubernamental
110 cdn 10.1.10.0/27 10.1.10.1 10.1.10.2 cdn.persona.internal CDN de Assets
111 api-rest 10.1.11.0/27 10.1.11.1 10.1.11.2 api-rest.persona.internal API REST
112 api-graphql 10.1.12.0/27 10.1.12.1 10.1.12.2 api-graphql.persona.internal API GraphQL
113 chat 10.1.13.0/27 10.1.13.1 10.1.13.2 chat.persona.internal Chat / Mensajería
114 webhook 10.1.14.0/27 10.1.14.1 10.1.14.2 webhook.persona.internal Webhooks
115 telemetry 10.1.15.0/27 10.1.15.1 10.1.15.2 telemetry.persona.internal Analytics / Telemetría
116 ads 10.1.16.0/27 10.1.16.1 10.1.16.2 ads.persona.internal Red de Publicidad
117 har-saas 10.1.17.0/27 10.1.17.1 10.1.17.2 har-saas.persona.internal SaaS Corporativo (replay HAR)
118 har-social 10.1.18.0/27 10.1.18.1 10.1.18.2 har-social.persona.internal Red Social (replay HAR)
119 har-webmail 10.1.19.0/27 10.1.19.1 10.1.19.2 har-webmail.persona.internal Webmail (replay HAR)
120 har-media 10.1.20.0/27 10.1.20.1 10.1.20.2 har-media.persona.internal Streaming de Medios (replay HAR)

IPs de los webservers: cada pod de persona recibe la primera IP disponible en su rango (.2). Si hay más de una réplica, se asignan IPs adicionales (.3, .4 …). El certificado TLS cubre todo el rango .2–.30. El NGFW se conecta directamente a la IP del webserver (validación por IP SAN).

3.4 Resumen — todas las subredes

VLAN Subred Función IP de interfaz NGFW
20 172.16.0.0/16 Agentes browser engine 172.16.0.1
30 172.17.0.0/16 Agentes synthetic-load engine 172.17.0.1
99 192.168.90.0/24 Gestión SNMP 192.168.90.3
101 10.1.1.0/27 shop 10.1.1.1
102 10.1.2.0/27 news 10.1.2.1
103 10.1.3.0/27 blog 10.1.3.1
104 10.1.4.0/27 docs 10.1.4.1
105 10.1.5.0/27 gallery 10.1.5.1
106 10.1.6.0/27 stream 10.1.6.1
107 10.1.7.0/27 download 10.1.7.1
108 10.1.8.0/27 edu 10.1.8.1
109 10.1.9.0/27 gov 10.1.9.1
110 10.1.10.0/27 cdn 10.1.10.1
111 10.1.11.0/27 api-rest 10.1.11.1
112 10.1.12.0/27 api-graphql 10.1.12.1
113 10.1.13.0/27 chat 10.1.13.1
114 10.1.14.0/27 webhook 10.1.14.1
115 10.1.15.0/27 telemetry 10.1.15.1
116 10.1.16.0/27 ads 10.1.16.1
117 10.1.17.0/27 har-saas 10.1.17.1
118 10.1.18.0/27 har-social 10.1.18.1
119 10.1.19.0/27 har-webmail 10.1.19.1
120 10.1.20.0/27 har-media 10.1.20.1

4. Configuración de Interfaces del NGFW

4.1 Interfaces necesarias

El NGFW debe tener al menos dos interfaces físicas (o una trunk):

Interfaz Conectada a Transporta VLANs Dirección
Inside (lado de los agentes) Nexus 9000 20, 30 Agentes → NGFW
Outside (lado de los servidores) Nexus 9000 101–120 NGFW → Webservers de personas
Management (opcional) Nexus 9000 99 Solo monitoreo SNMP

4.2 IPs de subinterfaces a configurar

Para cada VLAN, el NGFW necesita una subinterfaz con la IP de gateway indicada en la sección 3. Ejemplo para una interfaz inside con soporte de trunk:

# Interfaz inside — hacia los agentes
VLAN 20  → IP 172.16.0.1/16   (gateway de agentes browser-engine)
VLAN 30  → IP 172.17.0.1/16   (gateway de agentes synthetic-load)

# Interfaz outside — hacia los webservers
VLAN 101 → IP 10.1.1.1/27    (gateway de shop)
VLAN 102 → IP 10.1.2.1/27    (gateway de news)
VLAN 103 → IP 10.1.3.1/27    (gateway de blog)
VLAN 104 → IP 10.1.4.1/27    (gateway de docs)
VLAN 105 → IP 10.1.5.1/27    (gateway de gallery)
VLAN 106 → IP 10.1.6.1/27    (gateway de stream)
VLAN 107 → IP 10.1.7.1/27    (gateway de download)
VLAN 108 → IP 10.1.8.1/27    (gateway de edu)
VLAN 109 → IP 10.1.9.1/27    (gateway de gov)
VLAN 110 → IP 10.1.10.1/27   (gateway de cdn)
VLAN 111 → IP 10.1.11.1/27   (gateway de api-rest)
VLAN 112 → IP 10.1.12.1/27   (gateway de api-graphql)
VLAN 113 → IP 10.1.13.1/27   (gateway de chat)
VLAN 114 → IP 10.1.14.1/27   (gateway de webhook)
VLAN 115 → IP 10.1.15.1/27   (gateway de telemetry)
VLAN 116 → IP 10.1.16.1/27   (gateway de ads)
VLAN 117 → IP 10.1.17.1/27   (gateway de har-saas)
VLAN 118 → IP 10.1.18.1/27   (gateway de har-social)
VLAN 119 → IP 10.1.19.1/27   (gateway de har-webmail)
VLAN 120 → IP 10.1.20.1/27   (gateway de har-media)

# Interfaz de gestión
VLAN 99  → IP 192.168.90.3/24 (monitoreo SNMP)

4.3 Zonas de seguridad

Cree dos zonas de seguridad en el NGFW:

Nombre de zona Interfaces Nivel de confianza
agents VLAN 20, VLAN 30 Menor (clientes — origen de tráfico no confiable)
personas VLANs 101–120 Mayor (servidores — tráfico a inspeccionar)

5. Tabla de Ruteo

El NGFW debe poder enrutar tráfico entre las subredes de agentes y personas. Como es el gateway de todas las subredes, las rutas conectadas cubren el reenvío local. No se necesitan rutas estáticas a menos que el NGFW necesite un gateway predeterminado para gestión.

Destino Siguiente salto Interfaz Propósito
172.16.0.0/16 directamente conectado Inside.20 Agentes browser engine
172.17.0.0/16 directamente conectado Inside.30 Agentes synthetic-load engine
10.1.1.0/27 – 10.1.20.0/27 directamente conectado Outside.101–120 Webservers de personas
192.168.90.0/24 directamente conectado Mgmt.99 Gestión SNMP
0.0.0.0/0 GW de la red de gestión Management Acceso a internet para actualizaciones (opcional)

Ruteo basado en políticas: algunos NGFWs aplican decisiones de ruteo por regla de política de seguridad. Asegúrese de que su política de acceso permita tráfico de la zona agents a la zona personas en TCP 443 (y UDP 443 para HTTP/3 / QUIC).

6. PKI — Las Dos CAs

Esta es la parte más crítica de la configuración del NGFW. Hay dos CAs completamente distintas, cada una usada para un leg TLS diferente.

6.1 CA para el Leg 2 — persona-ca (importar EN el NGFW)

Qué es: la CA interna utilizada por cert-manager en el cluster Kubernetes para firmar los certificados TLS de las personas Caddy (20 Synthetic + 10 Cloned slots).

Por qué el NGFW la necesita: en el Leg 2 (NGFW → webserver), el NGFW actúa como cliente TLS y debe validar el certificado del servidor presentado por Caddy. Si el NGFW no confía en la persona-ca, rechazará la conexión con un error de validación de certificado.

Cómo exportarla del cluster:

# En el servidor Ubuntu (tras ejecutar k8s-dut-up.sh o k8s-install.sh)
kubectl get secret persona-ca -n web-agents \
  -o jsonpath='{.data.ca\.crt}' | base64 -d > persona-ca.pem

# Verificar el certificado
openssl x509 -in persona-ca.pem -text -noout | grep -E "Subject:|Issuer:|Not After"

Salida esperada: 

Subject: O=Web Agent Cluster, OU=DUT Lab, CN=Persona CA
Issuer:  O=Web Agent Cluster, OU=DUT Lab, CN=Persona CA
Not After: <fecha ~10 años desde la creación del cluster>

Dónde importarla en el NGFW: consulte la sección 8 para instrucciones específicas por fabricante. En general: trusted CA store / trusted CAs para inspección SSL.

6.2 CA para el Leg 1 — ngfw-ca (exportar DEL NGFW, instalar en el cluster)

Qué es: la CA que el NGFW utiliza para firmar los certificados de forward-proxy que presenta a los agentes durante el Leg 1. Es la CA de interceptación propia del NGFW.

Por qué el cluster la necesita: los agentes browser engine (Node.js) y synthetic-load engine (Go) validan el certificado del servidor en cada conexión HTTPS. Si no confían en la CA del NGFW, todas las conexiones fallarán con CERT_AUTHORITY_INVALID o similar.

Cómo exportarla de cada fabricante:

Fabricante Dónde encontrarla Formato de exportación
Cisco FTD (FMC) Objects → PKI → CA Certificates → seleccionar CA de interceptación → Export PEM
Cisco FTD (FDM) Policies → SSL → Trusted CA → exportar PEM
Cisco ASA crypto ca export <trustpoint> certificate PEM (copiar desde terminal)
FortiGate Security Profiles → SSL/SSH Inspection → CA Certificate → Download PEM
Palo Alto Device → Certificate Management → Certificates → seleccionar cert forward-trust → Export PEM
Check Point SmartConsole → Gateways → HTTPS Inspection → CA Certificate → Export PEM o Base64
Huawei USG System → PKI → CA Certificate → Export PEM
Meraki MX Security & SD-WAN → Content Filtering → SSL Inspection → Download CA Certificate PEM

Cómo instalarla en el cluster:

# Reemplace con la ruta real del archivo PEM exportado
kubectl create configmap ngfw-ca \
  -n web-agents \
  --from-file=ngfw-ca.crt=./ngfw-ca.pem \
  --dry-run=client -o yaml | kubectl apply -f -

# Verificar que fue aplicado
kubectl get configmap ngfw-ca -n web-agents -o yaml | grep 'ngfw-ca.crt' -A 3

# Reiniciar los agentes para cargar la nueva CA
kubectl rollout restart deployment/web-agent  -n web-agents
kubectl rollout restart deployment/k6-agent   -n web-agents
kubectl rollout status  deployment/web-agent  -n web-agents
kubectl rollout status  deployment/k6-agent   -n web-agents

7. Política de Inspección TLS

7.1 Qué inspeccionar

Configure la política de inspección TLS para descifrar e inspeccionar todo el tráfico HTTPS entre las subredes de agentes y personas:

Origen Destino Puerto Acción
172.16.0.0/16 (browser engine) 10.1.0.0/16 (todas las personas) TCP 443 Descifrar e Inspeccionar
172.17.0.0/16 (synthetic-load engine) 10.1.0.0/16 (todas las personas) TCP 443 Descifrar e Inspeccionar
172.16.0.0/16 (browser engine) 10.1.0.0/16 (todas las personas) UDP 443 Descifrar e Inspeccionar (QUIC/HTTP3)
172.17.0.0/16 (synthetic-load engine) 10.1.0.0/16 (todas las personas) UDP 443 Descifrar e Inspeccionar (QUIC/HTTP3)

7.2 Versiones TLS

Los webservers Caddy soportan TLS 1.2 y TLS 1.3. Configure el NGFW para inspeccionar ambos:

  • Mínimo: TLS 1.2
  • Máximo: TLS 1.3
  • Deshabilitar: TLS 1.1, TLS 1.0, SSL 3.0

7.3 Conjuntos de cifrado

Caddy utiliza exclusivamente cipher suites ECDHE+AEAD (certificados ECDSA). Asegúrese de que su política de inspección no haga downgrade a cifras RSA o CBC:

TLS_AES_256_GCM_SHA384          (TLS 1.3)
TLS_AES_128_GCM_SHA256          (TLS 1.3)
TLS_CHACHA20_POLY1305_SHA256    (TLS 1.3)
ECDHE-ECDSA-AES256-GCM-SHA384  (TLS 1.2)
ECDHE-ECDSA-AES128-GCM-SHA256  (TLS 1.2)
ECDHE-ECDSA-CHACHA20-POLY1305  (TLS 1.2)

7.4 HTTP/3 (QUIC) — nota importante

El agente k6 puede generar HTTP/3 (QUIC sobre UDP 443). La inspección TLS de HTTP/3 es más difícil para los NGFWs y es una de las métricas clave que se mide. Consulte la documentación de su fabricante para soporte de inspección QUIC:

  • Si la inspección QUIC es compatible: habilítela e incluya UDP 443 en la política de inspección.
  • Si la inspección QUIC no es compatible (o desea medir solo HTTP/2): agregue una regla para bloquear o resetear UDP 443, lo que fuerza a los agentes a hacer fallback a HTTP/2 sobre TCP. Este es un escenario de prueba válido — mide el impacto de forzar a los clientes QUIC a degradar.

7.5 Validación de certificado en el Leg 2

El NGFW debe validar el certificado del servidor durante el Leg 2 (NGFW → Caddy). Asegúrese de que:

  • Validación del certificado del servidor: habilitada (no omitida)
  • Trust store: incluye persona-ca.pem (ver sección 6.1)
  • Revocación de certificados: CRL/OCSP puede deshabilitarse — este es un laboratorio sin infraestructura de revocación

8. Ejemplos de Configuración por Fabricante

8.1 Cisco FTD — Firepower Management Center

Paso 1: Importar persona-ca (confiar en los certs de webservers de personas)

  1. Objects → PKI → Trusted CAs → Add Trusted CA
  2. Nombre: Persona-CA
  3. Subir persona-ca.pem
  4. Hacer clic en Save

Paso 2: Exportar ngfw-ca (para que los agentes confíen en el NGFW)

  1. Objects → PKI → CA Certificates → seleccionar su CA de interceptación
  2. Hacer clic en Export → descargar PEM
  3. Instalar en el cluster: kubectl create configmap ngfw-ca -n web-agents --from-file=ngfw-ca.crt=<archivo>.pem

Paso 3: Crear Política SSL

  1. Policies → SSL → New Policy
  2. Nombre: DUT-TLS-Inspection
  3. Agregar regla:
  4. Action: Decrypt — Resign
  5. Source Zones: agents
  6. Destination Zones: personas
  7. Destination Ports: TCP 443, UDP 443
  8. Resign CA: seleccionar su CA de interceptación
  9. Default Action: Do Not Decrypt (pasar el resto del tráfico sin inspección)

Paso 4: Crear regla en la Política de Control de Acceso

  1. Policies → Access Control → su política
  2. Agregar regla sobre el predeterminado:
  3. Source Networks: 172.16.0.0/16, 172.17.0.0/16
  4. Destination Networks: 10.1.0.0/16
  5. Destination Ports: TCP 443, UDP 443
  6. SSL Policy: DUT-TLS-Inspection
  7. Action: Allow (con inspección)
  8. Intrusion Policy: adjuntar si desea métricas de IPS durante la prueba
  9. Desplegar al sensor FTD

Paso 5: Configurar interfaces

# En FMC: Devices → Device Management → seleccione su FTD → Interfaces
# Configure subinterfaces en las interfaces físicas:

Interfaz inside (trunk):
  Subinterface 20: VLAN 20, IP 172.16.0.1/16, Security Zone: agents
  Subinterface 30: VLAN 30, IP 172.17.0.1/16, Security Zone: agents

Interfaz outside (trunk):
  Subinterface 101: VLAN 101, IP 10.1.1.1/27,  Security Zone: personas
  Subinterface 102: VLAN 102, IP 10.1.2.1/27,  Security Zone: personas
  ...
  Subinterface 120: VLAN 120, IP 10.1.20.1/27, Security Zone: personas

Interfaz de gestión:
  Subinterface 99: VLAN 99, IP 192.168.90.3/24  (fuera de banda, SNMP)

8.2 Cisco FTD — Firepower Device Manager

Importar persona-ca

  1. Objects → Certificates → Trusted CA → Add
  2. Nombre: Persona-CA, subir persona-ca.pem

Exportar ngfw-ca

  1. Policies → SSL → Trusted CA → exportar su CA de interceptación

Crear Política de Descifrado SSL

  1. Policies → SSL Decryption → Add Rule
  2. Origen: 172.16.0.0/16, 172.17.0.0/16
  3. Destino: 10.1.0.0/16
  4. Puerto: HTTPS (443/tcp)
  5. Acción: Decrypt — Resign con su CA de interceptación

8.3 Cisco ASA

ASA con FirePOWER Services (módulo SFR) o ASA con inspección SSL de AnyConnect:

# Importar persona-ca como CA de confianza
crypto ca authenticate DUT-ROOT-CA

# Pegar el contenido PEM cuando se solicite (contenido de persona-ca.pem)

# Crear crypto map o política de inspección SSL hacia:
#   src 172.16.0.0 255.255.0.0 y 172.17.0.0 255.255.0.0
#   dst 10.1.0.0 255.255.0.0
#   puerto 443

# Crear subinterfaces para VLANs de agentes
interface GigabitEthernet0/0.20
 encapsulation dot1Q 20
 ip address 172.16.0.1 255.255.0.0
 nameif agents-pw
 security-level 50

interface GigabitEthernet0/0.30
 encapsulation dot1Q 30
 ip address 172.17.0.1 255.255.0.0
 nameif agents-k6
 security-level 50

# Crear subinterfaces para VLANs de personas (repetir para 101-120)
interface GigabitEthernet0/1.101
 encapsulation dot1Q 101
 ip address 10.1.1.1 255.255.255.224
 nameif persona-shop
 security-level 0

# ... repetir para VLANs 102-120 ...

# Habilitar inspección SSL vía módulo FirePOWER o ASA CX

8.4 FortiGate

Crear VLANs e IPs de interfaces

# En CLI:
config system interface
  edit "inside.20"
    set vdom "root"
    set ip 172.16.0.1 255.255.0.0
    set allowaccess ping
    set type vlan
    set interface "port1"
    set vlanid 20
    set role lan
  next
  edit "inside.30"
    set vdom "root"
    set ip 172.17.0.1 255.255.0.0
    set type vlan
    set interface "port1"
    set vlanid 30
    set role lan
  next
  edit "outside.101"
    set vdom "root"
    set ip 10.1.1.1 255.255.255.224
    set type vlan
    set interface "port2"
    set vlanid 101
    set role wan
  next
  # ... repetir para VLANs 102-120 ...
end

Importar persona-ca

# GUI: Security Profiles → SSL/SSH Inspection → Crear/Editar perfil
# En "CA Certificate": importar persona-ca.pem

# O vía CLI:
config vpn certificate ca
  edit "Persona-CA"
    set ca "<persona-ca codificado en base64>"
  next
end

Exportar ngfw-ca

# GUI: Security Profiles → SSL/SSH Inspection → seleccione su perfil
#       → CA Certificate → Download
# Esto descarga la CA de interceptación de FortiGate en formato PEM.

Crear Perfil de Inspección SSL/SSH

# GUI: Security Profiles → SSL/SSH Inspection → Create New
config firewall ssl-ssh-profile
  edit "DUT-Inspection"
    set comment "TLSStress.Art modo DUT"
    config https
      set ports 443
      set status deep-inspection
      set proxy-after-tcp-handshake enable
    end
    config ssl
      set inspect-all deep-inspection
    end
    set caname "Persona-CA"
  next
end

Crear política de firewall

config firewall policy
  edit 100
    set name "DUT-agentes-a-personas"
    set srcintf "inside.20" "inside.30"
    set dstintf "outside.101" "outside.102" ... "outside.120"
    set srcaddr "172.16.0.0/16" "172.17.0.0/16"
    set dstaddr "10.1.0.0/16"
    set action accept
    set schedule "always"
    set service "HTTPS"
    set ssl-ssh-profile "DUT-Inspection"
    set utm-status enable
    set logtraffic all
  next
end

8.5 Palo Alto PAN-OS

Importar persona-ca

# GUI: Device → Certificate Management → Certificates → Import
# Nombre: Persona-CA
# Archivo: persona-ca.pem
# Marcar como: "Trusted Root CA"

# O vía CLI:
scp import certificate from <usuario@host:/ruta/persona-ca.pem>
> certificate-name Persona-CA
> category trusted-root-CA

Exportar ngfw-ca

# GUI: Device → Certificate Management → Certificates →
#       seleccionar su certificado forward-trust → Export Certificate
# Formato: Base64 Encoded Certificate (PEM)

Crear interfaces

# GUI: Network → Interfaces → Ethernet → Add Sub-Interface

# Interfaz inside (hacia los agentes)
Ethernet1/1.20:  IP 172.16.0.1/16, VLAN 20, Zone: agents
Ethernet1/1.30:  IP 172.17.0.1/16, VLAN 30, Zone: agents

# Interfaz outside (hacia las personas)
Ethernet1/2.101: IP 10.1.1.1/27,   VLAN 101, Zone: personas
Ethernet1/2.102: IP 10.1.2.1/27,   VLAN 102, Zone: personas
# ... repetir para 103-120 ...

Crear Perfil de Descifrado

# GUI: Objects → Decryption Profile → Add
# Nombre: DUT-Decrypt-Profile
# SSL Forward Proxy:
#   Forward Trust Certificate: <su CA de interceptación>
#   Forward Untrust Certificate: <su CA de no confianza>
# Server Certificate Verification:
#   Block sessions with expired certificates: yes
#   Block sessions with untrusted issuers: yes (con persona-ca como confiable)

Crear Política de Descifrado

# GUI: Policies → Decryption → Add
# Nombre: DUT-Decrypt-All
# Source Zone: agents
# Destination Zone: personas
# Source Address: 172.16.0.0/16, 172.17.0.0/16
# Destination Address: 10.1.0.0/16
# Service: application-default (o cree servicio HTTPS para 443/tcp + 443/udp)
# Type: SSL Forward Proxy
# Profile: DUT-Decrypt-Profile

Crear Política de Seguridad

# GUI: Policies → Security → Add
# Nombre: agents-a-personas
# Source Zone: agents
# Destination Zone: personas
# Application: ssl, web-browsing
# Service: application-default
# Action: Allow
# Profile Group: adjuntar su perfil de amenaza/URL

8.6 Check Point

Importar persona-ca

# SmartConsole → Objects → New → Certificate Authority → Trusted CA
# Nombre: Persona-CA
# Subir: persona-ca.pem

Exportar ngfw-ca

# SmartConsole → Gateways & Servers → doble clic en su gateway
# → HTTPS Inspection → CA Certificate → Export
# Guardar como PEM

Configurar Inspección HTTPS

# SmartConsole → Security Policies → HTTPS Inspection → Policy
# Agregar regla:
# Nombre: DUT-Inspection
# Source: Group(172.16.0.0/16, 172.17.0.0/16)
# Destination: Group(10.1.1.0/27 - 10.1.20.0/27)
# Services: HTTPS (443)
# Site Category: Any
# Action: Inspect
# Track: Log

# En Blade Control → SSL Inspection → Trusted CA:
# Agregar Persona-CA al trust store

Configurar interfaces

# SmartConsole → Gateways → Interfaces → Add VLAN
# Crear subinterfaces para cada VLAN (20, 30, 101-120)
# Asignar IPs según la sección 3 anterior

9. Verificación

9.1 Verificar conectividad desde el cluster

# SSH a uno de los pods de agente
kubectl exec -it -n web-agents deployment/web-agent -- sh

# Probar que el gateway del NGFW es accesible
ping -c 3 172.16.0.1        # Gateway VLAN 20 (browser-engine)
ping -c 3 172.17.0.1        # Gateway VLAN 30 (K6, desde pod K6)

# Probar HTTPS a una persona (debe funcionar si la inspección TLS está activa)
curl -v https://shop.persona.internal/ --max-time 5
# Esperado: HTTP 200, certificado emitido por la CA del NGFW

9.2 Verificar que la inspección TLS está activa

# Desde un pod de agente, inspeccionar la cadena de certificados presentada por el NGFW
echo | openssl s_client -connect shop.persona.internal:443 -servername shop.persona.internal 2>/dev/null \
  | openssl x509 -noout -issuer -subject

# Salida esperada (certificado emitido por NGFW, no por persona-ca):
# issuer=CN=<nombre de su CA de interceptación NGFW>
# subject=CN=shop.persona.internal   (re-firmado por NGFW)

9.3 Verificar monitoreo SNMP

# Desde el pod SNMP, probar conectividad con el NGFW
kubectl exec -it -n web-agents deployment/snmp-exporter -- sh
snmpwalk -v2c -c <community> 192.168.90.3 1.3.6.1.2.1.1.1.0

# Esperado: sysDescr del NGFW

9.4 Verificar Leg 2 TLS (NGFW confía en el cert del webserver)

Verifique los logs del NGFW en busca de errores TLS en el leg de salida. Si ve fallas de validación de certificado hacia 10.1.x.x, la persona-ca no fue importada correctamente.

# En el cluster: confirmar la cadena de certificados del webserver
echo | openssl s_client -connect 10.1.1.2:443 2>/dev/null \
  | openssl x509 -noout -issuer -subject

# Esperado (antes de interceptación por NGFW — directo desde el servidor Ubuntu):
# issuer=CN=Persona CA
# subject=CN=shop.persona.internal

10. Solución de Problemas

Síntoma Causa probable Solución
Los agentes reciben CERT_AUTHORITY_INVALID ngfw-ca no instalada en el cluster o agentes no reiniciados Re-ejecutar kubectl create configmap ngfw-ca ... y kubectl rollout restart deployment/web-agent
NGFW muestra error de validación de cert en Leg 2 persona-ca no importada en el trust store del NGFW Exportar persona-ca.pem del cluster e importar en el trusted CA store del NGFW
Conexiones HTTP/3 fallan pero HTTP/2 funciona El NGFW no soporta inspección QUIC Bloquear UDP 443 en el NGFW para forzar degradación a HTTP/2; registrar esto en los resultados de la prueba
Los agentes no pueden alcanzar IPs de personas (10.1.x.x) Rutas faltantes o política del NGFW bloqueando Verificar que la política de seguridad del NGFW permita 172.16.0.0/16 y 172.17.0.0/16 hacia 10.1.0.0/16
SNMP exporter no retorna datos del NGFW SNMP del NGFW no habilitado, community incorrecta o VLAN 99 inaccesible Verificar que SNMP del NGFW esté habilitado con community public (o según observability/snmp/snmp.yml); verificar que la IP 192.168.90.3 en VLAN 99 responda a ping
La inspección TLS no se activa Política SSL no vinculada a la regla de acceso, o zonas mal configuradas Verificar que las zonas de origen/destino correspondan a las interfaces de agentes y personas
Errores de certificado tras renovación de cert de persona NGFW con fingerprint de cert antiguo en caché Cert-manager renueva automáticamente los certs de personas cada 11 meses; Stakater Reloader reinicia los pods Caddy — no se requiere ningún cambio en el NGFW

Para detalles de arquitectura del test-bed, consulte docs/ARCHITECTURE.md. Para instrucciones de despliegue, consulte docs/UBUNTU_K3S_SINGLENODE_QUICKSTART_DEPLOY.en.md. Para el instalador Kubernetes automatizado, consulte scripts/k8s-install.sh.