En las arquitecturas clásicas el ADC vive en un dispositivo, el firewall en otro, y las reglas de enrutamiento y NAT existen en otra capa operacional. Esta separación parece ordenada al principio, pero en producción cada cambio se convierte en un problema de coordinación. Se abre un nuevo vService y se olvida la regla de firewall. Cambia un DNAT y no se actualiza la ruta. Un segmento de backend cambia y la regla FORWARD queda obsoleta.
En entornos multi-namespace o multi-tenant el problema crece. Cuando cada tenant tiene su propio espacio de IP, sus propias interfaces y sus propias reglas NAT, una única tabla de firewall global no es suficiente. El mismo CIDR puede usarse en diferentes namespaces; en ese caso el firewall también debe separarse por namespace.
Usar un dispositivo de firewall separado no es solo una carga de gestión adicional — la auditoría y el failover también se fragmentan. Un operador no puede responder «¿quién abrió este tráfico?», «¿qué regla automática provino de qué vService?» o «¿en qué namespace está activo este DNAT?» desde un único panel. Durante un incidente, los logs del ADC, los logs del firewall y el estado del enrutamiento deben inspeccionarse por separado.
La seguridad en la aplicación de reglas es otro problema. En los conjuntos de reglas de firewall tradicionales, una única línea defectuosa puede hacer que toda la operación de carga falle. En producción las consecuencias son graves: las reglas correctas tampoco se aplican, el tráfico se interrumpe o la política de seguridad queda inactiva.
TR7 ADC trata el firewall como una parte natural del ADC: conjuntos de reglas por namespace, control por interfaz, reglas automáticas ADC/GTM/NAT, directivas DDoS, un pipeline de prueba-aplicación y aislamiento de reglas defectuosas se combinan en un único modelo de gestión.
El enfoque de firewall de TR7 no es un dispositivo de seguridad añadido — es una capa de control L3/L4 embebida en el modelo de tráfico, enrutamiento y namespace del ADC.
Cada namespace tiene su propio gestor de firewall. Una regla dentro de un namespace no toca el tráfico de otro namespace. Este modelo proporciona aislamiento seguro en escenarios multi-tenant, CIDR solapado y route table separada.
El nuevo contenido del firewall se prueba primero y luego se aplica. Si una línea falla, el conjunto de reglas completo no se cancela — la línea defectuosa se deshabilita automáticamente y las reglas sanas se reintentarán. Esto evita que un único error elimine todo el conjunto de reglas durante un cambio en producción.
Las reglas IPv4 e IPv6 se gestionan en archivos separados, con validación separada, en paralelo. Un fallo en una familia de IP no afecta a la otra. En servicios dual-stack la política de seguridad se aplica de forma consistente para ambas familias.
Cuando se configura un pool ADC, L4 NAT, DNAT inline, redirección DNS GTM, acceso de gestión o marcador de backend, las reglas de firewall pueden generarse automáticamente. Los operadores que abren un vService no necesitan recordar la parte de seguridad por separado.
El Firewall Integrado combina el control clásico L3/L4 con generación automática de reglas nativa del ADC, mitigación DDoS, cuarentena y aislamiento de namespace.
Cada namespace opera con un conjunto de reglas de firewall independiente. Un DNAT definido en el namespace del Tenant A no afecta al mismo bloque CIDR en el Tenant B. Esta estructura proporciona la separación de seguridad fundamental para escenarios multi-tenant y de espacio de IP solapado.
Las reglas IPv4 e IPv6 se producen y aplican como conjuntos de reglas separados. En servicios dual-stack el lado IPv6 no se olvida más adelante; los controles de allow, deny, forward, NAT y rate-limit pueden escribirse para ambas familias de IP.
Las reglas pueden definirse no solo a nivel de namespace sino también a nivel de interfaz. Pueden aplicarse diferentes políticas a la interfaz de gestión, la interfaz de sync, la interfaz de tenant o la interfaz de servicio. Este modelo controla el tráfico según el punto real de ingreso/egreso.
Las operaciones básicas del firewall se gestionan en un único modelo. Permitir, bloquear, permitir el paso en tránsito o excluir tráfico específico del tránsito pueden definirse en las cadenas INPUT y FORWARD.
DNAT puede aplicarse para redirigir el tráfico entrante a una IP de destino diferente; SNAT cambia la IP de origen del tráfico saliente. La publicación inline, la redirección de servicios L4 y los escenarios multi-segmento de backend se gestionan con estas reglas.
La coincidencia de IP de origen puede realizarse contra conjuntos de países. Es posible incluir en allowlist ciertos países, bloquear países específicos o descartar rápidamente regiones de alto riesgo durante un ataque. La operación basada en conjuntos preserva el rendimiento a escala.
Se admite la lógica de IP/CIDR, dirección MAC y «excluir». Por ejemplo, puede bloquearse una subred completa mientras se eximen IPs específicas. Esta estructura se usa tanto para allowlists operacionales como para reglas temporales de respuesta a incidentes.
Pueden definirse múltiples puertos o rangos de puertos en una única regla. Pueden escribirse políticas de acceso amplias o estrechas para puertos DNS, RADIUS, SIP, API y de gestión.
El descarte de paquetes inválidos, el límite de nuevas conexiones TCP, el límite total de conexiones, el límite de flood UDP, el límite de flood DNS/NTP, el límite de reset TCP, el descarte de fragmentos, la detección de MSS sospechoso, la detección de ataques LAND y el bloqueo de UDP de cero bytes pueden habilitarse todos bajo una única política.
Los orígenes que superan un umbral se agregan a conjuntos de cuarentena temporales. Cuando expira el período de cuarentena la entrada se elimina automáticamente. Los conjuntos de allowlist pueden excluirse de las reglas de cuarentena para que los orígenes de confianza nunca se vean afectados accidentalmente.
Los connection marks y las listas recientes pueden usarse para vincular el tráfico de clientes específicos al mismo backend en servicios L4. Esto es importante para la continuidad de sesión en escenarios UDP o de rango de puertos.
Se admiten tipos de reglas automáticas para permitir un puerto de servicio cuando se abre un pool, generar L4 SNAT/DNAT, crear una regla DNAT inline, redirigir el acceso DNS GTM o agregar una regla de deny local.
Cuando una línea falla durante la aplicación del conjunto de reglas, se detecta, se comenta y las reglas restantes se reintentarán. Una única regla defectuosa no puede detener toda la sincronización del firewall.
Las reglas pueden configurarse para producir entradas de log. Los comportamientos de drop, allow, DNAT o cuarentena pueden incluirse en la cadena de auditoría. Tras un incidente, puede rastrearse qué regla afectó a qué tráfico.
El tráfico de gestión y sync del cluster es gestionado especialmente por el sistema. Las interfaces críticas están protegidas con comportamiento de allow automático para evitar la pérdida accidental del acceso operacional.
La capa de firewall integrado no es solo una pantalla de escritura de reglas — trabaja junto con las pruebas, la sincronización, el aislamiento de errores, la generación automática de reglas y la gestión del ciclo de vida de los namespaces.
El contenido del firewall IPv4 e IPv6 para cada namespace se almacena en archivos de configuración separados. La última configuración combinada también se conserva, lo que facilita el seguimiento de cambios y la depuración.
La sincronización del firewall opera dentro de límites de timeout definidos. El proceso primero alcanza un estado listo; luego se ejecutan los pasos de prueba y aplicación. Una operación larga o bloqueada está delimitada por el sistema.
Cuando hay muchos namespaces presentes, la sincronización del firewall se ejecuta en lotes en paralelo. Esto hace que sea operacionalmente manejable que cada namespace tenga su propio conjunto de reglas en entornos multi-tenant.
Tipos de reglas automáticas como pool-tcp-udp, ftp-allow, l4-snat, l4-any-dnat, l4-any-snat, inline-dnat, fw-access-allow, fw-access-dnat, gtm-dns-dnat, gtm-access-dnat, local-deny y be-mark pueden generarse desde objetos ADC.
Los flujos de retorno para tráfico RELATED y ESTABLISHED se reconocen automáticamente. Esto reduce la necesidad de escribir reglas manuales separadas para cada paquete de retorno en servicios stateful.
Se admiten rate limits por origen y límites de conexión. Las conexiones excesivas, los paquetes reset, los paquetes ICMP, los floods UDP DNS/NTP o los intentos de nuevas conexiones TCP desde la misma IP pueden limitarse.
Bloquear ICMP completamente puede deteriorar funciones de red básicas como IPv6 y Path MTU Discovery. TR7 gestiona las políticas ICMP con granularidad; los mensajes de descubrimiento y control necesarios pueden gestionarse de forma segura.
Después de que las reglas defectuosas se comentan, el conjunto de reglas final se escribe de vuelta en disco. Los operadores pueden ver qué línea fue deshabilitada y corregirla. El sistema produce un resultado visible y accionable en lugar de un fallo silencioso.
Las conexiones SSH a la interfaz de gestión se limitan con un límite por origen. Si la misma IP supera el umbral definido se pone en cuarentena temporalmente. La superficie de fuerza bruta se reduce mientras el acceso de gestión permanece abierto.
Solo se permite el tráfico de países seleccionados; todos los demás se descartan. Esto proporciona un control rápido para el cumplimiento normativo y la reducción de riesgo por país en sistemas financieros, del sector público o sanitarios.
Mientras se aplica el DNAT 1.2.3.4 → 10.0.0.5 en el namespace del Tenant A, el Tenant B puede usar el mismo CIDR interno con una regla diferente. El aislamiento por namespace garantiza que las políticas NAT de los dos tenants no entren en conflicto.
Los comportamientos de flood UDP de cero bytes, flood DNS/NTP, TCP anormal, fragmentos y flood de conexiones se mitigan con mecanismos hashlimit, connlimit y cuarentena. Se aplica protección L3/L4 básica sin un dispositivo de scrubbing separado.
Cuando se necesita tráfico de tránsito entre dos segmentos de backend, se establece un paso controlado con reglas FORWARD. Se define con precisión qué origen puede alcanzar qué destino en qué puerto.
La IP de un backend se publica a través de TR7 y el tráfico entrante se entrega al backend relevante mediante DNAT inline. La capa de seguridad y enrutamiento de TR7 se inserta sin cambiar el plan de IP de la aplicación o del backend.
Aislamiento de namespace, directivas DDoS, DNAT/SNAT y generación automática de reglas — le mostramos una configuración en vivo en su propio entorno.