Índice
- 1 Descripción
- 2 Solución
- 2.1 1) Configuración de la interfaz.
- 2.2 2) Configuración de host de confianza.
- 2.3 3) MTU a lo largo del camino.
- 2.4 4) Puertos de acceso de administración.
- 2.5 5) admin-server-cert (solo para versiones 5.6 y superiores).
- 2.6 6) La IP virtual existente anula los puertos HTTP o HTTPS del administrador.
- 2.7 7) Verifique si alguna política local está configurada para denegar el acceso en la interfaz relacionada.
- 2.8 8) Reinicie el demonio HTTPS.
Descripción
En algunos casos, es posible llegar a la unidad FortiGate a través de un Ping, Telnet o SSH, pero no a través de la GUI de administración web. Este artículo analiza algunas posibles causas de un acceso a la GUI que no funciona.
Solución
1) Configuración de la interfaz.
El acceso a la GUI, HTTP y/o HTTPS, debe estar habilitado en la interfaz.
Comandos CLI:
# config system interfaceedit <interface name>set allowaccess ping http httpsend
Permitir configuraciones de acceso posibles: PING, HTTP, HTTPS, TELNET, SSH, FGFM (se requiere FGFM para el acceso a FortiManager).
2) Configuración de host de confianza.
Si se configuran ‘hosts confiables’, la dirección IP de la computadora utilizada para el acceso a la GUI debe permitirse como ‘host confiable’.
Se puede permitir una subred completa como ‘host de confianza'».
De forma predeterminada, la configuración del host de confianza no está configurada y el acceso administrativo no está restringido a ninguna dirección IP de usuario específica.
Ejemplo de configuración de host de confianza:
# show
# config system admin
edit «admin-test»
set trusthost1 10.10.10.1 255.255.255.255
set trusthost2 192.168.0.0 255.255.0.0
set vdom «root»
# config dashboard-tabs
…
Cambiar la configuración del host de confianza:
# config system admin
edit <admin user>
set trusthost <1 to 10> <ip address>/<mask>
set ip6-trusthost <1 to 10> <ip6 address>/<mask>
La configuración del host de confianza es por usuario administrador y es válida para todos los tipos de acceso.
Ejemplo.
Si se confía en un usuario para el acceso a través de SSH, también se confía en el acceso HTTP o HTTPS.
3) MTU a lo largo del camino.
Después de los primeros paquetes de sincronización y protocolo de enlace, los paquetes HTTP y HTTPS de la interfaz gráfica de usuario del administrador web pueden superar los 1500 bytes.
Ejemplo.
Cuando una interfaz de red FortiGate está conectada a un segmento de red que admite paquetes de tamaño extendido.
Para Telnet o SSH, los paquetes suelen tener un tamaño más pequeño.
Para poder usar la GUI de administración web, se debe permitir la fragmentación en ciertos puntos de la infraestructura de la red (puntos en los que una trama gigante llega a un segmento de red que no lo admite), o se deben permitir tramas gigantes a lo largo de la red. todo el camino de la comunicación.
Nota sobre las tramas gigantes: las tramas gigantes son paquetes que superan el tamaño estándar de 1500 unidades de transmisión máxima (MTU). Las tramas gigantes aumentan las velocidades de transferencia de datos al transportar más datos por trama, lo que reduce la sobrecarga de los encabezados.
Todas las redes que transportan tramas gigantes deben tener unidades de red que admitan tramas gigantes.
De lo contrario, las tramas gigantes se eliminarán cuando lleguen a dispositivos de red que no las admitan.
4) Puertos de acceso de administración.
De forma predeterminada, para el inicio de sesión de administrador a través de la GUI, el puerto HTTPS está configurado en 443 y el puerto HTTP en 80.
Si se cambia esa configuración predeterminada, no será posible acceder a la GUI sin especificar el puerto personalizado utilizado al final de la URL.
Para verificar qué puertos HTTPS/HTTP están configurados para acceso de administrador:
# show full | grep admin-port
set admin-port 80
TestFGT # show full | grep admin-sport
set admin-sport 443
En caso de que se hayan cambiado los puertos predeterminados, acceda directamente a la GUI utilizando el puerto específico que está definido actualmente: http(s)://<address_of_appliance>:<custom port>.
Por ejemplo: http://192.168.0.101:222 donde 222 es el puerto no predeterminado utilizado para acceder a la GUI a través de HTTP.
Si es necesario cambiar los puertos a un valor nuevo o al valor predeterminado, use la siguiente sintaxis para el acceso HTTP:
# sistema de configuración globalestablecer admin-port <integer> end
Mientras que para el acceso HTTPS, utilice la sintaxis:
# config system global
set admin-sport <integer> end
5) admin-server-cert (solo para versiones 5.6 y superiores).
Habilite la siguiente depuración e intente acceder a la GUI nuevamente:
# diagnose debug application httpsd -1
# diagnose debug enable
Si la salida coincide con lo siguiente:
[httpsd 1746 – 1552998712 error] log_error_core[439] —
[Tue 19 12:31:52 2019] [crit] Can’t open certificate file /tmp/admin_server.crt, nor /ssl/certs//tmp/admin_server.crt
[httpsd 1749 – 1552998714 error] log_error_core[439] —
[Tue 19 12:31:54 2019] [crit] Can’t open certificate file /tmp/admin_server.crt, nor /ssl/certs//tmp/admin_server.crt
[httpsd 1752 – 1552998716 error] log_error_core[439] —
[Tue 19 12:31:56 2019] [crit] Can’t open certificate file/tmp/admin_server.crt, ni /ssl/certs//tmp/admin_server.crt
Proceda con lo siguiente:
# config sys global
set admin-server-cert Fortinet_Factory end
6) La IP virtual existente anula los puertos HTTP o HTTPS del administrador.
Cuando una IP virtual (VIP) tiene la misma dirección IP de la interfaz de FortiGate y reenvía los mismos puertos utilizados para el acceso HTTP/HTTPS (por ejemplo, 80 o 443), la VIP anulará el acceso administrativo.
Esto debe eliminarse o cambiarse para que no se superponga con los puertos HTTP/HTTPS de FortiGate.
Esto se puede verificar consultando la lista VIP en FortiGate (Política y objetos -> IP virtuales) o ejecutando el flujo de depuración.
7) Verifique si alguna política local está configurada para denegar el acceso en la interfaz relacionada.
#conf firewall local-in-policy
# sh full
edit 1
set uuid 794fef20-38ce-51ec-b995-89227f742faa
set intf «wan1»
set srcaddr «all»
set srcaddr-negate disable
set dstaddr-negate disable
set action deny
set service «HTTPS»
set service-negate disable
set schedule »
set status enable
set comments »
next
end
8) Reinicie el demonio HTTPS.
En caso de que ninguno de los procesos anteriores solucione el problema, intente reiniciar HTTPS Daemon.
# dia sys process pidof httpsd
– Tenga en cuenta el primer ID de proceso enumerado (este es el proceso principal).
# dia sys kill 11 XX <—– Agregue el ID del proceso recopilado en el paso 1.
– Esto reinicia httpsd.
¿Te ha resultado útil??
0 / 0
Hola, somos Mila Jiménez y César Sánchez. Dos apasionados de la ciberseguridad con muchos años de experiencia. Hemos trabajado en muchas empresas del mundo TI y ahora nos apetece compartir nuestro conocimiento con cualquiera que lo necesite.
¡Si te gusta nuestro contenido puedes invitarnos a un café AQUÍ!