fragen stichworte

Hinweise zur Konfiguration eines SonicWALL NSA 2400 für die Verwendung von zwei Subnetzen und den L2-Bridge-Modus

Dieser Beitrag ist kein exaktes Duplikat von Konfigurieren des Fernzugriffs auf mehrere Subnetze hinter einem SonicWALL NSA 2400. Ich habe dieses Problem jedoch fast wörtlich. Leider haben wir sogar den SonicWALL-Support bezahlt und werden sogar durch Loops geworfen.

Der Unterschied ist, dass ich einfach den Layer-2-Bridge-Modus verwenden möchte. Kein NAT, kein Routing. Wir möchten, dass die SonicWALL nichts weiter tut, als auf der Leitung zu hören, den gesamten Datenverkehr zu blockieren, mit Ausnahme der Auswahl von UDP- und TCP-Ports, und die zustandsorientierte Überprüfung aller anderen unerwünschten Datenverkehr, z. usw. Die X1-Schnittstelle ist im Subnetz A konfiguriert. Die restlichen verwendbaren IP-Adressen im Subnetz werden Servern zugewiesen, die mit dem Switch am X2-Port (DMZ) verbunden sind.

Bis vor kurzem hat diese Konfiguration gut funktioniert. Jetzt stehen wir jedoch vor einem Problem. Wir verwendeten unser gesamtes Subnetz A und benötigten mehr, sodass uns ein anderes/28-Subnetz zugewiesen wurde. Die Server, die in diesem Subnetz ausgeführt werden, sind an Port X2 an denselben Switch angeschlossen, und es werden keine VLANs verwendet. Wir haben also zwei Netzwerke in derselben Broadcast-Domäne. Dies schien in Ordnung zu sein, da SonicWALL nur Paketinspektionen durchführen sollte und sich nicht um den Routing-Aspekt des Datenverkehrs kümmern sollte. Der Router des Netzwerks (den wir nicht steuern können) an Port X1 muss sich um das Routing zwischen den beiden Subnetzen kümmern, die sich tatsächlich in derselben Broadcast-Domäne befinden.

Im Internet funktioniert diese Konfiguration gut. Wir können sowohl auf das Subnetz A als auch auf das Subnetz B zugreifen. Es wird zu einem Problem, wenn wir wollen, dass die beiden Netzwerke miteinander kommunizieren. Wir haben erwartet, dass die beiden Netzwerke den Router auf der anderen Seite der SonicWALL verwenden, um miteinander zu kommunizieren, aber ich habe bewiesen, dass Pakete nicht an der SonicWALL vorbeikommen. Es gibt keine Firewall-Protokolle, die darauf hinweisen, dass die Kommunikation aufgrund von Regeln abgebrochen wird. Wenn ich eine Paketerfassung auf der SonicWALL durchführe, kann ich stattdessen feststellen, dass die Pakete an Port X2 eingehen und nicht weitergeleitet werden. Der Status sagt einfach "Received" (was seltsamerweise nicht als gültiger Status in einer beliebigen Dokumentation gefunden werden kann (die Dokumentation besagt, dass "DROPPED" für den Datenverkehr aufgrund einer Firewall-Regel gilt)).

Der Support hat mir das genaue Dokument geschickt, auf das in dem obigen Beitrag verwiesen wird. Dies trifft jedoch nicht auf diese Situation zu. Nachdem ich tagelang mit dem mehr als schwierigen Support gesprochen hatte, wurde mir schließlich vorgeschlagen, nur noch eine statische Route hinzuzufügen:

Quelle: Any, Dest: Subnetz B, Gateway: 0.0.0.0, Schnittstelle X2.

Die aktuelle Routingtabelle enthält nur die Standardelemente, die sie selbst hinzufügt. Wenn Sie also nichts über SonicWALL wissen, sagen Sie mir, ob das Hinzufügen der obigen statischen Route für jeden sinnvoll ist. Die aktuelle Tabelle ist:

Quelle: Any, Dest: Subnet A-Gateway, Gateway: 0.0.0.0, Schnittstelle X1. Quelle: Alle, Ziel: Subnetz A, Gateway: 0.0.0.0, Schnittstelle X1. Quelle: Alle, Ziel: Alle, Gateway: Subnetz A-Gateway, Schnittstelle X1.

Es kommt mir seltsam vor, dass keiner der Werte bereits X2 ist. Ich habe das Gefühl, dass die Tatsache, dass das Subnetz-A-Gateway der einzige Grund ist, aus dem der Datenverkehr aus dem Subnetz A kommt, aber dann macht es keinen Sinn, wie es zurückkommt, da das Interface X2 verlassen werden sollte und in der obigen Tabelle X1 aufgelistet ist. Interessant ist auch, dass das Subnetz B mit dem Internet kommunizieren kann, was meiner Meinung nach der letzten Regel entspricht. Das Gateway von Subnetz A und B hat dieselbe MAC-Adresse: Es muss also nur ein Zufall sein, dass es funktioniert. Trotzdem macht es keinen Sinn, wie der Verkehr aus dem Internet zu einem der beiden Subnetze führt.

antworten

