12.04.2018, aktualisiert am 14.04.2018

8422

SonicWall Konfiguration und Hilfestellung für einen Anfänger

Hallo zusammen,

Ich habe hier ein paar sehr spezielle Fragen der SonicWall betreffend, um herauszufinden, wie diese genau funktioniert.
Kurz zuvor eine Sache zu mir: Ich bin kein SysAdmin, habe aber ein gutes Grundverständnis der IT und ein sehr ausgeprägtes Logikverständnis. Allerdings wurde ich hier ins kalte Wasser geschmissen und bin nun voll drin, herauszufinden wie das alles funktioniert (so bin ich eben).

Was wir hier in der Firma erreichen wollen:
- Unseren Synology FileServer in die Firewall einbinden (Aktuell im X0 Lan Subnet unter https://192.168.178.100:5001 zu erreichen) und den FileServer unter X2 anbinden um ein zweites Lan Subnet mit der IP 192.168.181.100:5001 (192.168.181.X) zu erstellen
- Funktionierende und sichere Routen/NAT/etc. erstellen um einen Zugriff auf den Synology FileServer vom Office/Lan Subnet(X0) zu ermöglichen sowieso von einer SSL VPN Verbindung (Die SSL VPN funktioniert aktuell leider auch nur halb, da ich noch nicht ganz dahintergekommen bin)
- Erstellen eines Site-To-Site VPN Tunnels für einen Kunden, der dann eben auf den eingerichteten Synology FileServer zugreifen muss

Ich bin hier super offen für alle Vorschläge, Ideen und Verbesserungen eurerseits! Generell würde mir jede Hilfestellung extrem weiterhelfen.. :D

Um es vllt besser erklären zu können, hier unsere internen IP Adressen:

Lan Subnet (X0) ist 192.168.178.X

Das zweite Subnet (X2) soll auf die 192.168.181.X

SSL VPN IP Range ist aktuell 192.168.182.X (Oder sollte die SSL VPN IP Range in eins der beiden Subnetze?)

Unsere Public IP Adresse ist hier als Beispiel 1.1.1.1

Vielen Lieben Dank für jede Hilfe! ;)

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 370909

Url: https://administrator.de/forum/sonicwall-konfiguration-und-hilfestellung-fuer-einen-anfaenger-370909.html

Ausgedruckt am: 01.05.2025 um 03:05 Uhr

17 Kommentare

Neuester Kommentar

habe aber ein gutes Grundverständnis der IT und ein sehr ausgeprägtes Logikverständnis.

Solch eine Aussage ist wie immer im Leben absolut relativ und besagt gar nichts. Vielleicht bist du ja C++ Profi verstehst aber nur Bahnhof wenn es um IP Layer 3 Forwarding und Protokolle geht. Wie sollen wir das beurteilen..?!
In so fern sind solche Aussagen überflüssig...aber egal.

X0 Lan Subnet unter https://192.168.178.100:5001

Riecht von der IP her als ob da ne billige FritzBox mit von der Partie ist ?!

Funktionierende und sichere Routen/NAT/etc. erstellen

Routen braucht man mit einem einzigen popeligen LAN Segment dafür nicht. Es reicht eine Default Route zum Provider und gut iss !

Erstellen eines Site-To-Site VPN Tunnels

Guckst du hier:
https://www.sonicwall.com/en-us/support/knowledge-base/170505690888348
https://www.youtube.com/watch?v=_OJ8j_xOTYQ

Lan Subnet (X0) ist 192.168.178.X

Das ist keine gültige Netzadresse (Hostbits = alle 0) außerdem fehlt die Maske

Du meinst vermutlich 192.168.178.0 /24 richtig ?

Das zweite Subnet (X2) soll auf die 192.168.181.X

Gleiches Problem...welche Maske ?

Beim IPsec VPN werden die Routing Credentials automatisch übergeben das erstmal nur vorweg.
Leider teilst du uns nicht mit mit welchem VPN Protokoll du das VPN realisieren willst, in der Beziehung können wir hier nur im freien Fall raten. Etwas mehr Infos wäre für eine zielführende Hilfe sehr förderlich.

