Wir haben ein kleines Unternehmen übernommen, das eine Sonicwall PRO 1260-Firewall verwendet, und ich habe einen Site-to-Site-VPN-Tunnel von der Sonciwall zu unserer Cisco ASA-Firewall konfiguriert. Hinter der Cisco ASA-Firewall habe ich 8 verschiedene Subnetze. Ich habe die VPN-Verbindung auf der Sonicwall so konfiguriert, dass sie eine Adressobjektgruppe verwendet, die alle erforderlichen Subnetze enthält.
Der VPN-Tunnel von Sonicwall zu Cisco ASA funktioniert einwandfrei und ich habe vom Remote-Standort aus volle Konnektivität zu „Subnetz 1“. Von „Subnetz 2“ (und allen anderen) gelangt nur ICMP (Ping), http und https zum Remote-Netzwerk.
Ich weiß, das schreit geradezu nach „Zugriffsregeln“, aber ich habe Stunden damit verbracht, die Sonicwall zu durchforsten und kann keine Zugriffsregeln finden, die dazu führen würden, dass der gesamte Datenverkehr außer den oben genannten Diensten blockiert wird. Die Sonicwall erstellt automatisch Zugriffsregeln von LAN > VPN und VPN > LAN, die besagen, dass „jeder Host, jeder Dienst jederzeit zugelassen wird“ – diese Regeln können nicht geändert, gelöscht oder deaktiviert werden (nur durch Entfernen des VPN).
Ich habe genau die gleiche Konfiguration für 5 andere Remote-Sites eingerichtet, die Site-to-Site-VPN verwenden, eine Verbindung zur gleichen Cisco ASA herstellen und alles funktioniert einwandfrei. Diese Sites verwenden jedoch Fortigate-Firewalls, daher bin ich sicher, dass dies mit der Sonicwall zusammenhängt.
Frage 1: Hat jemand das gleiche Problem gehabt und wie haben Sie es gelöst?
Frage 2: Welchen Befehl muss ich über die CLI auf der Sonicwall ausführen, um eine vollständige Textausgabe der laufenden Konfiguration zu erhalten?
Vielen Dank im Voraus für jede Hilfe.
Antwort1
Haben Sie jedes der betreffenden Subnetze in der Sonicwall-Netzwerkobjektkonfiguration als VPN-Subnetze definiert? Wenn Sie sie als LAN oder WAN klassifiziert haben, gelten Ihre „LAN zu VPN“-Regeln nicht für sie, selbst wenn Sie sie im VPN-Tunnel definiert haben. Ich bin nicht sicher, ob dies auf Ihr Modell zutrifft (unsere sind TZ17/8/90 und 3060s, aber wenn SonicOS darauf läuft, denke ich, dass es zutrifft).
Antwort2
Danke für die Kommentare, Kevin. Ich hatte daran gedacht, aber tatsächlich mit dem Adressobjekt für das Subnetz getestet, was funktionierte, indem das Objekt wiederum als LAN-, WAN- oder VPN-Objekt klassifiziert wurde, aber es machte keinen Unterschied, es funktionierte in allen Fällen. Es scheint, dass die automatisch hinzugefügten VPN-Regeln für das Site-to-Site-VPN nicht berücksichtigen, als was Sie das Objekt manuell klassifizieren.
Kurz gesagt, dieser Test ließ mich immer mehr daran zweifeln, ob die Sonicwall tatsächlich das Problem war – am Ende war sie es nicht. Schließlich wird die Cisco ASA am anderen Ende von einem Hosting-Dienst verwaltet und liegt daher außerhalb meiner Kontrolle. Nachdem wir uns die Konfiguration für die ASA angesehen hatten, stellten wir fest, dass das Genie, das die Regeln für das andere Ende der VPN-Verbindung hinzugefügt hatte, eine Zugriffsregel nach einer „Alles verweigern“-Regel platziert hatte. Das Verschieben der Zugriffsregel vor die „Alles verweigern“-Regel löste das Problem sofort.