Adquirimos una pequeña empresa que utiliza un firewall Sonicwall PRO 1260 y configuré un túnel VPN de sitio a sitio desde Sonciwall a nuestro firewall Cisco ASA. Detrás del firewall Cisco ASA tengo 8 subredes diferentes. He configurado la conexión VPN en Sonicwall para usar un grupo de objetos de dirección que contiene todas las subredes requeridas.
El túnel VPN de Sonicwall a Cisco ASA se establece bien y tengo conectividad total desde el sitio remoto a la 'subred 1'. Desde la 'subred 2' (y todas las demás), el único tráfico que llega a la red remota es ICMP (ping), http y https.
Sé que esto grita 'reglas de acceso', pero he pasado horas revisando Sonicwall y no puedo encontrar reglas de acceso que provoquen que se bloquee todo el tráfico, excepto los servicios mencionados anteriormente. Sonicwall crea automáticamente reglas de acceso desde LAN > VPN y VPN > LAN que dicen "permitir cualquier host, cualquier servicio, todo el tiempo"; estas reglas no se pueden modificar, eliminar ni desactivar (solo eliminando la VPN).
Tengo exactamente la misma configuración para otros 5 sitios remotos que usan VPN de sitio a sitio, me conecto al mismo Cisco ASA y todo funciona bien; sin embargo, esos sitios usan firewalls Fortigate, así que estoy seguro de que esto está relacionado con Sonicwall.
Pregunta 1: ¿Alguien ha experimentado el mismo problema y cómo lo resolvió?
Pregunta 2: ¿Qué comando necesito ejecutar a través de CLI en Sonicwall para obtener un resultado de texto completo de la configuración en ejecución?
Gracias de antemano por cualquier ayuda.
Respuesta1
¿Tiene cada una de las subredes en cuestión definidas como subredes VPN en la configuración del objeto de red de Sonicwall? Si los tiene clasificados como LAN o WAN, entonces sus reglas de "LAN a VPN" no se aplicarán incluso si los tiene definidos en el túnel VPN. No estoy seguro de si esto se aplica al modelo que tienes (los nuestros son TZ17/8/90 y 3060, pero si ejecuta SonicOS, creo que sí)
Respuesta2
Gracias por los comentarios Kevin, había pensado en esto, pero en realidad probé usando el objeto de dirección para la subred que funcionaba clasificando el objeto a su vez como un objeto LAN, WAN o VPN, pero no hizo ninguna diferencia, funcionó en todos los casos. Parecería que las reglas de VPN agregadas automáticamente para la VPN de sitio a sitio ignoran cómo clasifica manualmente el objeto.
En pocas palabras, estas pruebas me llevaron a preguntarme cada vez más si Sonicwall era realmente el problema; al final no lo fue. Después de mucho tiempo, el Cisco ASA en el otro extremo está administrado por un servicio de alojamiento y, por lo tanto, está fuera de mi control. Después de observar la configuración del ASA, descubrimos que el genio que agregó las reglas para el otro extremo de la conexión VPN había colocado una regla de acceso después de una regla de "negar todo". Mover la regla de acceso por delante de la regla de denegar todo resolvió el problema de inmediato.