Eigentlich wollte ich damit gar nichts sagen. Aber finde es schade das man sich Mühe gibt zu antworten, um... so etwas zu kritisieren? o.O
Trotzdem danke.

Riecht von der IP her als ob da ne billige FritzBox mit von der Partie ist ?!

Von dieser weiß ich bis jetzt noch nichts, allerdings bezieht die Firma ihre Internet Leitung per LTE, da es auf dieser Straßenseite keine Glasfaseranbindung gibt. Also gut möglich

Routen braucht man mit einem einzigen popeligen LAN Segment dafür nicht. Es reicht eine Default Route zum Provider und gut iss !

Und da hängt mein Problem, du kannst sagen was man "popeliges" nicht braucht oder braucht, aber eigentlich hatte ich mir erhofft, eine erklärung zu bekommen, keine "Du bist ja dumm" antwort. Dann kann man sich das antworten auch sparen ;)

Guckst du hier:
https://www.sonicwall.com/en-us/support/knowledge-base/170505690888348
https://www.youtube.com/watch?v=_OJ8j_xOTYQ

Vielen Dank, Links kannte ich zwar schon, aber werde ich mir noch einmal zur Brust nehmen.

Das ist keine gültige Netzadresse (Hostbits = alle 0) außerdem fehlt die Maske

Du meinst vermutlich 192.168.178.0 /24 richtig ?

Das zweite Subnet (X2) soll auf die 192.168.181.X

Gleiches Problem...welche Maske ?

Wie bereits erwähnt, kenne ich mich hier nichtmehr gut aus, bin aber lernbereit...
Maske steht aktuell 255.255.255.0 fest, viel mehr kann ich der SonicWall nicht entnehmen.

Ich denke du meinst diese?
IKE using Preshared Secret
Group2, 3DES, SHA1 - Phase 1
Perfect Forwad Secrecy, Group 2, ESP, 3DES, SHA1

Bitte allgemein im Kopf behalten, nicht direkt sofort draufzuhauen, wenn jemand etwas fragt, selbst wenn es nach eigenem Verständnis logisch oder selbstverständlich ist.
Es hilft niemandem, der etwas fragt, wenn man nur hate antwortet. Liest sich hier nämlich zu 90% so.
Ansonsten nicht antworten, mit dem Kopf wackeln, und weitergehen. (Wenn man "fast" nur haten möchte, bzw unfreundlicher reagiert)
Danke ;) Das soll konstruktiv gemeint sein

Aber finde es schade das man sich Mühe gibt zu antworten

Was hat denn solch Statement für einen Nutzen für andere Teilnehmer hier. Einzig das du dich damit selber stigmatisierst und dich als Dummie hinstellst. Das muss ja nicht sein. Ob du Informatik Doktorant oder PC Bastler bist können wir eh nicht beurteilen und deinen Wissenstand oder Pfiffigkeit oder was auch immer schon gar nicht.
Wozu also so eine wenig hilfreiche Einleitung die für dich und deinen Thread selber eher kontraproduktiv ist..?!
Das ist sicher gut gemeint und sollte auch keine Kritik sein, dir nur mal die Sinnlosigkeit von sowas vor Augen führen.
Zurück zum Thema...

Von dieser weiß ich bis jetzt noch nichts

War nur ein Verdacht, da .178.0 /24 bekanntlich das klassische, millionenfache Allerwelts FritzBox IP Netz ist.
Bei einer VPN Nutzung ist das wie immer ziemlich kontraproduktiv. Siehe hier:
VPNs einrichten mit PPTP
Besser also eine andere IP.

aber eigentlich hatte ich mir erhofft, eine erklärung zu bekommen

