Zyxel USG 40 Zugriff auf NAS funktioniert nicht
Guten Morgen liebe Gemeinde
ich habe bei mir zuhause eine Zyxel USG 40 hinter einem T-online Router stehen. Zudem eine Qnap NAS auf der alle Daten gespeichert sind.
Auf der USG sind Regeln für HTTP, HTTPS, IMAPS und SMTPS definiert so das E-mails und Web funktionieren. Zum Testen wurde auch noch von any zu any allow mit log gesetzt.
Derzeit sind an der USG nur 2 Geräte angeschlossen. PC mit 192.168.3.3 und NAS mit 192.168.3.2 die von der USG per DHCP zugeteilt werden. Beide hängen direkt an der USG im LAN1.
Leider kann ich weder direkt über die IP auf die NAS zugriffen noch findet der Qfinder die NAS.
Leider bin ich in diesem Gebiet neu und kenne mich noch nicht gut aus. Sollten Infos fehlen bitte um konstruktive Meldungen.
Das Endstadium wollte ich die NAS auf LAN2 setzen um eine gleichbleibende IP zuhaben und eine nochmal abgeschirmte Insel vom LAN1 mit den restlichen PC's. Um nur den Datenaustausch zu erlauben und alles andere dicht zu machen. Haltet Ihr das für sinnvoll um Daten zu schützen??
Vielen Dank schon mal für alle Lösungen
Gruß Alex
ich habe bei mir zuhause eine Zyxel USG 40 hinter einem T-online Router stehen. Zudem eine Qnap NAS auf der alle Daten gespeichert sind.
Auf der USG sind Regeln für HTTP, HTTPS, IMAPS und SMTPS definiert so das E-mails und Web funktionieren. Zum Testen wurde auch noch von any zu any allow mit log gesetzt.
Derzeit sind an der USG nur 2 Geräte angeschlossen. PC mit 192.168.3.3 und NAS mit 192.168.3.2 die von der USG per DHCP zugeteilt werden. Beide hängen direkt an der USG im LAN1.
Leider kann ich weder direkt über die IP auf die NAS zugriffen noch findet der Qfinder die NAS.
Leider bin ich in diesem Gebiet neu und kenne mich noch nicht gut aus. Sollten Infos fehlen bitte um konstruktive Meldungen.
Das Endstadium wollte ich die NAS auf LAN2 setzen um eine gleichbleibende IP zuhaben und eine nochmal abgeschirmte Insel vom LAN1 mit den restlichen PC's. Um nur den Datenaustausch zu erlauben und alles andere dicht zu machen. Haltet Ihr das für sinnvoll um Daten zu schützen??
Vielen Dank schon mal für alle Lösungen
Gruß Alex
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-Key: 316504
Url: https://administrator.de/contentid/316504
Ausgedruckt am: 19.03.2024 um 04:03 Uhr
7 Kommentare
Neuester Kommentar
NAS mit 192.168.3.2 die von der USG per DHCP zugeteilt werden.
Ein erster Kardinalsfehler ! Server IPs wie auch Infrastruktur Adressen sind in einem Netzwerk immer statisch, niemals dynamisch. Goldene Regel eines jeden verantwortungsvollen Netzwerkers !Der Sinn leuchtet ein. Gerade wenn man von außen auf diese Resourcen zugreifen will und feste Port Forwarding Zuordnungen braucht liegt es auf der Hand das diese Adressen sich niemals ändern dürfen. Bei dir machen sie das aber durch die Dynamik von DHCP.
Leider kann ich weder direkt über die IP auf die NAS zugriffen noch findet der Qfinder die NAS.
Dann hast du vermutlich diese beiden Ports NICHT als Layer 2 Switch definiert in der USG Konfig !Das müssen sie aber denn du bist mit diesen Ports ja in konfigtechnisch einer gemeinsamen Layer 2 Collision Domain.
Die USG sieht diese Ports im Default als dedizierte IP Segente an und versieht siw wie es für eine Firewall üblich ist mit einer deny any any Regel.
Das ist vermutlich die Falle in die du getappt bist ?!
Wenn du mal einen Wireshark auf deinem Laptop angeschmissen hättest, hättest du das auch sofort ohne den Thread hier gesehen...
Grundlagen zu der Thematik Bridging von 2 FW Interfaces findest du auch in diesem Forumstutorial:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Das mit dem Layer 2 Switch war mir so nicht bewusst.
Ist doch aber klar wenn du Ports in einem gemeinsamen IP Segment hast. Ansonsten machst du ja ein IP Routing, was dann aber umgekehrt wieder 2 unterschiedliche IP Segmente erfordert.Das ist nun simpelste Netzwerk Kunde erste Klasse....
das ich hier eine Bridge einrichten muss um zwischen LAN1 und LAN 2 zu kommunizieren
Sofern die Firewall diese beiden Ports im Default als separate IP Ports sieht ja. Andererseits müsstes du ja dann routen.http://kb.zyxel.com/KB/searchArticle!gwsViewDetail.action?articleOid=00 ...
http://www.dslreports.com/forum/r21451613-USG-bridging-ports
http://www.zyxeltech.de/snotezw5_362/app/bridge.htm
https://www.youtube.com/watch?v=A6AbjU1dVdo
Zitat von @Alexwehle:
Zugang soll die NAS von außen (WAN) nicht bekommen, nur das was sie selber benötigt (Zeit, Updat ecc.)
...
Das Endstadium wollte ich die NAS auf LAN2 setzen um eine gleichbleibende IP zuhaben und eine nochmal abgeschirmte Insel vom
LAN1 mit den restlichen PC's. Um nur den Datenaustausch zu erlauben und alles andere dicht zu machen. Haltet Ihr das für sinnvoll
um Daten zu schützen??
Zugang soll die NAS von außen (WAN) nicht bekommen, nur das was sie selber benötigt (Zeit, Updat ecc.)
...
Das Endstadium wollte ich die NAS auf LAN2 setzen um eine gleichbleibende IP zuhaben und eine nochmal abgeschirmte Insel vom
LAN1 mit den restlichen PC's. Um nur den Datenaustausch zu erlauben und alles andere dicht zu machen. Haltet Ihr das für sinnvoll
um Daten zu schützen??
Zuhause? Eher nein. Was soll das bringen? Wenn man von einzelnen PCs aus nicht aufs NAS zugegreifen können soll, dann kann man das selbstverständlich mittels der Firewall regeln. Dafür müssten die PCs aber auch alle feste IP-Adressen haben und diese von den Usern nicht geändert werden können. Ohnehin bräuchte es dafür die Firewall nicht, denn IP-basierte Filterung kann auch das QNAP selbst. Letztlich sehe ich aber auch darin wenig Sinn - wenn unterschiedliche Zugriffsrechte bestehen, dann bilde diese doch einfach über die Benutzerverwaltung des QNAP ab.
Zitat von @Alexwehle:
Ist hier Bridge überhaupt die richtige Wahl oder etwas anderes?
Ziel ist es das die NAS auf LAN 2 mit fester IP läuft und der Rest in LAN1 über DHCP.
Ist hier Bridge überhaupt die richtige Wahl oder etwas anderes?
Ziel ist es das die NAS auf LAN 2 mit fester IP läuft und der Rest in LAN1 über DHCP.
Um die PCs per DHCP und das QNAP per statischer IP betreiben zu können, braucht es weder eine Bridge noch muss dafür das QNAP nach LAN2.
Zitat von @Alexwehle:
Derzeit sind an der USG nur 2 Geräte angeschlossen. PC mit 192.168.3.3 und NAS mit 192.168.3.2 die von der USG per DHCP zugeteilt werden.
Beide hängen direkt an der USG im LAN1. Leider kann ich weder direkt über die IP auf die NAS zugriffen noch findet der Qfinder die NAS.
Derzeit sind an der USG nur 2 Geräte angeschlossen. PC mit 192.168.3.3 und NAS mit 192.168.3.2 die von der USG per DHCP zugeteilt werden.
Beide hängen direkt an der USG im LAN1. Leider kann ich weder direkt über die IP auf die NAS zugriffen noch findet der Qfinder die NAS.
Wenn beide Geräte wie beschrieben an der Firewall hängen und von dieser eine IP aus dem gleichen Netz zugewiesen bekommen, dann hängen diese definitiv bereits im gleichen Layer2-Segment. Wenn Du zudem zu diesem Zeitpunkt noch nicht viel von der Default-Config der Zywall abgeändert hattest - insbesondere noch keine wilden Experimente à la Bridge etc. veranstaltet hast, dann kann die Ursache eigentlich nicht die Firewall sein, denn sie arbeitet in diesem Fall wie ein dummer Switch.
Vielleicht mal ein paar Erläuterungen zum besseren Verständnis:
Die Firmware der USG40 basiert auf einer speziellen Linux-Anpassung, die prinzipiell sehr mächtig ist. Den vollen Funktionsumfang gibt es aber erst ab den wesentlich teureren Modellen der 3xx-Reihe und höher. Auch Zyxel möchte Geld verdienen. Also war (vor etlichen Jahren) ein Entwicklungsziel für die Firmware der ersten kleineren Linux-Modelle, deren Funktion gegenüber den größeren schon länger im Markt befindlichen Linux-Modellen künstlich zu beschneiden.
Ein weiteres Ziel war es offenkundig, den Nutzern der früheren (kleinen) Zywall-Modelle, die noch auf dem alten Betriebssystem "ZyNOS" basierten (bspw. die Zywall 5), durch eine gewisse Angleichung einiger Bezeichnungen in der GUI den Umstieg auf die neuen Linux-Geräte zu erleichtern. Während man den Käufern der größeren Modelle also durchaus etwas Gehirnschmalz zubilligte, hat man dies den typischen Nutzern der kleinen Modelle nicht zugetraut. Möglicherweise nicht ganz zu Unrecht und eigentlich wäre es auch nicht zu beanstanden, wenn man es denn gut gemacht hätte.
Statt dessen hat man wohl Entwickler, Marketingleute usw. in einen Raum gesperrt und es ordentlich rauchen lassen. Leider waren das offenkundig nicht die Köpfe, sondern die Joints! Heraus kam jedenfalls ziemlicher Schwachsinn: Und zwar die Übernahme der ZyNOS-typischen Bezeichnungen LAN1, DMZ, WAN1, WAN2 usw. Genau genommen war das noch nicht wirklich die schlechte Idee, sondern die Gleichbenennung und Zwangsbündelung von Portgruppen und Firewallzonen.
Wie jede Firewall hat auch die Zywall selbstverständlich physische Ethernetports. Diese kann man jedoch auch nur hinsichtlich ihrer physischen Eigenschaften wie Linkspeed, Duplexmode etc. konfigurieren. IP-Adressvergaben z.B. finden hier nicht statt. Dafür gibt es repräsentative (Ehternet-)Interfaces. Letzteren werden die physischen Ports zugeordnet. Dabei kann ein solches repräsentatives Interface genau einem physischen Port entsprechen oder auch einer Gruppe von physischen Ports (dann Portgrouping genannt).
Bei den größeren Modellen bis ZLD3.x (ab 4.x ist das über die GUI leider nicht mehr konfigurierbar) kann man diese Zuordnungen völlig frei gestalten und die repräsentativen Interfaces auch frei benennen. Bei den kleinen Modellen geht das nicht. Der erste physische Port an Deiner Büchse ist zwangsweise dem repr. Interface "wan1" (klein geschrieben!) zugeordnet. Weitere Ports kann man darin auch nicht aufnehmen. Dieses repr. Interface "wan1" ist hardcodiert als Typ "external" gelabelt (woran gewisse Eigenschaften und Verhaltensweisen der Box hängen) sowie zwangsweise der Firewallzone "WAN" (groß geschrieben) zugeordnet. Damit hat man sichergestellt, dass die Multi-WAN-Möglichkeiten der USG40 weitgehend beschnitten sind und sie den größeren Modellen diesbezüglich keine Konkurrenz macht.
In gleicher Manier geht es weiter: So gibt es weitere vordefinierte repr. Interfaces wie z.B. "lan1". Dieses kann dann immerhin schon ein Portgrouping sein. Welche Ports darin aber aufgenommen werden können, ist bei den kleinen Modellen letztlich doch wieder restriktiert (bei der 40er vermutlich Port 2-4). Auch gehört dieses Interface bei den kleinen Zywalls damit automatisch wieder zu einer vordefinierten Firewallzone, ist zwangsweise vom Typ "internal" usw.
Auf den ersten Blick scheint es also bei den kleinen Zywalls egal zu sein, ob man von "lan1" (=repräsentatives Interface/Portgrouping) oder "LAN1" ("=Firewallzone) spricht. Ist es aber nicht, weil dies das Verständnis der Arbeitsweise des Gerätes erschwert!
Traffic zwischen den physischen Ports derselben Portgruppe durchläuft nicht den IP-Stack der Zywall und ebenso auch NICHT das Firewallregelwerk und kann deshalb weder per Firewall beregelt noch im Echtzeitlog der Firewall angezeigt werden. Deshalb kann in dem hier vorliegenden Fall die Firewall auch nicht die Ursache für das "Nichtsehen" des QNAP sein, wenn beide Hosts an Ports der selben Portgruppe angeschlossen sind!
Das Firewallregelwerk der Zywall bietet optional die Möglichkeit, auf sog. Zonen abzustellen. Firewallzonen sind nichts anderes, als eine Gruppierungsmöglichkeit für Interfaces. Beregeln kann man sowohl Traffic innerhalb einer Firewallzone als auch zwischen verschiedenen Firewallzonen.Damit wird das Firewallregelwerk flexibler und mächtiger, als wenn man (wie z.B. bei pfSense) direkt auf Interfaces abstellen würde. Neben den bereits angesprochenen repräsentativen Ethernetinterfaces/Portgroupings können z.B. auch VLAN-Interfaces, Tunnel-Interfaces oder
PPP-Interfaces in Zonen aufgenommen/gruppiert werden.
Damit die Firewall zwischen den Interfaces routen kann, benötigt jedes Interface eine überschneidungsfreie IP-Konfiguration. Indirekt bedeutet dies, dass die Firewall (zunächst) nur dann wirken kann, wenn die Zywall auch zwischen verschiedenen IP-Netzen routet. In gewissen Szenarien ist es jedoch durchaus gewünscht, Layer2-Traffic mit der Firewall beregeln zu können. Hier kommt die von Aqui erwähnte Bridge ins Spiel: Man entfernt die IP-Konfig von zwei oder mehr Interfaces und fasst diese zu einer Bridge zusammen. Diese Bridge erhält dann eine IP-Konfiguration, die auf alle Member-Interfaces wirkt. Alle beteiligten Interfaces liegen dann also im gleichen IP-Netz und dennoch kann der Traffic dazwischen per Firewall beregelt werden. Damit mutiert die Zywall partiell zur Layer2-Firewall. Allerdings wirkt sich eine solche Bridge u.U. negativ auf die Performence aus, weil alles über die CPU der Zywall läuft. Die Gruppierung von physischen Ports zu einer Portgruppe umgeht hingegen nicht nur den IP-Stack und das Firewallregelwerk der Zywall, sondern läuft i.d.R. auch auf dem Switchchip ab, was die CPU gar nicht belastet.
Ich hoffe, ich konnte ein wenig zur Verwirrung beitragen...
Gruß
sk
Ansonsten nimm eine pfSense Firewall:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Dort ist das mit 3 Mausklicks im Handumdrehen konfiguriert. (Wenn man denn unbedingt bridgen will...?!)
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Dort ist das mit 3 Mausklicks im Handumdrehen konfiguriert. (Wenn man denn unbedingt bridgen will...?!)