Instalé un nuevo Sonicwall en el DC del proveedor de MPLS, lo hice funcionar por suerte pero no tengo idea de POR QUÉ funciona así

Instalé un nuevo Sonicwall en el DC del proveedor de MPLS, lo hice funcionar por suerte pero no tengo idea de POR QUÉ funciona así

Me pone nervioso dejar el dispositivo así porque no tiene sentido para mí POR QUÉ funciona así.

Instalamos el nuevo Sonicwall para reemplazar un Cisco ASA más antiguo.

Acabo de hacer la configuración básica, usando las mismas IP del ASA: (inventando las IP aquí pero usando las mismas subredes)

LAN X0: 172.16.5.2/30

X1 WAN: 216.40.5.100/30

Luego agrego una ruta para una de sus subredes internas...

10.1.0.0/16 a la puerta de enlace 172.16.5.1 en el puerto LAN X0 (172.16.5.1 es el enrutador del proveedor MPLS, que tiene una ruta que va a la red 10.1.0.0)

Entonces, configuré esto. No funciona. La red 10.1.0.0 no puede hacer ping a Sonicwall y no puede acceder a Internet, Sonicwall no puede hacer ping a la red 10.1.0.0.

AHORA, solo para probar algo, encendí el puerto X2 en Sonicwall, lo puse en modo Puente de capa 2 y lo conecté al puerto LAN X0. No conecto nada a X2, solo habilito el puente: X0 LAN y X1 WAN siguen siendo los únicos puertos que se utilizan. Por arte de magia, todo empieza a funcionar. Agregué rutas adicionales para más redes internas, configuré las reglas necesarias de firewall/nat, todo funciona al 100%.

Si apago el puerto X2 y quito el puente, todo se cae.

Estoy completamente perplejo en cuanto a por qué agregar este puente, que aparentemente es inútil, haría que las cosas funcionaran aquí. Eso sí, no había ninguna configuración de puente en Cisco. He configurado muchos Sonicwall y nunca tuve una situación similar.

Aquí hay una captura de pantalla delinterfaces.

Respuesta1

No mencionas cómo está configurado tu Firewall. Normalmente, X0 es LAN y X1 es WAN. De forma predeterminada, el tráfico de X1 a X0 está bloqueado. Pero no creo que ese sea el problema.

El 10.1.0.0/16 no tiene una interfaz enrutable a 172.16.5.1 en Sonicwall. las máscaras de subred lo impiden. Incluso si agrega una ruta estática, aún necesitará una interfaz de enrutamiento en la subred 10.1.xx para poder realizar la ruta de salida. de lo contrario, el SW probablemente reenviará los paquetes a la interfaz X1.

En lo que respecta al puente, tampoco tengo idea de por qué funciona. ¿Parece que podría estar explotando un error en el puente?

Creo que podría estar muy desviado con esta respuesta. Lo borraré si lo soy...

Respuesta2

Según la documentación de SonicWALL sobre el puente de Capa 2:

La derivación de puente de capa 2 es un relé de derivación de interfaz física X0-X1 actualmente implementado en SonicWALL NSA E7500. Esta característica a veces se conoce como "fallo al cablear", lo que significa que la conexión LAN-WAN vuelve a una conexión directa si el dispositivo SonicWALL experimenta una falla de hardware o software. Cuando el relé de derivación está cerrado, el tráfico de la red fluye sin obstáculos entre las interfaces X0 y X1. Cuando el relé de derivación está abierto, el tráfico de red lo maneja SonicOS Enhanced ejecutándose en el dispositivo SonicWALL.

Entonces, parece que al conectar la interfaz e incluir una interfaz fallida (X2 no está conectado a nada), está funcionando porque pasa por alto los controles del sistema operativo mejorado de SonicOS y pasa directamente por el cable.

Dicho esto, parece que esto podría verse como un paso elaborado de solución de problemas para ver que algo en la configuración está bloqueando las conexiones en la configuración normal. ¿Verificar las reglas del firewall?

información relacionada