Die FW ist dein einziges Gateway was du hast. Alle IP Netze sind direkt an ihr dran/angeschlossen. Damit "kennt" die Firewall logischerweise diese ganzen direkt verbundenen IP Netze und weiß wie man sie erreicht.
Das remote VPN LAN bekommt sie mit den IPsec Credetials automatisch in die Routing Tabelle beim Tunnelaufbau injiziert. Folglich musst du also keinerlei Routen oder sowas zusätzlich konfigurieren.

Ich denke du meinst diese?

Nein ! Ich meinte das Protokoll aber egal...auch die falsche Antwort hat bestätigt das die FW bzw. du das IPsec Protokoll nutzt für das VPN.
Ist auf der anderen Seite auch eine Sonicwall ? Wenn nicht und das ein anderer Hersteller ist solltest du bei IPsec immer den sog. Agressive Mode verwenden und nicht den Main Mode.

Liest sich hier nämlich zu 90% so.

Na ja in einem Administrator Forum sollte man auch etwas Standfestigkeit haben und keine Mimose sein wenn man dort Anfängerfragen stellt und der Wind mal etwas rauher wird. Sonst ist man bei www.gutefrage.net besser aufgehoben.

Das soll konstruktiv gemeint sein

Das kam auch so an

Vielen Dank, das kam jetzt auch freundlich rüber :D

Deshalb versuche ich gerade, das Subnetz 192.168.181.X einzurichten, aber aus einem mir unbekannten Grund kann ich 192.168.181.100 (Synology FileServer) zwar anpingen, aber nicht darauf zugreifen per https intern oder per SSL VPN.
Irgendwo sitze ich hier mit einem Gedankenfehler und komme einfach seit Tagen nicht darauf.

Das Interne Subnetz 192.168.178.X sollte ja für Remote erstmal kein Problem sein, wenn ich dafür das zweite Subnetz für den FileServer extra einrichte und dort die VPN Verbindung einrichte, oder?
Bitte gerne korrigieren falls es trotzdem dazwischen funkt.

Also generell kann ich das zweite Subnetz zwar anpingen, aber nicht auf den FileServer zugreifen (.100) aber auf das Gateway/Firewall mit der 192.168.181.1 komme ich drauf, per https/SSL VPN.
Habe ich eine NAT falsch? Fehlt eine Route? Ich versteh es grad einfach nicht so wirklich :D

Vielen Dank aufjedenfall für die Mühe, vorallem beim 2. Antworten nochmals!

aber aus einem mir unbekannten Grund kann ich 192.168.181.100 (Synology FileServer) zwar anpingen, aber nicht darauf zugreifen per https

WIE sieht denn dein Regelwerk in der Firewall aus ??? Ohne ein solche blockiert die Firewall wie es bei FW üblich ist ALLES.
Auf dem Interface 192.168.181.0 muss also mindestens so eine globale Regel stehen wie:
Erlaube IP, Quelladresse: 192.168.181.0, Zieladresse: ANY

Die erlaubt dann Inbound in das Interface alle IP Pakete (Protokoll egal) mit einer Absender IP 192.168.181.0 und Ziel IP egal.
Quasi also erstmal eine "Scheunentor Regel" zum Testen.
Die virtuellen VPN Interface brauchen logischerweise auch solche Regeln wie das nun mal bei einer FW üblich ist.
Hast du das bedacht ?
Und nochwas...
Wenn du mit Winblows Rechnern testest. Dann musst du AUCH deren interne Firewall customizen damit die ICMP (Ping, Traceroute) von Fremdnetzen durchlassen:
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
und auch ggf. andere Dienste die du nutzen willst !!
Ohne das blockiert dann zusätzlich noch die interne Windows Firewall !
Das gilt auch für das Synology NAS sofern das eine lokale FW aktiv hat was aber vermutlich nicht der Fall ist, oder ?

aber nicht auf den FileServer zugreifen (.100) aber auf das

Wie gesagt: Lokale Firewall customiizen !!! Wenn der Server ne Winblows Gurke ist.

Habe ich eine NAT falsch?

