Sonicwall VPN ne fonctionne que pour un sous-réseau distant

Nous avons acquis une petite entreprise qui utilise un pare-feu Sonicwall PRO 1260 et j'ai configuré un tunnel VPN Site-to-Site depuis Sonciwall vers notre pare-feu Cisco ASA. Derrière le pare-feu Cisco ASA, j'ai 8 sous-réseaux différents. J'ai configuré la connection VPN sur Sonicwall pour utiliser un groupe d'objects d'adresse qui contient tous les sous-réseaux requirejs.

Le tunnel VPN de Sonicwall à Cisco ASA établit bien et j'ai une connectivité complète du site distant vers le «sous-réseau 1». À partir du «sous-réseau 2» (et de tous les autres), le seul trafic qui passe par le réseau distant est ICMP (ping), http et https.

Je connais les règles d'access de ces cris, mais j'ai passé des heures à couler sur le Sonicwall et je ne trouve aucune règle d'access qui empêcherait tous les trafics, à l'exception des services mentionnés ci-dessus. Le Sonicwall crée automatiquement des règles d'access à partir de LAN> VPN et VPN> LAN qui disent «autoriser tout hôte, tout service, tout le time» – ces règles ne peuvent pas être modifiées, supprimées ou désactivées (uniquement en supprimant le VPN).

J'ai exactement la même configuration pour 5 autres sites distants utilisant le VPN de site à site, en train de se connecter au même ASA de Cisco et tout fonctionne bien, mais ces sites utilisent des pare-feu Fortigate, donc je suis sûr que cela est lié au Sonicwall.

Question 1: Quelqu'un at-il eu le même problème et comment l'avez-vous résolu?

Question 2: Quelle command dois-je exécuter via CLI sur Sonicwall pour get une sortie de text intégral de la configuration en cours d'exécution?

Merci d'avance pour toute aide.

Est-ce que vous avez chacun des sous-réseaux en question défini comme sous-réseaux VPN dans la configuration d'object réseau Sonicwall? Si vous les avez classés LAN ou WAN, vos règles "LAN to VPN" ne s'appliqueront pas à eux même si vous les avez définis dans le tunnel VPN. Je ne sais pas si cela s'applique au model que vous avez (les nôtres sont TZ17 / 8/90 et 3060, mais si cela fonctionne sur le SonicOS, je pense qu'il le fait)

Merci pour les commentaires Kevin, j'avais pensé à cela, mais j'ai effectivement testé l'utilisation de l'Objet d'adresse pour le sous-réseau qui fonctionnait en classant l'object comme un object LAN ou WAN ou VPN, mais cela ne faisait aucune différence, cela fonctionnait dans tous les cas. Il semblerait que les règles VPN auto-ajoutées pour le VPN du site au site ignorent ce que vous classz manuellement l'object.

Une longue histoire, ce test m'a amené à remettre en question de plus en plus si le Sonicwall était en fait le problème – en fin de count, ce n'était pas le cas. Après beaucoup, Cisco ASA à l'autre extrémité est géré par un service d'hébergement et donc hors de mon contrôle. Après avoir regardé la configuration pour l'ASA, nous avons constaté que le génie qui a ajouté les règles pour l'autre extrémité de la connection VPN avait placé une règle d'access après une règle «nier tout». Déplacement de la règle d'access avant le refus de toutes les règles a résolu le problème immédiatement.