Cuando el ADC y el firewall se gestionan por separado, la cadena de seguridad se rompe.
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.
Nuestro enfoque
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.
Gestión de firewall por namespace
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.
Pipeline de prueba → aplicación
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.
Conjuntos de reglas IPv4 e IPv6 en paralelo
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.
Reglas de firewall automáticas desde objetos ADC
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.
Capacidades
El Firewall Integrado combina el control clásico L3/L4 con generación automática de reglas nativa del ADC, mitigación DDoS, cuarentena, CGNAT determinista y aislamiento de namespace.
Aislamiento de firewall por 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.
CGNAT determinista — trazabilidad del abonado sin registro de sesiones
Cada abonado recibe un bloque fijo y precalculado de puertos públicos: identificar al abonado desde una dirección y un puerto públicos es aritmética, no una consulta a base de datos. El registro por sesión que de otro modo impone la RFC 6888, y que suele dominar el coste de un despliegue CGNAT, desaparece sin perder la trazabilidad legal. Se incluyen ALG para FTP, TFTP, SIP, PPTP y H.323. El filtrado independiente del extremo y el hairpinning quedan fuera del alcance de esta versión.
Gestión separada de IPv4 e IPv6
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.
NAT de doble pila, NAT66 incluido — una regla, dos familias de direcciones
El mismo motor de reglas emite los conjuntos IPv4 e IPv6 desde una sola política, así que el SNAT estático, el DNAT y la traducción uno a uno se comportan igual en una red IPv6. La traducción entre prefijos IPv6 — NAT66 — forma parte de ello, y lo decimos con claridad porque suele darse por ausente. No hay una vía de configuración IPv6 aparte ni reglas que se apliquen calladamente a una sola familia: eso es lo que impide que un despliegue IPv6 se convierta en un segundo cortafuegos a medio recordar.
Definición de reglas por interfaz
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.
Reglas allow, deny, forward y not-forward
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.
Soporte DNAT y SNAT
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.
Coincidencia GeoIP y por país
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.
Coincidencia CIDR, MAC y negate
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.
Coincidencia multi-puerto y rango de puertos
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.
Más de 20 directivas de protección DDoS
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.
Tablas de cuarentena
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.
Soporte de connection mark para persistencia L4
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.
Reglas automáticas ADC/GTM/NAT
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.
Aislamiento de reglas defectuosas
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.
Soporte de log y auditoría
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.
Protección automática para interfaces de gestión y sync de cluster
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.
Profundidad 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.
Ruta de configuración y separación de conjuntos de reglas
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.
Timeout de sincronización y aplicación segura
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.
Sincronización de namespace en paralelo
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
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.
Connection tracking
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.
Hashlimit y connlimit
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.
ICMP y descubrimiento de vecinos IPv6
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.
Conjunto de reglas final tras recuperación de errores
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.
Cuándo utilizarlo
Reducción de fuerza bruta SSH en la interfaz de gestión
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.
Política de acceso por país
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.
Separación DNAT multi-tenant
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.
Mitigación DDoS integrada
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.
Tránsito controlado entre segmentos mediante cadena FORWARD
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.
Publicación DNAT inline
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.
Preguntas frecuentes
¿Cuál es la diferencia entre un firewall por namespace y un firewall global?
Si se escribe una regla defectuosa, ¿se rompe todo el firewall?
¿Las reglas IPv6 se gestionan por separado de las reglas IPv4?
¿Se requiere un dispositivo separado para la protección DDoS?
¿Pueden generarse reglas de firewall automáticamente desde objetos ADC?
¿Cómo funciona la coincidencia GeoIP y afecta al rendimiento?
Gestione la seguridad de red desde la misma consola que su ADC
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.