Nein !
NAT machst du nur ausschliesslich zum Internet Provider und auch NUR wenn an der Firewall direkt ein reines Modem dran ist, sprich also die Firewall DIREKT mit einer öffentlichen Provider IP am WAN Port arbeitet.
Tut sie das NICHT, sprich arbeitet also in einer Router Kaskade mit einem vorgeschalteten NAT Router macht NUR diese NAT und NICHT die Firewall !
Leider sagst du auch nichts zur Anbindung, deshalb wieder Raten im freien Fall

Hier mal ein Bespiel zu solch einer Kaskade:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten

Also, dann versuche ich etwas Weiter auszuholen, vielleicht hilft das ja.

Unser Aufbau hier sieht folgendermaßen aus:
(Hier hattest du leider Recht)Unsere LTE Leitung könnte aus einer Fritzbox kommen, da wir unten im Serverraum eine stehen haben.
Allerdings ist das hier sehr kompliziert: Wir bekommen 4 LTE Leitungen, die zu einer Außenstelle geschickt werden, und dort dann gebündelt zu uns in einer Leitung geschickt werden :D Allerdings meinte mein Chef gerade zu mir, das die 192.168.178.X zufällig von ihm damals genommen wurde, also keine Fritzbox zurzeit diese IP vergabe macht.

Also:
LTE Leitung rein -> SonicWall NSA 6250

Die Firewall hat 3 Anschlüsse: X0 Lan Subnet, X1 WAN, X2 NAS/FileServer

X0: 192.168.178.X (Lan Subnet, voll nutzbar)
X2: 192.168.181.X (2. Subnet, NAS, nur PING möglich)

In der Firewall Rule sind alle Wege offen, siehe Screenshot.

Meine Lokale Firewall am Firmenlaptop ist aktuell komplett DEAKTIVIERT, zu Testzwecken.

So sieht es aus, wenn ich eine FW Rule hinzufügen will

So sieht die FW mit Interfaces aus, also X0 X1 X2 etc.

So die Routes auf der SonicWall, Alle standard

DHCP Leases von der FW

Das Problem ist einfach, dass ich auch aus dem Lan Subnet nicht auf das X2 Interface zugreifen kann, nur PING klappt hier.

Vielen Dank wieder für deine Antwort!

zufällig von ihm damals genommen wurde, also keine Fritzbox zurzeit diese IP vergabe macht.

Die Botschaft vernehm ich wohl allein mir fehlt der Glaube. Das sind ein paar Zufälle zuviel. Oder er hat zuviel AVM Handbücher gelesen.
Fakt ist das das auf alle Fälle eine sehr unglückliche Wahl ist und dir später gaz sicher wieder auf die Füsse fallen wird. Spätestens wenn das erste remote Netz auf ein Allwelts 192.168.178.0 FritzBox Netz ist, dann ists aus mit VPN dorthin.
JETZT kannst du das noch problemlos ändern in eine sinnvollere 172er oder 10er IP mit einem /24 Prefix.
https://de.wikipedia.org/wiki/Private_IP-Adresse#Adressbereiche.

Wir bekommen 4 LTE Leitungen, die zu einer Außenstelle geschickt werden

Auch das klingt höchst märchenhaft. LTE kann man in der Regel NICHT bündeln. Einzig und allein ein Failover ist möglich. Dafür würden dann aber 2 Leitungen reichen und keine 4. Vermutlich dümpeln da nur 3 Verbindungen ohne Funktion rum und über eine geht der Traffic.
Kann man aber wieder nur im freien Fall raten ohne weitere Infos....

Ist ja auch nicht das Thema.
Fakt ist dann aber das du mit der Sonicwall vermutlich eine Router Kaskade hast !!
Dann müsste die SonicWall kein NAT (Adress Translation) machen. Das wäre dann eh doppeltes NAT was nicht wirklich gut wäre in so einem Design. Gerade bei VPNs, da es massic Probleme schafft.

Also: LTE Leitung rein -> SonicWall NSA 6250

