Infraestructura y redes · Caso real
FortiGate 50E lento: cómo diagnosticar una falla del switch interno (ISF)
Descarga al 10% de lo contratado, subida normal, y el problema sigue igual después del factory reset. Cuando la configuración y el firmware quedan descartados, el sospechoso es el hardware — y en el 50E hay un componente que explica por qué cambiar de puerto no sirve de nada.
Por Christian Sepúlveda, Gerente de Proyectos en SEiT S.p.A.
26 de agosto de 2026
Lectura: 8 min
Resumen del caso
Un FortiGate 50E con más de siete años de operación y firmware FortiOS 6.2.3 presentaba conectividad errática. Medido directamente contra el ISP, el enlace entregaba el 100% de la velocidad contratada. Conectado a través del firewall — incluso con configuración de fábrica — la descarga caía a un 10% o menos, mientras la subida se mantenía entre 80% y 100% de forma inconsistente.
Actualizar el firmware a 6.2.5 no cambió nada. Mover el servicio LAN a otros puertos internos tampoco. La causa era una falla de hardware en el switch interno (ISF) que gobierna los cinco puertos LAN del equipo. La solución provisoria fue reconfigurar el puerto wan2 con rol LAN, lo que restableció el rendimiento completo mientras se gestionaba el reemplazo del equipo.
Los síntomas exactos
El patrón importa, porque es lo que uno busca en Google a las once de la noche con un cliente sin internet. Estos fueron los síntomas observados:
- Medición directa al ISP: 100% de la velocidad contratada, estable.
- Medición detrás del FortiGate: descarga al 10% o menos.
- Subida: entre 80% y 100%, pero inconsistente entre pruebas.
- Pruebas desde el FortiGate: resultados normales, dentro de lo esperado.
- Pruebas a través del FortiGate: insuficientes, siempre.
- Persistencia: el comportamiento se mantenía con la configuración de fábrica.
Esa asimetría — descarga destruida, subida casi intacta — suele apuntar a un problema de capa física: negociación de velocidad y dúplex, cableado, o errores de CRC en un puerto. Es la primera hipótesis correcta y hay que perseguirla. Lo distinto de este caso es que la asimetría sobrevivió a todas las correcciones de capa física.
Qué descartar primero
Antes de sospechar del hardware hay que agotar lo barato. En orden de probabilidad:
| Hipótesis | Cómo se verifica | Señal de que es esto |
|---|---|---|
| Negociación velocidad/dúplex | Revisar el estado del enlace en la interfaz y forzar 1000/full en ambos extremos | El puerto reporta 100 Mbps o half-duplex |
| Cable o puerto del switch dañado | Cambiar patch cord y puerto del switch aguas abajo | Contadores de errores en aumento |
| Perfiles de inspección pesados | Quitar temporalmente antivirus, IPS e inspección SSL de la política | CPU alta bajo carga; el rendimiento mejora al quitar perfiles |
| Aceleración por hardware | Deshabilitar el offload ASIC en la política de prueba | El rendimiento cambia al activar o desactivar el offload |
| Defecto de firmware | Actualizar dentro de la misma rama y volver a medir | El comportamiento cambia con la versión |
| Falla del switch interno | Probar todos los puertos internos, en configuración de fábrica | Nada de lo anterior cambia el resultado |
Los comandos útiles para esta etapa, desde la CLI del FortiGate:
# Versión, modelo y tiempo de operación
get system status
# Estado del enlace y contadores de error por puerto físico
# (buscar Rx_CRC_Errors, Rx_Errors, Rx_Drops, collisions)
diagnose hardware deviceinfo nic lan1
# Listado de interfaces y su estado a nivel de kernel
diagnose netlink device list
# Carga de CPU y memoria durante la prueba de velocidad
get system performance status
# Prueba de conectividad desde el propio equipo
execute ping 1.1.1.1
execute traceroute 1.1.1.1El nombre de los puertos varía según modelo y versión de FortiOS: pueden aparecer como lan1 a lan5, como internal1 a internal5, o agrupados bajo una interfaz de tipo hardware switch llamada internal. Conviene confirmarlo con diagnose netlink device list antes de asumir.
El diagnóstico, paso a paso
La secuencia que seguimos en este caso, en el orden real en que ocurrió:
- Medición de línea base contra el ISPSe conectó un equipo directamente al enlace del proveedor. Resultado: 100% de la velocidad contratada. El ISP quedó descartado, y eso importa: sin esta medición, la conversación con el proveedor consume días.
- Medición a través del firewallCon el FortiGate en línea, la descarga cayó bajo el 10%. La subida se mantuvo alta pero errática. Primera evidencia de que el problema está en el equipo o en su ruta física.
- Restablecimiento a configuración de fábricaSe volvió al factory default para eliminar cualquier política, perfil de seguridad, shaper de tráfico o configuración heredada. El síntoma se mantuvo idéntico. A partir de aquí, la configuración deja de ser una explicación posible.
- Actualización de firmware 6.2.3 → 6.2.5Se subió la versión dentro de la misma rama para descartar un defecto conocido de software. Sin cambios: mismos resultados insuficientes. El firmware queda descartado.
- Rotación por los puertos internosSe configuró el servicio LAN con DHCP en
lan2y luego enlan5, replicando lo que hacíalan1. Los tres puertos entregaron el mismo rendimiento deficiente. - Prueba en ambiente aisladoCon el equipo desconectado de la red productiva, se midió su comportamiento básico. Aquí apareció la anomalía que ordenó todo el diagnóstico.
La pista que cambió todo: el ping local
El indicador decisivo
En un ambiente completamente aislado — sin tráfico productivo, sin políticas, sin inspección — el FortiGate no respondía correctamente a un ping en sus puertos internos.
Un ICMP contra la IP de gestión de la interfaz, en la misma red local, es la prueba más elemental que existe. No involucra ruteo, ni NAT, ni inspección de contenido, ni conmutación de sesiones. Si eso falla de forma errática, el problema no está en ninguna capa que el administrador pueda configurar. Está más abajo.
Vale la pena insistir en este punto porque es fácil pasarlo por alto: al perseguir un problema de throughput, uno tiende a medir throughput. El ping parece demasiado básico para entregar información. En realidad es al revés — precisamente porque es básico, una anomalía ahí acota el problema de forma brutal.
Por qué cambiar de puerto LAN no sirve
El FortiGate 50E tiene siete puertos Gigabit Ethernet: dos puertos WAN y cinco puertos de switch. Esa distinción del datasheet no es cosmética. Los cinco puertos internos no son cinco interfaces independientes: cuelgan de un mismo bloque de conmutación interna — el Internal Switch Fabric o ISF — que los interconecta entre sí y con el procesador del equipo.
lan1, lan2 y lan5 equivale a probar tres asientos del mismo auto averiado. Los puertos WAN, en cambio, no dependen de él — y esa fue la vía de escape.Esto explica limpiamente por qué la rotación de puertos no arrojó ninguna mejora, y por qué el resultado era tan consistente. Un daño en un conector individual habría producido un comportamiento distinto en cada puerto. La uniformidad del síntoma era, en sí misma, evidencia de una causa común aguas arriba.
La solución provisoria: WAN2 como LAN
Con el ISF descartado como ruta utilizable, quedaba un recurso: los puertos WAN no dependen de ese bloque. Se reconfiguró wan2 con rol LAN, se habilitó servidor DHCP y se crearon las políticas de firewall correspondientes.
Resultado
Rendimiento completo restablecido. El tráfico de la red local pasó a entrar por wan2, evitando por completo el componente defectuoso, y el cliente recuperó la velocidad contratada mientras se gestionaba el reemplazo del equipo.
La configuración, en términos generales:
# Cambiar el rol de wan2 y asignarle direccionamiento LAN
config system interface
edit "wan2"
set role lan
set alias "LAN-provisoria"
set ip 192.168.10.1 255.255.255.0
set allowaccess ping https ssh
next
end
# Servidor DHCP sobre la nueva interfaz LAN
config system dhcp server
edit 0
set interface "wan2"
set default-gateway 192.168.10.1
set netmask 255.255.255.0
config ip-range
edit 1
set start-ip 192.168.10.50
set end-ip 192.168.10.200
next
end
next
endDespués hay que rehacer las políticas de salida desde wan2 hacia wan1, con NAT habilitado, y revisar que el DNS y las rutas estáticas apunten donde corresponde. Las direcciones del ejemplo son ilustrativas: hay que ajustarlas al direccionamiento real del cliente.
Lo que este parche no resuelve
Conviene ser explícito con el cliente sobre las limitaciones, porque una solución que funciona bien tiende a quedarse más tiempo del que debería:
- Se pierde el segundo enlace WAN. El equipo queda sin posibilidad de redundancia de proveedores ni de SD-WAN entre dos enlaces.
- Un solo puerto para toda la LAN. Toda la red local entra por una boca; el switch aguas abajo pasa a ser un punto único de falla adicional.
- La falla de hardware sigue ahí. Un componente que se degradó puede seguir degradándose, y nada garantiza que el resto del equipo esté sano.
- Documentar el desvío. Un puerto etiquetado WAN2 operando como LAN es exactamente el tipo de configuración que confunde a quien tome el equipo después. Debe quedar registrado.
Qué hacer después del parche
El FortiGate 50E de este caso tenía más de siete años en operación. Tanto la plataforma como la rama de firmware FortiOS 6.2 ya recorrieron su ciclo de vida y se encuentran fuera de soporte, lo que significa dos cosas concretas: no hay reemplazo en garantía ante una falla de hardware, y no hay parches para vulnerabilidades nuevas. Las fechas exactas de cada milestone conviene verificarlas en el portal de ciclo de vida de Fortinet, porque varían según la variante del modelo.
La secuencia razonable, entonces:
- Aplicar el parche para restablecer el servicio — el negocio del cliente no puede esperar al proceso de compra.
- Respaldar la configuración completa del equipo mientras siga operativo.
- Dimensionar el reemplazo con la carga real de hoy, no con la de hace siete años: usuarios concurrentes, ancho de banda contratado, necesidad de inspección SSL y de túneles VPN.
- Planificar la migración con ventana de mantención y plan de rollback.
- Revisar si el resto de la infraestructura está en la misma condición. Un firewall de siete años rara vez es el único equipo en fin de vida en la sala.
La lección de diagnóstico
El factory reset es la línea divisoria del troubleshooting. Todo lo que sobrevive a una configuración de fábrica ya no es configuración. Llegar temprano a ese punto — y probar después el comportamiento más elemental posible, como un ping en red aislada — ahorra días de perseguir hipótesis de software en un problema que nunca lo fue.
Preguntas frecuentes
¿Por qué internet funciona lento solo detrás del FortiGate?
Si al medir directamente contra el ISP se obtiene el 100% de la velocidad contratada y al pasar por el firewall el rendimiento cae, el problema está en el equipo o en el enlace físico hacia él. Las causas más frecuentes son negociación de velocidad y dúplex incorrecta, cables o puertos dañados, perfiles de inspección demasiado exigentes para el hardware, o una falla del switch interno. Las primeras tres se descartan con pruebas de configuración; la última se manifiesta cuando el problema persiste incluso con la configuración de fábrica.
¿Cómo sé si el problema es de hardware o de configuración?
La prueba decisiva es restablecer la configuración de fábrica y volver a medir con el equipo aislado, sin perfiles de seguridad ni reglas adicionales. Si el bajo rendimiento se mantiene en factory default, se repite en todos los puertos LAN y sobrevive a un cambio de firmware, la configuración deja de ser una explicación posible. En ese punto la sospecha razonable es hardware.
¿Cambiar de puerto LAN soluciona el problema en un FortiGate 50E?
No, si la falla está en el switch interno. El FortiGate 50E tiene siete puertos GE: cinco de switch y dos WAN. Los cinco puertos internos dependen del mismo bloque de conmutación, de modo que moverse de lan1 a lan2 o lan5 mantiene el tráfico pasando por el mismo componente defectuoso y reproduce el mismo síntoma.
¿Se puede configurar el puerto WAN2 como interfaz LAN?
Sí. En FortiOS se puede cambiar el rol de la interfaz de WAN a LAN, asignarle una dirección IP, habilitar servidor DHCP y crear las políticas correspondientes. Es una medida provisoria válida para restablecer el servicio cuando los puertos internos fallan, pero deja al equipo con un solo enlace WAN disponible y sin redundancia.
¿Actualizar el firmware de FortiOS soluciona los problemas de rendimiento?
Puede hacerlo cuando la causa es un defecto de software conocido, y por eso vale la pena intentarlo temprano en el diagnóstico. Pero si el rendimiento sigue igual después de la actualización, el firmware queda descartado como causa y el resultado orienta la investigación hacia el hardware.
¿El FortiGate 50E todavía tiene soporte de Fortinet?
El FortiGate 50E es una plataforma de generación E que ya recorrió su ciclo de vida y se encuentra en fin de soporte, al igual que la rama FortiOS 6.2. Un equipo en esa condición no recibe parches de seguridad ni reemplazo en garantía, por lo que ante una falla de hardware la vía razonable es reemplazarlo por un modelo vigente. Las fechas exactas deben verificarse en el portal de ciclo de vida de Fortinet.
¿Qué significa que la descarga esté lenta pero la subida normal?
La asimetría entre descarga y subida apunta habitualmente a la capa física: negociación de dúplex incorrecta, errores de CRC en el puerto, o cableado defectuoso. Es la primera hipótesis a perseguir. Si la asimetría sobrevive al cambio de cable, al forzado de velocidad y al restablecimiento de fábrica en todos los puertos, la sospecha se traslada al componente que todos esos puertos comparten.
¿Su firewall está entregando menos de lo que debería?
En SEiT diagnosticamos y administramos infraestructura de red y seguridad perimetral para empresas en Chile desde 2007, con certificación ISO/IEC 27001:2022. Si tiene un equipo con comportamiento errático, o simplemente quiere saber si su infraestructura sigue dentro de soporte, conversemos.
O escríbanos a comercial@seit.cl · +56 2 2581 2370
Últimas Entradas
¿que tu empresa no se detenga?
Estamos a un clic de distancia. Descubre cómo nuestras soluciones pueden revolucionar procesos y proteger tu infraestructura. Completa el formulario y juntos haremos realidad tus objetivos. Nos apasiona la transformación digital y estamos aquí para sostener tus procesos y plataformas.
