En la configuración del NGFW (firewall de próxima generación) los modos Fail Open y Fail Close determinan el comportamiento del dispositivo cuando la protección o la inspección dejan de funcionar dentro del modo normal de operación. En pocas palabras, el sistema debe elegir entre dos opciones. O bien dejar pasar el tráfico para que la red no se detenga, o bien cerrar el acceso para impedir que el tráfico no verificado atraviese el perímetro.
El problema empieza cuando este asunto se convierte en una bonita casilla en una tabla. En el portal la línea «Fail Close / Fail Open» parece simple y clara, pero en la práctica no habla de la «calidad de supervivencia bajo carga», sino, ante todo, de la existencia de un mecanismo y de la posibilidad de configurar el comportamiento cuando se activan las condiciones de alta carga. En la metodología la lógica está descrita de forma directa: en el modo Fail Close el sistema debe cerrar el acceso, y en el modo Fail Open mantener el acceso abierto. La formulación es útil, pero muy básica.
Qué significan realmente Fail Open y Fail Close
Fail Open suele elegirse cuando la caída de la conexión es más peligrosa que un debilitamiento temporal del control. Este enfoque se da en nodos donde no es posible detener un proceso de negocio, el acceso a servicios o las integraciones externas. El coste de la decisión es evidente: en modo de fallo parte del tráfico puede pasar sin la profundidad de inspección que se esperaba en el funcionamiento normal.
Fail Close se utiliza donde permitir tráfico no verificado es más peligroso que una parada. Este modo se acerca a un modelo de seguridad conservador. Si el módulo de inspección deja de funcionar, se cierra el acceso. Desde el punto de vista de la protección la lógica es estricta pero clara. Desde la perspectiva de operaciones, esta elección puede convertir una sobrecarga, una falla del módulo o una actualización defectuosa en una auténtica interrupción del servicio.
Fail Open responde a la pregunta «qué es más importante, que la red siga funcionando». Fail Close responde a la pregunta «qué es más importante, que no pase tráfico no verificado». No hay una opción universalmente correcta.
Cómo leer la tabla ngfw.jet.su sin ilusiones
En el portal se mezclan fichas de diferentes generaciones de la metodología, desde v1.0 hasta v3.0, y la última actualización está fechada el 25 de marzo de 2026. Por eso la comparación horizontal sigue siendo útil, pero no conviene imaginar una simetría ideal de condiciones. Junto a una misma línea pueden aparecer los mismos iconos, mientras que la madurez ingenieril real de las soluciones puede diferir notablemente.
El error más frecuente es este: el lector ve en la línea «Fail Close / Fail Open» la marca «Sí» y mentalmente completa una imagen en la que el dispositivo degrada su servicio con suavidad, mantiene sesiones, responde a los umbrales de forma predecible y no rompe funciones adyacentes. La tabla no promete eso. La tabla solo indica que el mecanismo ha sido declarado o detectado en el alcance de la prueba.
| Elemento de la tabla en ngfw.jet.su | Qué muestra | Qué no muestra | Qué conclusión sacar |
|---|---|---|---|
| «Sí» en la línea Fail Close / Fail Open | El producto tiene un comportamiento configurable cuando se activan condiciones de alta carga | No demuestra degradación suave, umbrales correctos, preservación de sesiones ni funcionamiento uniforme de todos los módulos | Considerarlo como un requisito básico para seguir la conversación, no como una victoria comparativa |
| «±» | Hay soporte, pero con reservas: parcial, solo para algunos módulos o en escenarios limitados | No equivale a una lógica completa de doble sentido («Fail Open y Fail Close en todas partes donde se necesite») | Buscar de inmediato las limitaciones, los comentarios y las filas adyacentes |
| «No» | No se encontró un mecanismo explícito dentro de la metodología | No significa que el dispositivo sea completamente incapaz en una emergencia, pero puede que no sea posible elegir el comportamiento de forma consciente | Para un perímetro con carga, ya es motivo para plantear preguntas incómodas al proveedor |
| Prueba de carga EMIX | Muestra dónde el dispositivo alcanza el límite con un perfil de tráfico mixto | No equivale a la velocidad nominal del folleto | Compararlo con el aumento del número de reglas y verificar si detrás de la atractiva línea Fail Open no se oculta una simple caída de rendimiento |
| Comportamiento al actualizar las reglas | Muestra si las sesiones se interrumpen y cómo el producto afronta los cambios de políticas | No reemplaza la prueba de sobrecarga | Ayuda a comprender la madurez del plano de control |
| Comportamiento ante enrutamiento asimétrico | Muestra hasta qué punto el producto tolera las condiciones reales de red | No equivale a la calidad del IPS o de la inspección SSL | Si aquí es frágil, la bonita historia sobre la sobrecarga deja de parecer convincente |
Un matiz de la metodología suele pasarse por alto. El documento permite configurar el comportamiento «completo o para módulos individuales». Para el comprador esto no es una aclaración menor, sino una cuestión central. Si el producto solo sabe aplicar Fail Open en un punto de la cadena, y un módulo crítico actúa con otra lógica, el soporte formal del modo dice poco sobre el riesgo real.
Un buen ejemplo de cómo leer esa línea con cuidado ofrece la ficha PT NGFW 1.7.2, donde aparece «±» frente al caso. Ese signo es más útil que un «Sí» excesivamente confiado, porque obliga a buscar de inmediato los límites de la implementación. El soporte parcial con una marca honesta es mejor que una promesa amplia sin desglose, que el comprador luego completa por su cuenta.
Dónde empieza la niebla del marketing
La niebla del marketing aparece cuando la línea Fail Open / Fail Close se presenta como prueba de la resistencia general a fallos. La resistencia a fallos en el perímetro no se reduce a un único interruptor. Hay que ver qué pasa con las sesiones ya abiertas, cómo funcionan el IPS, la inspección SSL, el control de aplicaciones, los registros, el enrutamiento, los clústeres y el cambio de enlaces. Incluso una lógica perfecta de «abrir o cerrar» no salva a un producto que cae en rendimiento al aumentar el número de reglas, rompe conexiones al actualizar políticas o se comporta de forma inestable en topologías atípicas.
Por eso la línea sobre Fail Open / Fail Close siempre debe leerse junto con la sección de carga. En ngfw.jet.su el umbral en las pruebas de carga se fija donde la pérdida de paquetes o de sesiones supera el 1%. Ahí termina la teoría y empieza el coste real de las decisiones arquitectónicas. Si el modo de sobrecarga existe formalmente, pero el rendimiento se desploma demasiado pronto con el aumento de reglas, para la operación esa combinación puede ser peor que una implementación modesta pero predecible.
También hay otra trampa. Fail Open no siempre significa «la seguridad se apagó por completo», ni Fail Close siempre significa «todo murió al instante». En distintos proveedores la lógica puede activarse en etapas diferentes de la cadena, con umbrales distintos y con volúmenes de bypass distintos. Por eso la pregunta directa al proveedor no debe ser «¿soportan Fail Open?», sino «¿qué módulos exactos y en qué condiciones pasan a Fail Open, qué ocurre con las sesiones nuevas y existentes, y dónde se registran los eventos?»
Qué preguntar al proveedor antes del piloto
Antes del piloto conviene no discutir términos y obtener la concreción rápidamente. Qué módulos pueden pasar a Fail Open, cuáles siempre permanecerán en Fail Close, quién define el umbral de activación, si se preservan las sesiones actuales, si cambia el registro de eventos, cómo se comporta el clúster y si es posible reproducir el escenario en un banco de pruebas con su carga. Tras esa conversación, la mitad de las presentaciones bonitas pierde peso de repente.
¿Fail Open siempre es peor desde el punto de vista de la seguridad?
No siempre. Para algunos servicios la pérdida de conectividad es más costosa que un debilitamiento temporal del control. En esos segmentos Fail Open puede ser un compromiso consciente si el equipo entiende los límites del riesgo y sabe monitorizarlos.
¿Fail Close siempre es la elección correcta para el perímetro?
Tampoco siempre. Fail Close suena bien hasta el primer incidente real, donde la sobrecarga convierte la protección en una falla de servicio autoinfligida. Para servicios de negocio críticos esa rigidez puede ser demasiado costosa.
¿Se pueden comparar soluciones por una sola fila de la tabla?
No. La fila solo da una señal primaria. La comparación empieza a funcionar cuando se tienen juntos los datos sobre carga, actualización de reglas, enrutamiento asimétrico, fallos de enlace y comportamiento en clúster.
¿Qué significa el signo «±»?
Suele indicar soporte parcial, limitaciones de implementación o dependencia del módulo y del escenario concreto. Ese signo no debe leerse como «casi sí». Debe leerse como «vamos a ver las notas».
¿Cuál es el error más común al leer ngfw.jet.su?
Lo más frecuente es confundir la existencia de una función con la calidad de su implementación. Tener el mecanismo no implica que el producto gestione la sobrecarga de forma elegante y predecible.
La conclusión práctica es sencilla. Un buen NGFW no es el que tiene «Sí» en la línea Fail Open / Fail Close, sino el que tiene una lógica de comportamiento ante fallos alineada con las tareas del perímetro, en el que las pruebas adjuntas no muestran fragilidad y la parte de carga no se convierte en un corte brusco al crecer las reglas y los módulos activados.
