El interruptor administrado no se puede contactar cuando está conectado a Fortigate 30E

El interruptor administrado no se puede contactar cuando está conectado a Fortigate 30E

Acabo de comprar un UniFi US-8 (conmutador PoE administrado de 8 puertos) y estoy intentando configurarlo, pero no consigo que el controlador UniFi vea el dispositivo; el controlador simplemente dice "No se encontraron dispositivos".

Mi configuración de red actual es:

Módem/enrutador ISP ( 192.168.0.1/24) -> Fortigate 30E ( 192.168.1.1/24) -> Escritorio ( 192.168.1.10/24)

El controlador UniFi está instalado en mi escritorio ( 192.168.1.10/24).

Si elimino el Fortigate ate de la ecuación:

  1. Reconfigurar el módem/enrutador de mi ISP para que esté en la 192.168.1.0/24red
  2. Conecte el conmutador y mi escritorio cada uno a un puerto LAN en el módem/enrutador

Luego puedo contactar (ping/ssh) el conmutador desde mi escritorio ( 192.168.1.10/24), y el controlador que se ejecuta en mi escritorio ve el conmutador y puede "adoptarlo".

Sin embargo, si vuelvo a poner la puerta Fortigate en la ecuación:

  1. Módem/enrutador ISP en la 192.168.0.0/24red
  2. Fortigate 30E en la 192.168.1.0/24red (puerto WAN conectado a un puerto LAN en el enrutador ISP)
  3. Escritorio y conmutador conectados a los puertos LAN del Fortigate

Mi escritorio ya no puede ver el interruptor. Al observar el inventario de dispositivos en Fortigate, parece que el conmutador obtiene una concesión de DHCP para 192.168.1.12/24, pero solo puedo acceder a esta dirección si conecto una computadora portátil directamente al conmutador y configuro la computadora portátil para que esté en la 192.168.1.0/24red.

¿Fortigate está haciendo algo para bloquear el tráfico hacia el conmutador? Si es así, ¿qué puedo hacer para permitir que el tráfico fluya?

Como referencia, el resultado del show system interfacecomando se encuentra a continuación:

FWF30E********** # show system interface
config system interface
    edit "wan"
        set vdom "root"
        set ip 192.168.0.10 255.255.255.0
        set allowaccess ping https http fgfm
        set type physical
        set scan-botnet-connections block
        set role wan
        set snmp-index 1
    next
    edit "modem"
        set vdom "root"
        set mode pppoe
        set type physical
        set snmp-index 2
    next
    edit "ssl.root"
        set vdom "root"
        set type tunnel
        set alias "SSL VPN interface"
        set snmp-index 3
    next
    edit "wifi"
        set vdom "root"
        set type vap-switch
        set role lan
        set snmp-index 5
    next
    edit "guestwifi"
        set vdom "root"
        set ip 192.168.11.1 255.255.255.0
        set allowaccess ping https ssh http
        set type vap-switch
        set device-identification enable
        set fortiheartbeat enable
        set role lan
        set snmp-index 7
    next
    edit "internal"
        set vdom "root"
        set ip 192.168.1.1 255.255.255.0
        set allowaccess ping https ssh http fgfm capwap
        set broadcast-forward enable
        set type switch
        set device-identification enable
        set fortiheartbeat enable
        set role lan
        set snmp-index 6
    next
    edit "lan"
        set vdom "root"
        set type hard-switch
        set stp enable
        set role lan
        set snmp-index 4
    next
end

Respuesta1

Creo que resolví el problema; a continuación están mis notas:

Noté que si reinicio el firewall, poco antes de que termine de iniciarse, el conmutador comienza a adoptar. Tan pronto como el firewall termina de iniciarse, el conmutador pierde la conexión. Tampoco puedo comunicarme con ningún otro dispositivo en mi subred.

Si elimino "lan" de los miembros del conmutador de software "interno" predeterminado, el conmutador (aún predeterminado en 192.168.1.20/24) se conecta a mi escritorio (y puedo conectarme a otros dispositivos en la red 192.168.1.0/24). ), pero pierdo la conexión a Internet. El firewall crea automáticamente una nueva interfaz de conmutador de hardware llamada "lan", compuesta por las 4 interfaces LAN físicas como interfaces miembro.

Para volver a conectarme al firewall desde mi escritorio, tuve que iniciar sesión en 192.168.1.99 (la IP del firewall) con mi teléfono (que está en la red wifi interna 192.168.1.0/24) y configurar la nueva puerta de enlace "lan". IP en 192.168.10.99/24, luego configuré mi computadora para que esté en la nueva subred (la configuré en 192.168.10.10/24, con puerta de enlace 192.168.10.99). Pero ahora, debido a que mi escritorio está en una subred diferente, pierdo la conexión al conmutador.

Desde mi escritorio (192.168.10.10/24, puerta de enlace 192.168.10.99), creé una nueva regla de firewall en la "política IPv4" para permitir todo el tráfico de "lan" a "wan". Esto me volvió a conectar a Internet, pero como era de esperar, no puedo hacer ping ni SSH al conmutador ni a ningún otro host en la red 192.168.1.0/24. Confirmé esto volviendo a configurar mi escritorio en la red 192.168.1.0/24 (puerta de enlace 192.168.1.99), lo que interrumpe mi Internet, pero puedo hacer ping/SSH a otros hosts en esa subred una vez más y el conmutador se vuelve a conectar.

Dado que sé que el conmutador tiene por defecto 192.168.1.20/24 si no obtiene una concesión DHCP, encendí el servidor DHCP para la interfaz "lan" y finalmente se le asignó una IP al conmutador y se conectó a mi escritorio.

Ahora el siguiente problema era descubrir cómo permitir que los dispositivos en la interfaz "interna" (dispositivos wifi) se comunicaran con dispositivos en la interfaz "lan" (dispositivos cableados). Para hacer esto, configuro 2 políticas IPv4: permitir todo el tráfico de "lan" a "interno" y permitir todo el tráfico de "interno" a "lan".

Esta solución logra el resultado deseado, pero no estoy seguro de que sea la forma más segura (o la "mejor") de lograrlo.

información relacionada