Es stellt sich heraus, dass niemand mein Problem lösen konnte. Ich habe zwei Monate lang mit dem SonicWALL-Support gesprochen und erhielt nur "im Dunkeln geschossene" Lösungen ". Sie machten deutlich, dass sie die von ihnen unterstützten Geräte nicht verstanden und gaben mir unannehmbare Lösungen. Es war ihnen egal, was ich über ihre inakzeptablen Lösungen dachte, denn alles, was sie taten, war, sie erneut zu empfehlen. Es gibt keine Emulationssoftware für diese Produkte (zumindest Cisco hat Packet Tracer) und sie sind ziemlich teuer. Daher gab es keine Möglichkeit, ihre lächerlichen Lösungen zu testen, abgesehen von dem kleinen Zeitrahmen, den ich während eines geplanten Ausfalls immer wieder auf dem Live-Server hatte -Zeit. Sie haben das auch nicht respektiert und würden mich am Montag anrufen und um Zugang zur SonicWALL bitten. Sie schienen verwirrt zu sein, als ich absolut nicht sagte.

Schlechter Support für Unternehmensprodukte, die ich je hatte, vor allem weil es nicht frei war, so schlecht behandelt zu werden. Wir haben den Fall aufgegeben und ich habe einen sehr hohen Verdacht, was ich gefunden habe, ist ein Fehler in ihrer Software. Es wäre so viel besser gewesen, wenn sie das zugegeben hätten, anstatt mich zwei Monate herumzureißen.

Lösung: Wir haben die zwei Subnetze für ein großes Netzwerk gespeichert, das die größere Anzahl von Hosts unterstützen könnte.

alter Beitrag, aber einen guten Kommentar bezüglich des Status "Empfangen" im Paketmonitor wert. Zu diesem Status konnte ich in der Dokumentation zu Sonicwall/Dell nichts finden. Endlich bekam ich eine Technik um es zu erklären, habe eigentlich eine kurze Beschreibung ...

Received bedeutet, dass das Paket von der Schnittstelle verbraucht wurde. Dies bedeutet, dass das Paket es nicht intern im Netzwerk gemacht hat. Die andere Verwendung für empfangen ist in einem VPN-Szenario, in dem das Paket empfangen und entschlüsselt wird.

Nach 3 Wochen kam Sonicwall endlich mit einer Antwort zu mir zurück und obwohl ich einen Link auf diese Seite eingefügt hatte, gaben sie mir immer noch dieselbe Antwort wie Sie. Ihre Unterstützung scheint den Unterschied zwischen Layer 2 und Layer 3 des OSI-Modells nicht zu kennen.

Ich habe mich beschwert, und einer der Supportmitarbeiter hat mich angerufen, aber er schien nicht zu wissen, was er tat, und ich musste ihn weiter korrigieren. Er gab schließlich auf und akzeptierte, dass es jenseits von ihm lag und sagte er würde es an einen Ingenieur weitergeben müssen.

Möchte jemand von Sonicwall NSA $ 15.000? Es gibt natürlich Probleme mit Sonicwall Layer 2 Bridging, nicht zu erwähnen, dass es drei Wochen dauert, um eine Dose per E-Mail zu versenden.

Mögliche Lösung/Behebung dafür: Installieren Sie einen günstigen Router als einfachen Access Router zwischen beiden Subnetzen. Richten Sie eine statische Route von der Sonicwall aus auf diese Route, damit der gesamte Verkehr zwischen den beiden Subnetzen über den "anderen" Router erfolgt.

Wenn Sie den Bridged-Modus ausführen, gibt es in der Bridge-Schnittstelle die Option "Auf diesem Bridge-Paar nicht routen", wodurch das Problem gelöst wird und die Subnetze wieder miteinander kommunizieren können (dh ein richtiger Durchlauf).

Das Problem danach ist, dass der gesamte Datenverkehr ausgeht, Ihren Router trifft und auf dem Rückweg Firewall-Regeln unterliegt (Sie benötigen also mehr Regeln, um Ihre eigenen IPs zuzulassen). Es kann auch schmerzhaft sein, wenn Sie vor dem Router ein Paketshaper haben (oder sogar, wenn Ihr Router nur eine 100-Meter-Schnittstelle anstelle von 1 GB hat), da dies ohne Zweifel den Datenverkehr beeinflusst, wenn er durchläuft, und alles verlangsamt. Aus diesem Grund habe ich Sonicwall kontaktiert und ich stimme zu, sie sind schrecklich und ich werde den Support-Vertrag nicht verlängern, wenn er fällig ist. Alles, was ich von ihnen bekomme, ist irrelevant und völlig unbrauchbar.

Wir haben einen NSA 4500, der kein billiges Kit ist und ich habe mehr davon erwartet. Hoffen wir, dass der Dell-Buyout die Dinge ändern kann. Ich bezweifle es aber ...

Es klingt so, als würden Sie versuchen, die Sonicwall nur mit Datenverkehr zu schnüffeln. Ich würde dazu einen gespiegelten Port (auf dem Switch) konfigurieren und dann nur die WAN-Schnittstellen für das Schnüffeln konfigurieren. Ich würde den Port auch als "Sniffing" -Zone konfigurieren, da es Ihnen nicht wichtig ist, das Routing durchzuführen. Sie sind sich nicht sicher, ob Sie dies versucht haben ...

Ich habe Sonicwall seit mehreren Jahren verwendet, ich mag alle ihre Produkte zum größten Teil. Ich kann nicht sagen, dass ich den Support wirklich sehr nutze, aber bei den besten Supportanfragen Vor- und Nachteile hatte. Die erste und die zweite Unterstützungslinie sind normalerweise ziemlich schwach.

Sonicwall NSA-Benutzer