Stimmt ja nicht !
Denn versteht man dich richtig muss das ja so aussehen:
(Internet)==LTE==(NAT-LTE-Router)- - - -(Firewall)- - - -Lokale LANs
Routerkaskade mit dem LTE Router, oder ?

In der Firewall Rule sind alle Wege offen, siehe Screenshot.

Das ist die Regel "LAN -> DMZ" richtig ??
Wo aber ist die Rule "DMZ -> LAN" ??
So kommen zwar IP Pakete vom LAN Segment .178.0 ins DMZ Segment .181.0 aber es gibt keinerlei Firewall Regel für die Rückroute vom DMZ Segment .181.0 ins LAN Segment .178.0 !!
Pingst du also was vom LAN im DMZ bleiben die Antwort Pakete in der Firewall hängen denn die Default regel ist Alles verboten !.
Hast du das bedacht ??

So sieht die FW mit Interfaces aus, also X0 X1 X2 etc.

Das ist alles korrekt.

So die Routes auf der SonicWall, Alle standard

Sieht etwas wirr aus und unverständlich aber wenn du da nichts zusätzliches eingerichtet hast außer der Default Route 0.0.0.0 /0 ist das OK.
Statische Routen dürfen NICHT konfiguriert werden.

Das Problem ist einfach, dass ich auch aus dem Lan Subnet nicht auf das X2 Interface zugreifen kann

Wie bereits gesagt...die fehlende Regel wenn X2 das DMZ Segment ist.

Also, X2 ist im LAN Segment, ZONE LAN, untergebracht, damit es problemlos (jetzt erstmal) mit dem LAN SUBNET kommunizieren kann. Hat also dieselben einstellungen wie X0.

Das interessante an der ganzen Geschichte ist jetzt, das ich einen laptop per switch zum X2 angehängt habe:
X2 -> Switch -> NAS und Laptp

Auf dem Laptop ist die Firewall komplett deaktiviert, zu testzwecken, und ich bekomme per Firewall DHCP eine 192.168.181.14 IP zugewiesen.
Ich kann innerhalb des Netzwerks auch den NAS anpingen, komme ins X1 WAN, aber nicht ins X0 LAN im Office.
Sprich, eine Verbindung von X0 LAN zu X2 NAS funktioniert, aber nicht andersherum.
Fällt dir dazu etwas ein, was ich hier falsch mache?

Eigentlich sind in den Firewall Rules aktuelle alle Richtungen auf Allow ANY gesetzt, wie man sieht. Deny Rules sind zu testzwecken nicht aktiv.

Also komme ich mit dem Laptop an X2 ins WAN und Internet, kann surfen, kann aber nicht aufs 192.168.176.X Subnet pingen und zugreifen...

Vielen lieben Dank für deine Hilfe! Das ist großartig!

Ich kann innerhalb des Netzwerks auch den NAS anpingen

Ja, das ist ja klar und auch logisch, da ja alle Interfaces in einer gemeinsamen Layer 2 Doamin sind, sprich also alle im gleichen IP Segment.

Fällt dir dazu etwas ein, was ich hier falsch mache?

Ja, das riecht ganz klar nach falschen Firewall Regeln !!
Das regelwerk X0 Segment zu X2 Segment stimmt, aber die Rückroute X2 zu X0 ist falsch oder fehlerhaft so das hier Pakete geblockt werden.
Da solltest du also sehr verstärkt nochmal das Regelwerk überprüfen !!

aktuelle alle Richtungen auf Allow ANY gesetzt, wie man sieht.

Nimmt man das von dir oben gepostete Bild als Grundlage stimmt eben genau das nicht. Hier fehlt komplett die Regel X2 zu X0 und das bedeutet = alles verboten. Würde das Verhalten erklären.

Laptop an X2 ins WAN und Internet, kann surfen, kann aber nicht aufs 192.168.176.X Subnet pingen und zugreifen...

Bestätigt dann auch nochmal die o.a. Vermutung des falschen oder fehlerhaften Regelwerkes zw. X2 und X0 !!

