Cómo resolver fallos de Scan‑to‑Folder entre VLANs con SonicWall

Problema

En oficinas pequeñas o sucursales, es frecuente separar dispositivos críticos (cámaras, impresoras, equipos médicos) en VLAN distintas y colocar un firewall de perímetro como puerta de enlace. Cuando una impresora multifunción debe escanear a una carpeta compartida en un PC ubicado en otra VLAN, el proceso se bloquea: el trabajo queda en “Resending…”, termina con “TX Incomplete” o simplemente no aparece la carpeta.

El síntoma típico es que ICMP funciona entre subredes pero SMB (puertos 445/139) es rechazado. El cliente ve “Network path not found” al intentar acceder a \\IP\share. La causa suele estar en la configuración del firewall, reglas de zona o políticas de inspección que impiden el tráfico de capa 4/7 entre VLAN.

Causa

1. Reglas de acceso implícitas insuficientes
   Los firewalls de próxima generación, incluido SonicWall, crean reglas implícitas “Deny‑All” entre zonas. Si no se define explícitamente una regla que permita tráfico SMB entre LAN y WLAN (o entre VLAN específicas), el paquete llega al firewall, es inspeccionado y descartado.

2. Inspección profunda (DPI) que rompe la negociación SMB
   Cuando la inspección de AV/IPS está activa para una regla, el motor puede modificar o bloquear paquetes SMB, sobre todo si la firma de “SMB signing” o “SMB encryption” no coincide con la política. El resultado es un “TX Incomplete” en la impresora.

3. Política de “Inter‑VLAN routing” deshabilitada
   En algunos modelos, la opción “Enable Inter‑VLAN Routing” o “Allow LAN‑to‑LAN” está desactivada por defecto. El firewall sigue funcionando como puente, pero no enruta tráfico entre subredes internas.

4. Configuración de zona errónea
   Colocar la impresora en la zona “LAN” y los PCs Wi‑Fi en la zona “WLAN” sin habilitar “Allow LAN‑to‑WLAN” genera un filtro de capa 3 que permite ping (ICMP) pero bloquea puertos de aplicación.

5. Políticas de seguridad del host
   Aunque el firewall permita el tráfico, el firewall de Windows o software de AV puede negar conexiones entrantes de subredes no locales, especialmente si el perfil de red está marcado como “Public”.

Solución

1. Verificar y habilitar el enrutamiento inter‑VLAN

• Acceder a la interfaz de SonicWall → Network → Interfaces.
• Confirmar que cada VLAN tiene una interfaz asignada y que la casilla Enable Inter‑VLAN Routing (o similar) está marcada.
• Guardar y aplicar cambios.

2. Crear reglas de acceso específicas para SMB

En la sección Firewall → Access Rules crear dos reglas:

• Source: la subred de la impresora (ej. 192.168.0.0/24).
• Destination: la subred del PC (ej. 192.168.20.0/24).
• Service: seleccionar “SMB” o crear un objeto con puertos 445, 139.
• DPI: desactivar AV/IPS para evitar que la inspección rompa la negociación.

3. Desactivar inspección para tráfico SMB (opcional pero recomendado)

Si la política de seguridad de la empresa lo permite, crear una Security Service Exclusion para el rango de IP de la impresora, excluyendo AV/IPS. Esto reduce la latencia y elimina falsos positivos.

4. Revisar la configuración del host Windows

• Desactivar temporalmente el firewall de Windows para confirmar que el problema está en el perímetro.
• Si funciona, crear una regla de entrada que permita SMB desde la subred de la impresora:

netsh advfirewall firewall add rule name="Allow SMB from Printer VLAN" dir=in action=allow protocol=TCP localport=445 remoteip=192.168.0.0/24

• Asegurarse de que la carpeta compartida tiene permisos Full Control para “Everyone” o para el usuario de escaneo configurado.

5. Validar la ruta de escaneo en la impresora

• En la consola web de la MFP, establecer la ruta como \\192.168.20.67\Scans (usar IP en vez de nombre NetBIOS).
• Verificar que el usuario y la contraseña coinciden con una cuenta local del PC que tiene permiso de escritura.

6. Probar conectividad sin DPI

• Desde un cliente en la VLAN de la impresora, ejecutar:

smbclient //192.168.20.67/Scans -U usuario

• Si la conexión se establece, el firewall está pasando el tráfico correctamente.

Cuándo aplicar esta solución

• Síntomas: ping entre subredes funciona, pero SMB, LDAP, RDP o cualquier aplicación basada en TCP/UDP específico falla.
• Entornos: oficinas pequeñas, sucursales o laboratorios con una única pieza de hardware que necesita acceder a recursos en otra VLAN (impresoras, cámaras, servidores de backup).
• No aplica: cuando el tráfico está completamente aislado por política de seguridad (por ejemplo, DMZ pública) o cuando la arquitectura usa un router de capa 3 externo que ya gestiona el enrutamiento.

Código

# Añadir regla de firewall en Windows para permitir SMB desde la VLAN de la impresora
netsh advfirewall firewall add rule name="Allow SMB from Printer VLAN" dir=in action=allow protocol=TCP localport=445 remoteip=192.168.0.0/24

# Probar acceso SMB desde Linux (útil para validar sin depender de la impresora)
smbclient //192.168.20.67/Scans -U usuario

Verificación

1. Ping entre ambas subredes → debe responder.
2. Telnet al puerto 445 desde la VLAN de la impresora: telnet 192.168.20.67 445. Conexión establecida indica que el firewall permite el flujo.
3. Acceso a la carpeta desde un PC Windows en la VLAN de la impresora: \\192.168.20.67\Scans. Debe abrirse sin error.
4. Escaneo desde la MFP → la carpeta debe llenarse en menos de 5 s.
5. Revisar los logs de SonicWall → buscar entradas “SMB allowed” y confirmar que no aparecen “Deny” o “Drop”.

Notas adicionales

• Evitar usar nombres NetBIOS en rutas de escaneo cuando el DNS interno no resuelve entre VLAN; la IP siempre funciona.
• Si la política de seguridad requiere inspección, crear una Application Rule que permita SMB sin inspección en lugar de desactivar DPI globalmente.
• En entornos con varios dispositivos de escaneo, agruparlos en una VLAN dedicada y aplicar una única regla de acceso simplifica la gestión.
• Mantener el firmware del SonicWall actualizado reduce falsos positivos de IPS que pueden afectar SMB.
• Cuando se cambie la IP del firewall a la misma subred que la impresora, se elimina la necesidad de enrutamiento inter‑VLAN, pero se pierde la segmentación de seguridad; la solución basada en reglas es más flexible.