Also, Ich hatte gestern noch eine Regel gesetzt die X2 auf X0 auf ALLOW ANY setzt.
Auch danach ging es nicht... Hmmm Mensch >.< Ich komm nicht drauf was da falsch läuft :D

Habe nun testweise ALLES von X2 > LAN/DMZ/WLAN/WAN/X0 etc auf ALLOW ANY gesetzt. Ändert sich trotzdem nichts.
Denke auch das irgendwas mit den Rules/Policies der Firewall nicht stimmt, aber ich verstehe einfach nicht woran es liegt bzw. wie die SonicWall funktioniert.

noch eine Regel gesetzt die X2 auf X0 auf ALLOW ANY setzt.

Dann kann aber was mit dem grundsätzlichen Design oder der Interface Zuordnung auf der Firewall was schon nicht stimmen.
Mit der Scheunentorregel ANY to ANY muss es in jedem Falle funktionieren !

Hat die Firewall eine Log Funktion ?? Sollte sie mit Sicherheit haben !
Dort mal ins Log sehen wenn du von X2 auf X0 zugreifst. In den Logs steht immer drin was wo warume gefiltert wurde. Ggf. Log vorher mal löschen wegen der Übersichtlichkeit.

Selbst die Log funktion ist... super unübersichtlich. Ich sehe nicht auf anhieb in welches der ganzen logs ich schauen muss, bzw wo das richtige Log zu finden ist :D
Ich verzweifel an dieser FW zurzeit! Ahhhh

EDIT: Ok, habe eine art Event log gefunden, dort stehen die events wie, wann und mit wem ich mit eingeloggt habe in die FW, per SSL VPN verbunden etc.

Aber ich habe da noch keine Übersicht gefunden die den Zugriff von X2 und X0 zeigt.

Sieh dir zur Not dann mal ALLE Logs an. Wenn du in einem Blocking Infos findest, dann ist das das richtige.

Dürfte ich dich vielleicht zu einer Skype Desktop Übertragung heranziehen?

Ich sitze jetzt seit 6 Tagen da dran und verstehe noch nicht woran es scheitert.

Hier zum beispiel Packet Monitoring, ich denke hier sehe ich es am ehesten wenn etwas droppt/denied wird. Aber aktuell passiert da nichts. Glaube ich muss da aber mehr einstellen was er zeigen soll...

Es sieht für mich im Packet Monitoring so aus, als würde er aus dem SSL VPN die Weiterleitung zu .181.100 zulassen, auch mit dem Port 5001.
Aber ich komme in Wahrheit nicht auf die IP.

Ebenso sind mir unstimmigkeiten aufgefallen:
Auf 192.168.178.100:5001 komme ich SOFORT ohne das es lange lädt.
Auf 192.168.181.100:5001 komme ich nicht und es lädt ewig, bevor es mir nach 20-30 sek sagt, das es nicht erreichbar sei.

Auf 192.168.181.100:5001 komme ich nicht und es lädt ewig, bevor es mir nach 20-30 sek sagt, das es nicht erreichbar sei.

Das liegt daran das der Host aus dem Netz nicht antwortet. Oder er antwortet und die Antwort bleibt in der Firewall hängen.
Das warten ist das TCP Session Timeout. Ein sicheres Indiz dafür das keinerlei Reply von dem Host kommt.
Da schlägt die Firewall zu....vermutlich.

Mach es doch mal ganz einfach:
Installiere auf dem 192.168.181.100 einen kostenlosen Wireshark Sniffer und checke mal ob dort eingehende Pakete mit TCP Port 5001 vom Absender ankommen mit dem du darauf zugreifst.

Wenn nichts ankommt blockiert die FW schon das senden.
Wenn was ankommt, der 192.168.181.100 antortet aber am Absender nix ankommt dann blockiert die Firewall den Rückweg.

So kannst du wenigstens schnell und sicher feststellen in welche Richtung die FW blockt !